From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 01:02:28 2008 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 E310E1065670; Sun, 21 Sep 2008 01:02:27 +0000 (UTC) (envelope-from netgeek@bgp4.net) Received: from mail.bgp4.net (mail.bgp4.net [64.247.24.57]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB0B8FC14; Sun, 21 Sep 2008 01:02:27 +0000 (UTC) (envelope-from netgeek@bgp4.net) Received: from janet-sullivans-macbook-pro.local (pool-71-112-183-31.sttlwa.dsl-w.verizon.net [71.112.183.31]) (authenticated bits=0) by mail.bgp4.net (8.14.2/8.14.2) with ESMTP id m8L0bV2Z004953 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 20 Sep 2008 17:37:37 -0700 (PDT) (envelope-from netgeek@bgp4.net) Message-ID: <48D596AD.1070209@bgp4.net> Date: Sat, 20 Sep 2008 17:34:53 -0700 From: netgeek User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Robert Watson References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.bgp4.net [64.247.24.57]); Sat, 20 Sep 2008 17:37:38 -0700 (PDT) Cc: Jo Rhett , freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 21 Sep 2008 01:02:28 -0000 Robert Watson wrote: > When it comes to commercial OS products, like Windows and Mac OS X, > there is often a strict requirement to live on the most recent minor > release in order to continue to receive support. For example, you won't > make a lot of headway turning up at Apple and demanding security updates > for Mac OS X 10.5.0 a year after it has been released. The answer will > be "Great, update 10.5.3" (or something along those lines) -- not only > will it fix the security issues, but it will support the hardware we now > sell. In that sense, we're actually quite different: rather than saying > "Sorry, 6.2 is vulnerable, please upgrade to 6.3", we say "You can live > on 6.2 for up to 18 months and receive *only* security and critical > errata patches". > > Don't get me wrong: I would love to see us support all releases for 24 > months (or even more) after they ship. I think our users would > appreciate that also. Perhaps there is a middle ground here? What about a statement that each major branch (6.x, 7.x) will be supported for at least 24+ months from its last production release? Smaller periods of support could be given to minor releases along the way (7.2, for example), but at least companies would know that if they installed a 6.x version, they'd have support for a couple of years, even if that might mean upgrading to a newer minor version if there was a problem. I really wouldn't mind being told to upgrade from 7.2 to 7.4_p12 because its been 20 months since the last 7.x release. Because companies are used to the Apple and Microsoft way you outlined above, I don't think they'd have a huge problem with it either. Wouldn't it make it easier on the teams to only ofter extended support for the major versions, rather than trying to support specific minor versions (6.3, 6.4, 7.0, 7.1) for an extended time? I'll admit, in the early days of 5.x, I really didn't like having to jump between minor versions. Let's face it, things didn't really settle down until, what, 5.3? In those days, being able to stay on a specific minor release was a Good Thing. However, I don't have the same kind of API and upgrade fear going from 6.x to 6.y. Maybe there are people out there who truly fear upgrading from 6.3 to 6.4, and need both supported for an extended time. But if resources are limited, it seems that only offering extended support for the latest release from a major branch would be the way to go. Perhaps 6-12 months for a minor release, 24+ months for the entire major release train? I'm not demanding anything, or saying this is the right way. I'm just wondering if there is a compromise out there that would give companies the security that their 6.x or 7.x server will have 2 years+ of support for vulnerabilities, while at the same time not requiring the developers to extended support for multiple minor releases. I'll now go put on my asbestos undergarments and sit in the corner. ;-) From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 01:47:58 2008 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 EE44B106567D for ; Sun, 21 Sep 2008 01:47:58 +0000 (UTC) (envelope-from ozbilgin@hotmail.com) Received: from bay0-omc3-s34.bay0.hotmail.com (bay0-omc3-s34.bay0.hotmail.com [65.54.246.234]) by mx1.freebsd.org (Postfix) with ESMTP id D1CF88FC1E for ; Sun, 21 Sep 2008 01:47:58 +0000 (UTC) (envelope-from ozbilgin@hotmail.com) Received: from BAY138-W30 ([64.4.49.65]) by bay0-omc3-s34.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 20 Sep 2008 18:47:58 -0700 Message-ID: Content-Type: multipart/mixed; boundary="_f8b786d7-4619-43eb-a4e3-fefd36fe9127_" X-Originating-IP: [88.230.246.57] From: =?windows-1254?Q?yusuf_=F6zbilgin?= To: Jeremy Chadwick Date: Sun, 21 Sep 2008 04:47:57 +0300 Importance: Normal In-Reply-To: <20080920225314.GA84482@icarus.home.lan> References: <20080920225314.GA84482@icarus.home.lan> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Sep 2008 01:47:58.0475 (UTC) FILETIME=[12FD95B0:01C91B8C] X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: RE: Freebsd custom installation cd 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, 21 Sep 2008 01:47:59 -0000 --_f8b786d7-4619-43eb-a4e3-fefd36fe9127_ Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: 8bit I added kernel configuration as attachment. When I boot system via freebsd live cd at boot process .... hptrr: no controller detected. acd0:DVDR at ata2-master UDMA66 ad16: 476938MB at ata8-master SATA300 then everthing is ok. but when I boot via custom installation cd; ad16 is not listed at boot screen. then saying no disk at fdisk section. I think there is missing kernel module but I couldnt find it. > Date: Sat, 20 Sep 2008 15:53:14 -0700> From: koitsu@FreeBSD.org> To: ozbilgin@hotmail.com> CC: freebsd-stable@freebsd.org> Subject: Re: Freebsd custom installation cd> > On Sun, Sep 21, 2008 at 01:20:51AM +0300, yusuf özbilgin wrote:> > Hello, I created custom freebsd installation cd with custom kernel.> > When I boot system with custom cd; kernel detects Intel ICH9 sata300> > controller but end of the bootingit doesnt detect my sata disk.> > When you say "it doesn't detect my SATA disk", what do you mean?> > Does the system lock up after saying "Mounting root from..."? Please> let me know -- it's very important.> > > Mainboard is intel and chipset is i965. There is no problem when I use> > this custom cd with gigabyte p35 chipset mainboard with same sata disk > > When I use the freebsd live cd> > > > it detects atapci0 Marvell 88SX6101> > and atapci1 Intel Ahci Controller > > > > then it detects disk without problem. > > > > My kernel conf file is below.> > No one can read your kernel configuration because what you posted lacks> newlines.> > Additionally, you said you're using a "custom FreeBSD installation CD",> which may be part of the problem as well (since you admit the Live CD> works fine).> > -- > | Jeremy Chadwick jdc at parodius.com |> | Parodius Networking http://www.parodius.com/ |> | UNIX Systems Administrator Mountain View, CA, USA |> | Making life hard for others since 1977. PGP: 4BD6C0CB |> > _______________________________________________> 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" --_f8b786d7-4619-43eb-a4e3-fefd36fe9127_ Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="FREEBSD-CDBOOT.txt" IA0KY3B1ICAgICAgICAgICAgIEk0ODZfQ1BVDQpjcHUgICAgICAgICAgICAgSTU4Nl9DUFUNCmNw dSAgICAgICAgICAgICBJNjg2X0NQVQ0KaWRlbnQgICAgICAgICAgIEZSRUVCU0QtQ0RCT09UDQoj IFRvIHN0YXRpY2FsbHkgY29tcGlsZSBpbiBkZXZpY2Ugd2lyaW5nIGluc3RlYWQgb2YgL2Jvb3Qv ZGV2aWNlLmhpbnRzDQojaGludHMgICAgICAgICAgIkdFTkVSSUMuaGludHMiICAgICAgICAgIyBE ZWZhdWx0IHBsYWNlcyB0byBsb29rIGZvciBkZXZpY2VzLg0KI21ha2VvcHRpb25zICAgIERFQlVH PS1nICAgICAgICAgICAgICAgICMgQnVpbGQga2VybmVsIHdpdGggZ2RiKDEpIGRlYnVnIHN5bWJv bHMNCm9wdGlvbnMgICAgICAgICBTQ0hFRF80QlNEICAgICAgICAgICAgICAjIDRCU0Qgc2NoZWR1 bGVyDQpvcHRpb25zICAgICAgICAgUFJFRU1QVElPTiAgICAgICAgICAgICAgIyBFbmFibGUga2Vy bmVsIHRocmVhZCBwcmVlbXB0aW9uDQpvcHRpb25zICAgICAgICAgSU5FVCAgICAgICAgICAgICAg ICAgICAgIyBJbnRlck5FVHdvcmtpbmcNCiNvcHRpb25zICAgICAgICBJTkVUNiAgICAgICAgICAg ICAgICAgICAjIElQdjYgY29tbXVuaWNhdGlvbnMgcHJvdG9jb2xzDQojb3B0aW9ucyAgICAgICAg U0NUUCAgICAgICAgICAgICAgICAgICAgIyBTdHJlYW0gQ29udHJvbCBUcmFuc21pc3Npb24gUHJv dG9jb2wNCm9wdGlvbnMgICAgICAgICBGRlMgICAgICAgICAgICAgICAgICAgICAjIEJlcmtlbGV5 IEZhc3QgRmlsZXN5c3RlbQ0Kb3B0aW9ucyAgICAgICAgIFNPRlRVUERBVEVTICAgICAgICAgICAg ICMgRW5hYmxlIEZGUyBzb2Z0IHVwZGF0ZXMgc3VwcG9ydA0Kb3B0aW9ucyAgICAgICAgIFVGU19B Q0wgICAgICAgICAgICAgICAgICMgU3VwcG9ydCBmb3IgYWNjZXNzIGNvbnRyb2wgbGlzdHMNCm9w dGlvbnMgICAgICAgICBVRlNfRElSSEFTSCAgICAgICAgICAgICAjIEltcHJvdmUgcGVyZm9ybWFu Y2Ugb24gYmlnIGRpcmVjdG9yaWVzDQojb3B0aW9ucyAgICAgICAgVUZTX0dKT1VSTkFMICAgICAg ICAgICAgIyBFbmFibGUgZ2pvdXJuYWwtYmFzZWQgVUZTIGpvdXJuYWxpbmcNCm9wdGlvbnMgICAg ICAgICBNRF9ST09UICAgICAgICAgICAgICAgICAjIE1EIGlzIGEgcG90ZW50aWFsIHJvb3QgZGV2 aWNlDQpvcHRpb25zICAgICAgICAgTURfUk9PVF9TSVpFPTMwMDAwDQpvcHRpb25zICAgICAgICAg TkZTQ0xJRU5UICAgICAgICAgICAgICAgIyBOZXR3b3JrIEZpbGVzeXN0ZW0gQ2xpZW50DQojb3B0 aW9ucyAgICAgICAgTkZTU0VSVkVSICAgICAgICAgICAgICAgIyBOZXR3b3JrIEZpbGVzeXN0ZW0g U2VydmVyDQpvcHRpb25zICAgICAgICAgTkZTX1JPT1QgICAgICAgICAgICAgICAgIyBORlMgdXNh YmxlIGFzIC8sIHJlcXVpcmVzIE5GU0NMSUVOVA0Kb3B0aW9ucyAgICAgICAgIE1TRE9TRlMgICAg ICAgICAgICAgICAgICMgTVNET1MgRmlsZXN5c3RlbQ0Kb3B0aW9ucyAgICAgICAgIENEOTY2MCAg ICAgICAgICAgICAgICAgICMgSVNPIDk2NjAgRmlsZXN5c3RlbQ0Kb3B0aW9ucyAgICAgICAgIFBS T0NGUyAgICAgICAgICAgICAgICAgICMgUHJvY2VzcyBmaWxlc3lzdGVtIChyZXF1aXJlcyBQU0VV RE9GUykNCm9wdGlvbnMgICAgICAgICBQU0VVRE9GUyAgICAgICAgICAgICAgICAjIFBzZXVkby1m aWxlc3lzdGVtIGZyYW1ld29yaw0Kb3B0aW9ucyAgICAgICAgIEdFT01fUEFSVF9HUFQgICAgICAg ICAgICMgR1VJRCBQYXJ0aXRpb24gVGFibGVzLg0Kb3B0aW9ucyAgICAgICAgIEdFT01fTEFCRUwg ICAgICAgICAgICAgICMgUHJvdmlkZXMgbGFiZWxpemF0aW9uDQpvcHRpb25zICAgICAgICAgQ09N UEFUXzQzVFRZICAgICAgICAgICAgIyBCU0QgNC4zIFRUWSBjb21wYXQgW0tFRVAgVEhJUyFdDQpv cHRpb25zICAgICAgICAgQ09NUEFUX0ZSRUVCU0Q0ICAgICAgICAgIyBDb21wYXRpYmxlIHdpdGgg RnJlZUJTRDQNCm9wdGlvbnMgICAgICAgICBDT01QQVRfRlJFRUJTRDUgICAgICAgICAjIENvbXBh dGlibGUgd2l0aCBGcmVlQlNENQ0Kb3B0aW9ucyAgICAgICAgIENPTVBBVF9GUkVFQlNENiAgICAg ICAgICMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q2DQpvcHRpb25zICAgICAgICAgU0NTSV9ERUxB WT01MDAwICAgICAgICAgIyBEZWxheSAoaW4gbXMpIGJlZm9yZSBwcm9iaW5nIFNDU0kNCm9wdGlv bnMgICAgICAgICBLVFJBQ0UgICAgICAgICAgICAgICAgICAjIGt0cmFjZSgxKSBzdXBwb3J0DQpv cHRpb25zICAgICAgICAgU1lTVlNITSAgICAgICAgICAgICAgICAgIyBTWVNWLXN0eWxlIHNoYXJl ZCBtZW1vcnkNCm9wdGlvbnMgICAgICAgICBTWVNWTVNHICAgICAgICAgICAgICAgICAjIFNZU1Yt c3R5bGUgbWVzc2FnZSBxdWV1ZXMNCm9wdGlvbnMgICAgICAgICBTWVNWU0VNICAgICAgICAgICAg ICAgICAjIFNZU1Ytc3R5bGUgc2VtYXBob3Jlcw0Kb3B0aW9ucyAgICAgICAgIF9LUE9TSVhfUFJJ T1JJVFlfU0NIRURVTElORyAjIFBPU0lYIFAxMDAzXzFCIHJlYWwtdGltZSBleHRlbnNpb25zDQpv cHRpb25zICAgICAgICAgS0JEX0lOU1RBTExfQ0RFViAgICAgICAgIyBpbnN0YWxsIGEgQ0RFViBl bnRyeSBpbiAvZGV2DQpvcHRpb25zICAgICAgICAgQURBUFRJVkVfR0lBTlQgICAgICAgICAgIyBH aWFudCBtdXRleCBpcyBhZGFwdGl2ZS4NCm9wdGlvbnMgICAgICAgICBTVE9QX05NSSAgICAgICAg ICAgICAgICAjIFN0b3AgQ1BVUyB1c2luZyBOTUkgaW5zdGVhZCBvZiBJUEkNCiNvcHRpb25zICAg ICAgICBBVURJVCAgICAgICAgICAgICAgICAgICAjIFNlY3VyaXR5IGV2ZW50IGF1ZGl0aW5nDQoj b3B0aW9ucyAgICAgICAgIFFVT1RBDQojb3B0aW9ucyAgICAgICAgIElQRklSRVdBTEwNCiNvcHRp b25zICAgICAgICAgSVBGSVJFV0FMTF9WRVJCT1NFDQojb3B0aW9ucyAgICAgICAgIElQRklSRVdB TExfVkVSQk9TRV9MSU1JVD01DQojb3B0aW9ucyAgICAgICAgIElQRklSRVdBTExfRk9SV0FSRA0K I29wdGlvbnMgICAgICAgICBJUEZJUkVXQUxMX05BVA0KI29wdGlvbnMgICAgICAgICBJUERJVkVS VA0KI29wdGlvbnMgICAgICAgICBEVU1NWU5FVA0KI29wdGlvbnMgICAgICAgICBJUFNURUFMVEgN CiMNCm9wdGlvbnMgICAgICAgICBORVRHUkFQSA0Kb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX0JQ Rg0Kb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX0JSSURHRQ0Kb3B0aW9ucyAgICAgICAgIE5FVEdS QVBIX0RFVklDRQ0Kb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX0VDSE8NCm9wdGlvbnMgICAgICAg ICBORVRHUkFQSF9FVEhFUg0Kb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX0dJRg0Kb3B0aW9ucyAg ICAgICAgIE5FVEdSQVBIX0dJRl9ERU1VWA0Kb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX0hPTEUN Cm9wdGlvbnMgICAgICAgICBORVRHUkFQSF9UQUcNCm9wdGlvbnMgICAgICAgICBORVRHUkFQSF9J RkFDRQ0Kb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX0lQX0lOUFVUDQpvcHRpb25zICAgICAgICAg TkVUR1JBUEhfSVBGVw0Kb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX0tTT0NLRVQNCm9wdGlvbnMg ICAgICAgICBORVRHUkFQSF9OQVQNCiNvcHRpb25zICAgIElQRklSRVdBTExfREVGQVVMVF9UT19B Q0NFUFQNCiMNCm9wdGlvbnMgICAgICAgICBMSUJBTElBUw0Kb3B0aW9ucyAgICAgICAgIE5FVEdS QVBIX05FVEZMT1cNCm9wdGlvbnMgICAgICAgICBORVRHUkFQSF9QUFANCm9wdGlvbnMgICAgICAg ICBORVRHUkFQSF9TT0NLRVQNCm9wdGlvbnMgICAgICAgICBORVRHUkFQSF9TUExJVA0Kb3B0aW9u cyAgICAgICAgIE5FVEdSQVBIX1RDUE1TUw0Kb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX1RFRQ0K b3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX1RUWQ0Kb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX1VJ DQoNCiNvcHRpb25zICAgICAgICAgSFo9MTAwMA0KI29wdGlvbnMgICAgICAgICBJUFNFQw0KI29w dGlvbnMgICAgICAgICBJUFNFQ19GSUxURVJUVU5ORUwNCiNkZXZpY2UgICAgICAgICAgY3J5cHRv DQoNCiMgVG8gbWFrZSBhbiBTTVAga2VybmVsLCB0aGUgbmV4dCB0d28gbGluZXMgYXJlIG5lZWRl ZA0KI29wdGlvbnMgICAgICAgIFNNUCAgICAgICAgICAgICAgICAgICAgICMgU3ltbWV0cmljIE11 bHRpUHJvY2Vzc29yIEtlcm5lbA0KZGV2aWNlICAgICAgICAgIGFwaWMgICAgICAgICAgICAgICAg ICAgICMgSS9PIEFQSUMNCiMgQ1BVIGZyZXF1ZW5jeSBjb250cm9sDQojZGV2aWNlICAgICAgICAg Y3B1ZnJlcQ0KIyBCdXMgc3VwcG9ydC4NCmRldmljZSAgICAgICAgICBlaXNhDQpkZXZpY2UgICAg ICAgICAgcGNpDQojIEZsb3BweSBkcml2ZXMNCmRldmljZSAgICAgICAgICBmZGMNCiMgQVRBIGFu ZCBBVEFQSSBkZXZpY2VzDQpkZXZpY2UgICAgICAgICAgYXRhDQpkZXZpY2UgICAgICAgICAgYXRh ZGlzayAgICAgICAgICMgQVRBIGRpc2sgZHJpdmVzDQpkZXZpY2UgICAgICAgICAgYXRhcmFpZCAg ICAgICAgICMgQVRBIFJBSUQgZHJpdmVzDQpkZXZpY2UgICAgICAgICAgYXRhcGljZCAgICAgICAg ICMgQVRBUEkgQ0RST00gZHJpdmVzDQojZGV2aWNlICAgICAgICAgYXRhcGlmZCAgICAgICAgICMg QVRBUEkgZmxvcHB5IGRyaXZlcw0KI2RldmljZSAgICAgICAgIGF0YXBpc3QgICAgICAgICAjIEFU QVBJIHRhcGUgZHJpdmVzDQpvcHRpb25zICAgICAgICAgQVRBX1NUQVRJQ19JRCAgICMgU3RhdGlj IGRldmljZSBudW1iZXJpbmcNCiMgU0NTSSBDb250cm9sbGVycw0KZGV2aWNlICAgICAgICAgIGFo YiAgICAgICAgICAgICAjIEVJU0EgQUhBMTc0MiBmYW1pbHkNCmRldmljZSAgICAgICAgICBhaGMg ICAgICAgICAgICAgIyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4eHggZGV2aWNlcw0Kb3B0aW9u cyAgICAgICAgIEFIQ19SRUdfUFJFVFRZX1BSSU5UICAgICMgUHJpbnQgcmVnaXN0ZXIgYml0Zmll bGRzIGluIGRlYnVnDQpkZXZpY2UgICAgICAgICAgYWhkICAgICAgICAgICAgICMgQUhBMzkzMjAv MjkzMjAgYW5kIG9uYm9hcmQgQUlDNzl4eCBkZXZpY2VzDQpvcHRpb25zICAgICAgICAgQUhEX1JF R19QUkVUVFlfUFJJTlQgICAgIyBQcmludCByZWdpc3RlciBiaXRmaWVsZHMgaW4gZGVidWcNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIG91dHB1dC4gIEFkZHMgfjIx NWsgdG8gZHJpdmVyLg0KZGV2aWNlICAgICAgICAgIGFtZCAgICAgICAgICAgICAjIEFNRCA1M0M5 NzQgKFRla3JhbSBEQy0zOTAoVCkpDQpkZXZpY2UgICAgICAgICAgaHB0aW9wICAgICAgICAgICMg SGlnaHBvaW50IFJvY2tldFJhaWQgM3h4eCBzZXJpZXMNCmRldmljZSAgICAgICAgICBpc3AgICAg ICAgICAgICAgIyBRbG9naWMgZmFtaWx5DQojZGV2aWNlICAgICAgICAgaXNwZncgICAgICAgICAg ICMgRmlybXdhcmUgZm9yIFFMb2dpYyBIQkFzLSBub3JtYWxseSBhIG1vZHVsZQ0KZGV2aWNlICAg ICAgICAgIG1wdCAgICAgICAgICAgICAjIExTSS1Mb2dpYyBNUFQtRnVzaW9uDQojZGV2aWNlICAg ICAgICAgbmNyICAgICAgICAgICAgICMgTkNSL1N5bWJpb3MgTG9naWMNCmRldmljZSAgICAgICAg ICBzeW0gICAgICAgICAgICAgIyBOQ1IvU3ltYmlvcyBMb2dpYyAobmV3ZXIgY2hpcHNldHMgKyB0 aG9zZSBvZiBgbmNyJykNCmRldmljZSAgICAgICAgICB0cm0gICAgICAgICAgICAgIyBUZWtyYW0g REMzOTVVL1VXL0YgREMzMTVVIGFkYXB0ZXJzDQpkZXZpY2UgICAgICAgICAgYWR2ICAgICAgICAg ICAgICMgQWR2YW5zeXMgU0NTSSBhZGFwdGVycw0KZGV2aWNlICAgICAgICAgIGFkdyAgICAgICAg ICAgICAjIEFkdmFuc3lzIHdpZGUgU0NTSSBhZGFwdGVycw0KZGV2aWNlICAgICAgICAgIGFoYSAg ICAgICAgICAgICAjIEFkYXB0ZWMgMTU0eCBTQ1NJIGFkYXB0ZXJzDQpkZXZpY2UgICAgICAgICAg YWljICAgICAgICAgICAgICMgQWRhcHRlYyAxNVswMTJdeCBTQ1NJIGFkYXB0ZXJzLCBBSUMtNlsy M102MC4NCmRldmljZSAgICAgICAgICBidCAgICAgICAgICAgICAgIyBCdXNsb2dpYy9NeWxleCBN dWx0aU1hc3RlciBTQ1NJIGFkYXB0ZXJzDQpkZXZpY2UgICAgICAgICAgbmN2ICAgICAgICAgICAg ICMgTkNSIDUzQzUwMA0KZGV2aWNlICAgICAgICAgIG5zcCAgICAgICAgICAgICAjIFdvcmtiaXQg TmluamEgU0NTSS0zDQpkZXZpY2UgICAgICAgICAgc3RnICAgICAgICAgICAgICMgVE1DIDE4QzMw LzE4QzUwDQojIFNDU0kgcGVyaXBoZXJhbHMNCmRldmljZSAgICAgICAgICBzY2J1cyAgICAgICAg ICAgIyBTQ1NJIGJ1cyAocmVxdWlyZWQgZm9yIFNDU0kpDQpkZXZpY2UgICAgICAgICAgY2ggICAg ICAgICAgICAgICMgU0NTSSBtZWRpYSBjaGFuZ2Vycw0KZGV2aWNlICAgICAgICAgIGRhICAgICAg ICAgICAgICAjIERpcmVjdCBBY2Nlc3MgKGRpc2tzKQ0KZGV2aWNlICAgICAgICAgIHNhICAgICAg ICAgICAgICAjIFNlcXVlbnRpYWwgQWNjZXNzICh0YXBlIGV0YykNCmRldmljZSAgICAgICAgICBj ZCAgICAgICAgICAgICAgIyBDRA0KZGV2aWNlICAgICAgICAgIHBhc3MgICAgICAgICAgICAjIFBh c3N0aHJvdWdoIGRldmljZSAoZGlyZWN0IFNDU0kgYWNjZXNzKQ0KZGV2aWNlICAgICAgICAgIHNl cyAgICAgICAgICAgICAjIFNDU0kgRW52aXJvbm1lbnRhbCBTZXJ2aWNlcyAoYW5kIFNBRi1URSkN CiMgUkFJRCBjb250cm9sbGVycyBpbnRlcmZhY2VkIHRvIHRoZSBTQ1NJIHN1YnN5c3RlbQ0KI2Rl dmljZSAgICAgICAgIGFtciAgICAgICAgICAgICAjIEFNSSBNZWdhUkFJRA0KI2RldmljZSAgICAg ICAgIGFyY21zciAgICAgICAgICAjIEFyZWNhIFNBVEEgSUkgUkFJRA0KI2RldmljZSAgICAgICAg IGFzciAgICAgICAgICAgICAjIERQVCBTbWFydFJBSUQgViwgVkkgYW5kIEFkYXB0ZWMgU0NTSSBS QUlEDQpkZXZpY2UgICAgICAgICAgY2lzcyAgICAgICAgICAgICMgQ29tcGFxIFNtYXJ0IFJBSUQg NSoNCmRldmljZSAgICAgICAgICBkcHQgICAgICAgICAgICAgIyBEUFQgU21hcnRjYWNoZSBJSUks IElWIC0gU2VlIE5PVEVTIGZvciBvcHRpb25zDQpkZXZpY2UgICAgICAgICAgaHB0bXYgICAgICAg ICAgICMgSGlnaHBvaW50IFJvY2tldFJBSUQgMTgyeA0KZGV2aWNlICAgICAgICAgIGhwdHJyICAg ICAgICAgICAjIEhpZ2hwb2ludCBSb2NrZXRSQUlEIDE3eHgsIDIyeHgsIDIzeHgsIDI1eHgNCmRl dmljZSAgICAgICAgICBpaXIgICAgICAgICAgICAgIyBJbnRlbCBJbnRlZ3JhdGVkIFJBSUQNCmRl dmljZSAgICAgICAgICBpcHMgICAgICAgICAgICAgIyBJQk0gKEFkYXB0ZWMpIFNlcnZlUkFJRA0K ZGV2aWNlICAgICAgICAgIG1seSAgICAgICAgICAgICAjIE15bGV4IEFjY2VsZVJBSUQvZVh0cmVt ZVJBSUQNCmRldmljZSAgICAgICAgICB0d2EgICAgICAgICAgICAgIyAzd2FyZSA5MDAwIHNlcmll cyBQQVRBL1NBVEEgUkFJRA0KIyBSQUlEIGNvbnRyb2xsZXJzDQpkZXZpY2UgICAgICAgICAgYWFj ICAgICAgICAgICAgICMgQWRhcHRlYyBGU0EgUkFJRA0KZGV2aWNlICAgICAgICAgIGFhY3AgICAg ICAgICAgICAjIFNDU0kgcGFzc3Rocm91Z2ggZm9yIGFhYyAocmVxdWlyZXMgQ0FNKQ0KZGV2aWNl ICAgICAgICAgIGlkYSAgICAgICAgICAgICAjIENvbXBhcSBTbWFydCBSQUlEDQpkZXZpY2UgICAg ICAgICAgbWZpICAgICAgICAgICAgICMgTFNJIE1lZ2FSQUlEIFNBUw0KZGV2aWNlICAgICAgICAg IG1seCAgICAgICAgICAgICAjIE15bGV4IERBQzk2MCBmYW1pbHkNCmRldmljZSAgICAgICAgICBw c3QgICAgICAgICAgICAgIyBQcm9taXNlIFN1cGVydHJhayBTWDYwMDANCmRldmljZSAgICAgICAg ICB0d2UgICAgICAgICAgICAgIyAzd2FyZSBBVEEgUkFJRA0KIyBhdGtiZGMwIGNvbnRyb2xzIGJv dGggdGhlIGtleWJvYXJkIGFuZCB0aGUgUFMvMiBtb3VzZQ0KZGV2aWNlICAgICAgICAgIGF0a2Jk YyAgICAgICAgICAjIEFUIGtleWJvYXJkIGNvbnRyb2xsZXINCmRldmljZSAgICAgICAgICBhdGti ZCAgICAgICAgICAgIyBBVCBrZXlib2FyZA0KZGV2aWNlICAgICAgICAgIHBzbSAgICAgICAgICAg ICAjIFBTLzIgbW91c2UNCmRldmljZSAgICAgICAgICBrYmRtdXggICAgICAgICAgIyBrZXlib2Fy ZCBtdWx0aXBsZXhlcg0KZGV2aWNlICAgICAgICAgIHZnYSAgICAgICAgICAgICAjIFZHQSB2aWRl byBjYXJkIGRyaXZlcg0KZGV2aWNlICAgICAgICAgIHNwbGFzaCAgICAgICAgICAjIFNwbGFzaCBz Y3JlZW4gYW5kIHNjcmVlbiBzYXZlciBzdXBwb3J0DQojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQg Y29uc29sZSBkcml2ZXIsIHJlc2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUNCmRldmljZSAgICAgICAg ICBzYw0KZGV2aWNlICAgICAgICAgIGFncCAgICAgICAgICAgICAjIHN1cHBvcnQgc2V2ZXJhbCBB R1AgY2hpcHNldHMNCiMgUG93ZXIgbWFuYWdlbWVudCBzdXBwb3J0IChzZWUgTk9URVMgZm9yIG1v cmUgb3B0aW9ucykNCiNkZXZpY2UgICAgICAgICBhcG0NCiMgQWRkIHN1c3BlbmQvcmVzdW1lIHN1 cHBvcnQgZm9yIHRoZSBpODI1NC4NCmRldmljZSAgICAgICAgICBwbXRpbWVyDQojIFBDQ0FSRCAo UENNQ0lBKSBzdXBwb3J0DQojIFBDTUNJQSBhbmQgY2FyZGJ1cyBicmlkZ2Ugc3VwcG9ydA0KI2Rl dmljZSAgICAgICAgIGNiYiAgICAgICAgICAgICAjIGNhcmRidXMgKHllbnRhKSBicmlkZ2UNCiNk ZXZpY2UgICAgICAgICBwY2NhcmQgICAgICAgICAgIyBQQyBDYXJkICgxNi1iaXQpIGJ1cw0KI2Rl dmljZSAgICAgICAgIGNhcmRidXMgICAgICAgICAjIENhcmRCdXMgKDMyLWJpdCkgYnVzDQojIFNl cmlhbCAoQ09NKSBwb3J0cw0KZGV2aWNlICAgICAgICAgIHNpbyAgICAgICAgICAgICAjIDgyNTAs IDE2WzQ1XTUwIGJhc2VkIHNlcmlhbCBwb3J0cw0KZGV2aWNlICAgICAgICAgIHVhcnQgICAgICAg ICAgICAjIEdlbmVyaWMgVUFSVCBkcml2ZXINCiMgUGFyYWxsZWwgcG9ydA0KI2RldmljZSAgICAg ICAgIHBwYw0KI2RldmljZSAgICAgICAgIHBwYnVzICAgICAgICAgICAjIFBhcmFsbGVsIHBvcnQg YnVzIChyZXF1aXJlZCkNCiNkZXZpY2UgICAgICAgICBscHQgICAgICAgICAgICAgIyBQcmludGVy DQojZGV2aWNlICAgICAgICAgcGxpcCAgICAgICAgICAgICMgVENQL0lQIG92ZXIgcGFyYWxsZWwN CiNkZXZpY2UgICAgICAgICBwcGkgICAgICAgICAgICAgIyBQYXJhbGxlbCBwb3J0IGludGVyZmFj ZSBkZXZpY2UNCiNkZXZpY2UgICAgICAgICB2cG8gICAgICAgICAgICAgIyBSZXF1aXJlcyBzY2J1 cyBhbmQgZGENCiMgSWYgeW91J3ZlIGdvdCBhICJkdW1iIiBzZXJpYWwgb3IgcGFyYWxsZWwgUENJ IGNhcmQgdGhhdCBpcw0KIyBzdXBwb3J0ZWQgYnkgdGhlIHB1Yyg0KSBnbHVlIGRyaXZlciwgdW5j b21tZW50IHRoZSBmb2xsb3dpbmcNCiMgbGluZSB0byBlbmFibGUgaXQgKGNvbm5lY3RzIHRvIHNp bywgdWFydCBhbmQvb3IgcHBjIGRyaXZlcnMpOg0KI2RldmljZSAgICAgICAgIHB1Yw0KIyBQQ0kg RXRoZXJuZXQgTklDcy4NCmRldmljZSAgICAgICAgICBkZSAgICAgICAgICAgICAgIyBERUMvSW50 ZWwgREMyMXg0eCAoYGBUdWxpcCcnKQ0KZGV2aWNlICAgICAgICAgIGVtICAgICAgICAgICAgICAj IEludGVsIFBSTy8xMDAwIGFkYXB0ZXIgR2lnYWJpdCBFdGhlcm5ldCBDYXJkDQpkZXZpY2UgICAg ICAgICAgaXhnYiAgICAgICAgICAgICMgSW50ZWwgUFJPLzEwR2JFIEV0aGVybmV0IENhcmQNCmRl dmljZSAgICAgICAgICBsZSAgICAgICAgICAgICAgIyBBTUQgQW03OTAwIExBTkNFIGFuZCBBbTc5 Qzl4eCBQQ25ldA0KZGV2aWNlICAgICAgICAgIHR4cCAgICAgICAgICAgICAjIDNDb20gM2NSOTkw IChgYFR5cGhvb24nJykNCmRldmljZSAgICAgICAgICB2eCAgICAgICAgICAgICAgIyAzQ29tIDNj NTkwLCAzYzU5NSAoYGBWb3J0ZXgnJykNCiMgUENJIEV0aGVybmV0IE5JQ3MgdGhhdCB1c2UgdGhl IGNvbW1vbiBNSUkgYnVzIGNvbnRyb2xsZXIgY29kZS4NCiMgTk9URTogQmUgc3VyZSB0byBrZWVw IHRoZSAnZGV2aWNlIG1paWJ1cycgbGluZSBpbiBvcmRlciB0byB1c2UgdGhlc2UgTklDcyENCmRl dmljZSAgICAgICAgICBtaWlidXMgICAgICAgICAgIyBNSUkgYnVzIHN1cHBvcnQNCmRldmljZSAg ICAgICAgICBiY2UgICAgICAgICAgICAgIyBCcm9hZGNvbSBCQ001NzA2L0JDTTU3MDggR2lnYWJp dCBFdGhlcm5ldA0KZGV2aWNlICAgICAgICAgIGJmZSAgICAgICAgICAgICAjIEJyb2FkY29tIEJD TTQ0MHggMTAvMTAwIEV0aGVybmV0DQpkZXZpY2UgICAgICAgICAgYmdlICAgICAgICAgICAgICMg QnJvYWRjb20gQkNNNTcweHggR2lnYWJpdCBFdGhlcm5ldA0KZGV2aWNlICAgICAgICAgIGRjICAg ICAgICAgICAgICAjIERFQy9JbnRlbCAyMTE0MyBhbmQgdmFyaW91cyB3b3JrYWxpa2VzDQpkZXZp Y2UgICAgICAgICAgZnhwICAgICAgICAgICAgICMgSW50ZWwgRXRoZXJFeHByZXNzIFBSTy8xMDBC ICg4MjU1NywgODI1NTgpDQpkZXZpY2UgICAgICAgICAgbGdlICAgICAgICAgICAgICMgTGV2ZWwg MSBMWFQxMDAxIGdpZ2FiaXQgRXRoZXJuZXQNCmRldmljZSAgICAgICAgICBtc2sgICAgICAgICAg ICAgIyBNYXJ2ZWxsL1N5c0tvbm5lY3QgWXVrb24gSUkgR2lnYWJpdCBFdGhlcm5ldA0KZGV2aWNl ICAgICAgICAgIG5mZSAgICAgICAgICAgICAjIG5WaWRpYSBuRm9yY2UgTUNQIG9uLWJvYXJkIEV0 aGVybmV0DQpkZXZpY2UgICAgICAgICAgbmdlICAgICAgICAgICAgICMgTmF0U2VtaSBEUDgzODIw IGdpZ2FiaXQgRXRoZXJuZXQNCiNkZXZpY2UgICAgICAgICBudmUgICAgICAgICAgICAgIyBuVmlk aWEgbkZvcmNlIE1DUCBvbi1ib2FyZCBFdGhlcm5ldCBOZXR3b3JraW5nDQpkZXZpY2UgICAgICAg ICAgcGNuICAgICAgICAgICAgICMgQU1EIEFtNzlDOTd4IFBDSSAxMC8xMDAgKHByZWNlZGVuY2Ug b3ZlciAnbGUnKQ0KZGV2aWNlICAgICAgICAgIHJlICAgICAgICAgICAgICAjIFJlYWxUZWsgODEz OUMrLzgxNjkvODE2OVMvODExMFMNCmRldmljZSAgICAgICAgICBybCAgICAgICAgICAgICAgIyBS ZWFsVGVrIDgxMjkvODEzOQ0KZGV2aWNlICAgICAgICAgIHNmICAgICAgICAgICAgICAjIEFkYXB0 ZWMgQUlDLTY5MTUgKGBgU3RhcmZpcmUnJykNCmRldmljZSAgICAgICAgICBzaXMgICAgICAgICAg ICAgIyBTaWxpY29uIEludGVncmF0ZWQgU3lzdGVtcyBTaVMgOTAwL1NpUyA3MDE2DQpkZXZpY2Ug ICAgICAgICAgc2sgICAgICAgICAgICAgICMgU3lzS29ubmVjdCBTSy05ODR4ICYgU0stOTgyeCBn aWdhYml0IEV0aGVybmV0DQpkZXZpY2UgICAgICAgICAgc3RlICAgICAgICAgICAgICMgU3VuZGFu Y2UgU1QyMDEgKEQtTGluayBERkUtNTUwVFgpDQpkZXZpY2UgICAgICAgICAgc3RnZSAgICAgICAg ICAgICMgU3VuZGFuY2UvVGFtYXJhY2sgVEM5MDIxIGdpZ2FiaXQgRXRoZXJuZXQNCmRldmljZSAg ICAgICAgICB0aSAgICAgICAgICAgICAgIyBBbHRlb24gTmV0d29ya3MgVGlnb24gSS9JSSBnaWdh Yml0IEV0aGVybmV0DQpkZXZpY2UgICAgICAgICAgdGwgICAgICAgICAgICAgICMgVGV4YXMgSW5z dHJ1bWVudHMgVGh1bmRlckxBTg0KZGV2aWNlICAgICAgICAgIHR4ICAgICAgICAgICAgICAjIFNN QyBFdGhlclBvd2VyIElJICg4M2MxNzAgYGBFUElDJycpDQpkZXZpY2UgICAgICAgICAgdmdlICAg ICAgICAgICAgICMgVklBIFZUNjEyeCBnaWdhYml0IEV0aGVybmV0DQpkZXZpY2UgICAgICAgICAg dnIgICAgICAgICAgICAgICMgVklBIFJoaW5lLCBSaGluZSBJSQ0KZGV2aWNlICAgICAgICAgIHdi ICAgICAgICAgICAgICAjIFdpbmJvbmQgVzg5Qzg0MEYNCmRldmljZSAgICAgICAgICB4bCAgICAg ICAgICAgICAgIyAzQ29tIDNjOTB4IChgYEJvb21lcmFuZycnLCBgYEN5Y2xvbmUnJykNCiMgSVNB IEV0aGVybmV0IE5JQ3MuICBwY2NhcmQgTklDcyBpbmNsdWRlZC4NCmRldmljZSAgICAgICAgICBj cyAgICAgICAgICAgICAgIyBDcnlzdGFsIFNlbWljb25kdWN0b3IgQ1M4OXgwIE5JQw0KIyAnZGV2 aWNlIGVkJyByZXF1aXJlcyAnZGV2aWNlIG1paWJ1cycNCmRldmljZSAgICAgICAgICBlZCAgICAg ICAgICAgICAgIyBORVsxMl0wMDAsIFNNQyBVbHRyYSwgM2M1MDMsIERTODM5MCBjYXJkcw0KZGV2 aWNlICAgICAgICAgIGV4ICAgICAgICAgICAgICAjIEludGVsIEV0aGVyRXhwcmVzcyBQcm8vMTAg YW5kIFByby8xMCsNCmRldmljZSAgICAgICAgICBlcCAgICAgICAgICAgICAgIyBFdGhlcmxpbmsg SUlJIGJhc2VkIGNhcmRzDQpkZXZpY2UgICAgICAgICAgZmUgICAgICAgICAgICAgICMgRnVqaXRz dSBNQjg2OTZ4IGJhc2VkIGNhcmRzDQpkZXZpY2UgICAgICAgICAgaWUgICAgICAgICAgICAgICMg RXRoZXJFeHByZXNzIDgvMTYsIDNDNTA3LCBTdGFyTEFOIDEwIGV0Yy4NCmRldmljZSAgICAgICAg ICBzbiAgICAgICAgICAgICAgIyBTTUMncyA5MDAwIHNlcmllcyBvZiBFdGhlcm5ldCBjaGlwcw0K ZGV2aWNlICAgICAgICAgIHhlICAgICAgICAgICAgICAjIFhpcmNvbSBwY2NhcmQgRXRoZXJuZXQN CiMgV2lyZWxlc3MgTklDIGNhcmRzDQpkZXZpY2UgICAgICAgICAgd2xhbiAgICAgICAgICAgICMg ODAyLjExIHN1cHBvcnQNCmRldmljZSAgICAgICAgICB3bGFuX3dlcCAgICAgICAgIyA4MDIuMTEg V0VQIHN1cHBvcnQNCmRldmljZSAgICAgICAgICB3bGFuX2NjbXAgICAgICAgIyA4MDIuMTEgQ0NN UCBzdXBwb3J0DQpkZXZpY2UgICAgICAgICAgd2xhbl90a2lwICAgICAgICMgODAyLjExIFRLSVAg c3VwcG9ydA0KZGV2aWNlICAgICAgICAgIHdsYW5fYW1yciAgICAgICAjIEFNUlIgdHJhbnNtaXQg cmF0ZSBjb250cm9sIGFsZ29yaXRobQ0KZGV2aWNlICAgICAgICAgIHdsYW5fc2Nhbl9hcCAgICAj IDgwMi4xMSBBUCBtb2RlIHNjYW5uaW5nDQpkZXZpY2UgICAgICAgICAgd2xhbl9zY2FuX3N0YSAg ICMgODAyLjExIFNUQSBtb2RlIHNjYW5uaW5nDQpkZXZpY2UgICAgICAgICAgYW4gICAgICAgICAg ICAgICMgQWlyb25ldCA0NTAwLzQ4MDAgODAyLjExIHdpcmVsZXNzIE5JQ3MuDQpkZXZpY2UgICAg ICAgICAgYXRoICAgICAgICAgICAgICMgQXRoZXJvcyBwY2kvY2FyZGJ1cyBOSUMncw0KZGV2aWNl ICAgICAgICAgIGF0aF9oYWwgICAgICAgICAjIEF0aGVyb3MgSEFMIChIYXJkd2FyZSBBY2Nlc3Mg TGF5ZXIpDQpkZXZpY2UgICAgICAgICAgYXRoX3JhdGVfc2FtcGxlICMgU2FtcGxlUmF0ZSB0eCBy YXRlIGNvbnRyb2wgZm9yIGF0aA0KZGV2aWNlICAgICAgICAgIGF3aSAgICAgICAgICAgICAjIEJh eVN0YWNrIDY2MCBhbmQgb3RoZXJzDQpkZXZpY2UgICAgICAgICAgcmFsICAgICAgICAgICAgICMg UmFsaW5rIFRlY2hub2xvZ3kgUlQyNTAwIHdpcmVsZXNzIE5JQ3MuDQpkZXZpY2UgICAgICAgICAg d2kgICAgICAgICAgICAgICMgV2F2ZUxBTi9JbnRlcnNpbC9TeW1ib2wgODAyLjExIHdpcmVsZXNz IE5JQ3MuDQojZGV2aWNlICAgICAgICAgd2wgICAgICAgICAgICAgICMgT2xkZXIgbm9uIDgwMi4x MSBXYXZlbGFuIHdpcmVsZXNzIE5JQy4NCiMgUHNldWRvIGRldmljZXMuDQpkZXZpY2UgICAgICAg ICAgbG9vcCAgICAgICAgICAgICMgTmV0d29yayBsb29wYmFjaw0KZGV2aWNlICAgICAgICAgIHJh bmRvbSAgICAgICAgICAjIEVudHJvcHkgZGV2aWNlDQpkZXZpY2UgICAgICAgICAgZXRoZXIgICAg ICAgICAgICMgRXRoZXJuZXQgc3VwcG9ydA0KZGV2aWNlICAgICAgICAgIHNsICAgICAgICAgICAg ICAjIEtlcm5lbCBTTElQDQpkZXZpY2UgICAgICAgICAgcHBwICAgICAgICAgICAgICMgS2VybmVs IFBQUA0KZGV2aWNlICAgICAgICAgIHR1biAgICAgICAgICAgICAjIFBhY2tldCB0dW5uZWwuDQpk ZXZpY2UgICAgICAgICAgcHR5ICAgICAgICAgICAgICMgUHNldWRvLXR0eXMgKHRlbG5ldCBldGMp DQpkZXZpY2UgICAgICAgICAgbWQgICAgICAgICAgICAgICMgTWVtb3J5ICJkaXNrcyINCmRldmlj ZSAgICAgICAgICBnaWYgICAgICAgICAgICAgIyBJUHY2IGFuZCBJUHY0IHR1bm5lbGluZw0KZGV2 aWNlICAgICAgICAgIGZhaXRoICAgICAgICAgICAjIElQdjYtdG8tSVB2NCByZWxheWluZyAodHJh bnNsYXRpb24pDQpkZXZpY2UgICAgICAgICAgZmlybXdhcmUgICAgICAgICMgZmlybXdhcmUgYXNz aXN0IG1vZHVsZQ0KIyBUaGUgYGJwZicgZGV2aWNlIGVuYWJsZXMgdGhlIEJlcmtlbGV5IFBhY2tl dCBGaWx0ZXIuDQojIEJlIGF3YXJlIG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb25zZXF1ZW5jZXMg b2YgZW5hYmxpbmcgdGhpcyENCiMgTm90ZSB0aGF0ICdicGYnIGlzIHJlcXVpcmVkIGZvciBESENQ Lg0KZGV2aWNlICAgICAgICAgIGJwZiAgICAgICAgICAgICAjIEJlcmtlbGV5IHBhY2tldCBmaWx0 ZXINCiMgVVNCIHN1cHBvcnQNCmRldmljZSAgICAgICAgICB1aGNpICAgICAgICAgICAgIyBVSENJ IFBDSS0+VVNCIGludGVyZmFjZQ0KZGV2aWNlICAgICAgICAgIG9oY2kgICAgICAgICAgICAjIE9I Q0kgUENJLT5VU0IgaW50ZXJmYWNlDQpkZXZpY2UgICAgICAgICAgZWhjaSAgICAgICAgICAgICMg RUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UgKFVTQiAyLjApDQpkZXZpY2UgICAgICAgICAgdXNiICAg ICAgICAgICAgICMgVVNCIEJ1cyAocmVxdWlyZWQpDQojZGV2aWNlICAgICAgICAgdWRicCAgICAg ICAgICAgICMgVVNCIERvdWJsZSBCdWxrIFBpcGUgZGV2aWNlcw0KZGV2aWNlICAgICAgICAgIHVn ZW4gICAgICAgICAgICAjIEdlbmVyaWMNCmRldmljZSAgICAgICAgICB1aGlkICAgICAgICAgICAg IyAiSHVtYW4gSW50ZXJmYWNlIERldmljZXMiDQpkZXZpY2UgICAgICAgICAgdWtiZCAgICAgICAg ICAgICMgS2V5Ym9hcmQNCiNkZXZpY2UgICAgICAgICB1bHB0ICAgICAgICAgICAgIyBQcmludGVy DQpkZXZpY2UgICAgICAgICAgdW1hc3MgICAgICAgICAgICMgRGlza3MvTWFzcyBzdG9yYWdlIC0g UmVxdWlyZXMgc2NidXMgYW5kIGRhDQpkZXZpY2UgICAgICAgICAgdW1zICAgICAgICAgICAgICMg TW91c2UNCmRldmljZSAgICAgICAgICB1cmFsICAgICAgICAgICAgIyBSYWxpbmsgVGVjaG5vbG9n eSBSVDI1MDBVU0Igd2lyZWxlc3MgTklDcw0KZGV2aWNlICAgICAgICAgIHJ1bSAgICAgICAgICAg ICAjIFJhbGluayBUZWNobm9sb2d5IFJUMjUwMVVTQiB3aXJlbGVzcyBOSUNzDQojZGV2aWNlICAg ICAgICAgdXJpbyAgICAgICAgICAgICMgRGlhbW9uZCBSaW8gNTAwIE1QMyBwbGF5ZXINCiNkZXZp Y2UgICAgICAgICB1c2Nhbm5lciAgICAgICAgIyBTY2FubmVycw0KIyBVU0IgRXRoZXJuZXQsIHJl cXVpcmVzIG1paWJ1cw0KI2RldmljZSAgICAgICAgIGF1ZSAgICAgICAgICAgICAjIEFETXRlayBV U0IgRXRoZXJuZXQNCiNkZXZpY2UgICAgICAgICBheGUgICAgICAgICAgICAgIyBBU0lYIEVsZWN0 cm9uaWNzIFVTQiBFdGhlcm5ldA0KI2RldmljZSAgICAgICAgIGNkY2UgICAgICAgICAgICAjIEdl bmVyaWMgVVNCIG92ZXIgRXRoZXJuZXQNCiNkZXZpY2UgICAgICAgICBjdWUgICAgICAgICAgICAg IyBDQVRDIFVTQiBFdGhlcm5ldA0KI2RldmljZSAgICAgICAgIGt1ZSAgICAgICAgICAgICAjIEth d2FzYWtpIExTSSBVU0IgRXRoZXJuZXQNCiNkZXZpY2UgICAgICAgICBydWUgICAgICAgICAgICAg IyBSZWFsVGVrIFJUTDgxNTAgVVNCIEV0aGVybmV0DQojIEZpcmVXaXJlIHN1cHBvcnQNCiNkZXZp Y2UgICAgICAgICBmaXJld2lyZSAgICAgICAgIyBGaXJlV2lyZSBidXMgY29kZQ0KI2RldmljZSAg ICAgICAgIHNicCAgICAgICAgICAgICAjIFNDU0kgb3ZlciBGaXJlV2lyZSAoUmVxdWlyZXMgc2Ni dXMgYW5kIGRhKQ0KI2RldmljZSAgICAgICAgIGZ3ZSAgICAgICAgICAgICAjIEV0aGVybmV0IG92 ZXIgRmlyZVdpcmUgKG5vbi1zdGFuZGFyZCEpDQojZGV2aWNlICAgICAgICAgZndpcCAgICAgICAg ICAgICMgSVAgb3ZlciBGaXJlV2lyZSAoUkZDIDI3MzQsMzE0NikNCiNkZXZpY2UgICAgICAgICBk Y29ucyAgICAgICAgICAgIyBEdW1iIGNvbnNvbGUgZHJpdmVyDQojZGV2aWNlICAgICAgICAgZGNv bnNfY3JvbSAgICAgICMgQ29uZmlndXJhdGlvbiBST00gZm9yIGRjb25zDQo= --_f8b786d7-4619-43eb-a4e3-fefd36fe9127_-- From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 02:04:54 2008 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 7557F1065670 for ; Sun, 21 Sep 2008 02:04:54 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id E04CB8FC0C for ; Sun, 21 Sep 2008 02:04:53 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from [10.29.62.12] (port=50582) by fish.ish.com.au with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1KhERX-0001fw-0r; Sun, 21 Sep 2008 12:12:59 +1000 Message-Id: <64D99803-C832-42B6-90EF-D46D29E395E6@ish.com.au> From: Aristedes Maniatis To: netgeek In-Reply-To: <48D596AD.1070209@bgp4.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 21 Sep 2008 11:52:50 +1000 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> X-Mailer: Apple Mail (2.929.2) Cc: Jo Rhett , freebsd-stable , Robert Watson Subject: Re: Upcoming Releases Schedule... 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, 21 Sep 2008 02:04:54 -0000 On 21/09/2008, at 10:34 AM, netgeek wrote: > Perhaps there is a middle ground here? What about a statement that > each major branch (6.x, 7.x) will be supported for at least 24+ > months from its last production release? Smaller periods of support > could be given to minor releases along the way (7.2, for example), > but at least companies would know that if they installed a 6.x > version, they'd have support for a couple of years, even if that > might mean upgrading to a newer minor version if there was a problem. This is already the case [1]. From each major branch one or more releases are designated as 'extended' and supported for 24 months. All you have to do is pick one of those and you've got support for 24 months. For example 6.3 has extended support in this way. RELENG_6 itself will be supported 24 months after the last release. Given roughly 18 months between major releases and about 12 months of ongoing releases from the previous branch after that, 4.5 years is roughly how long each major branch is supported for. That is already clear as could be. I can't quite understand what Jo Rhett is offering to the community that he is upset isn't being taken up. I think he wants some other arbitrary point release to be given extended support, either because in his case 24 months is not enough, or because he wants every release to have 24 months of support, or something else, I'm not sure. Jo, you say that he have had to maintain your own patched build of old FreeBSD releases because you need to keep them in production for longer than EoL period. Can I suggest that the first step is for you to publish those patches somewhere public and allow others to have access to them. Then you'll have a chance of convincing others to contribute to your patch sets and eventually of convincing FreeBSD to officially sanction them. Go and create a new sourceforge project or convince your boss to set aside some space on his web site/svn server/ etc for this project. Tell him that if it goes well, you'll be creating a whole lot of good will for the company in addition to the prospect of getting other people to contribute and share the work. Ari Maniatis [1] http://security.freebsd.org/ --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 05:22:24 2008 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 A4259106564A; Sun, 21 Sep 2008 05:22:24 +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 2F8718FC19; Sun, 21 Sep 2008 05:22:18 +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 1KhHOi-0000z0-QW; Sun, 21 Sep 2008 08:22:16 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Bob Willcox In-reply-to: <20080920185024.GC15275@rancor.immure.com> References: <20080920042418.GB1322@rancor.immure.com> <20080920123914.GA72833@icarus.home.lan> <20080920132429.GA15275@rancor.immure.com> <20080920140456.GA74663@icarus.home.lan> <20080920144510.GB15275@rancor.immure.com> <20080920150533.GA75785@icarus.home.lan> <20080920185024.GC15275@rancor.immure.com> Comments: In-reply-to Bob Willcox message dated "Sat, 20 Sep 2008 13:50:24 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Sep 2008 08:22:16 +0300 From: Danny Braniss Message-ID: Cc: PYUN Yong-Hyeon , Jeremy Chadwick , freebsd-stable@FreeBSD.org Subject: Re: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB 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, 21 Sep 2008 05:22:24 -0000 > On Sat, Sep 20, 2008 at 08:05:33AM -0700, Jeremy Chadwick wrote: > > On Sat, Sep 20, 2008 at 09:45:10AM -0500, Bob Willcox wrote: > > > On Sat, Sep 20, 2008 at 07:04:56AM -0700, Jeremy Chadwick wrote: > > > > On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: > > > > > > 1) It would be helpful to know if you installed i386 or amd64 FreeBSD, > > > > > > > > > > This is amd64 on this particular machine. > > > > > > > > > > > 2) With regards to the lock-up after "mount root", if you press NumLock > > > > > > or CapsLock, do the keyboard LEDs turn on/off? > > > > > > > > > > Nope, no keys do anything. You must either push reset or pull the plug. > > > > > > > > Is it possible to get the output when booting in verbose mode? If not, > > > > what are the last few lines before the machine locks up when booting > > > > verbosely? > > > > > > Yep, just did that. The last things printed right before hang are: > > > > > > ioapic0: Assigning ISA IRQ 1 to local APIC 0 > > > ioapic0: Assigning ISA IRQ 4 to local APIC 1 > > > ioapic0: Assigning ISA IRQ 6 to local APIC 2 > > > ioapic0: Assigning ISA IRQ 7 to local APIC 0 > > > ioapic0: Assigning ISA IRQ 9 to local APIC 1 > > > ioapic0: Assigning ISA IRQ 12 to local APIC 2 > > > ioapic0: Assigning ISA IRQ 14 to local APIC 0 > > > ioapic0: Assigning ISA PCI 16 to local APIC 1 > > > ioapic0: Assigning ISA PCI 17 to local APIC 2 > > > ioapic0: Assigning ISA PCI 18 to local APIC 0 > > > ioapic0: Assigning ISA PCI 19 to local APIC 1 > > > ioapic0: Assigning ISA PCI 22 to local APIC 2 > > > trying to mount root from ufs:/dev/ad4s1a > > > start_init: trying /sbin/init > > > [hung at this point] > > > > > > > > > 3) Many others have seen the hanging/lock-up after "mount root". I > > > > > > believe one found a workaround by setting ATA_STATIC_ID in their kernel > > > > > > configuration. I realise this is a problem when you can't get the > > > > > > system up to a point of building a kernel; chicken-and-egg problem, > > > > > > > > > > Well, I can build a kernel if I run the 7.0-release kernel. That's how I > > > > > got to 7-stable on the machine in the first place. I used "sneaker net" > > > > > to copy it to this one via a CD (as I mentioned, the 7.0 kernel boots > > > > > but the Realtek ethernet device is not recognized). > > > > > > > > So the problem is that 7.0-RELEASE works fine for you, but after > > > > upgrading your RELENG_7 source (to what is now 7.1-BETA), the machine > > > > hangs after printing the mount root message. Is this correct? > > > > > > Yes, that is pretty much it. The Realtek ethernet isn't working in in > > > 7.0-RELEASE either, but I'm guessing that that is a different (and less > > > serious) problem related to changes in that device. > > > > > > > Here's another question: does booting into single-user exhibit the same > > > > problem as multi-user? > > > > > > It looks like when I try a single-user mode (and verbose) boot the only > > > difference is that the las line shown above (the start_init line) isn't > > > printed. Otherwise, the hang is the same. > > > > > > > > > 4) The Realtek NIC on that motherboard is probably too new to be > > > > > > supported under RELENG_7. Realtek has a history of releasing different > > > > > > sub-revisions of the same NIC/PHY, and the internal changes are severe > > > > > > enough to cause the NIC to not work correctly (under any OS) without > > > > > > full driver support for that specific sub-revision. > > > > > > > > > > That's what I suspected. The values displayed when doing a "pciconf -lv" > > > > > are similar as for this system I'm using to type this, but now that > > > > > I look closer and make a direct comparison, the failing device has a > > > > > rev=0x02 vs. rev=0x01 for the working one. The pciconf -lv output for > > > > > the failing mb is: > > > > > > > > > > none3@pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 > > > > > vendor = 'Realtek Semiconductor' > > > > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > > > > class = network > > > > > subclass = ethernet > > > > > > > > Regarding the Realtek issue: I've CC'd PYUN Yong-Hyeon (surname in > > > > caps), who maintains the re(4) driver for FreeBSD. He might have a > > > > patch available for you to try, or help determine how to get this NIC > > > > working on FreeBSD. He'll probably need more than just pciconf -lv > > > > output, but should be able to work with you. > > > > > > Ok, that'd be great. I must say that I'm close to simply returning this > > > MB and going with something not quite so new that is more likely to > > > work. I was hoping to get this system up and running this weekend. :( > > > > I wish I knew what was causing the lock-up for you. I'm truly baffled, > > especially given that the system is able to boot + find the kernel + > > load kernel modules. Debugging this problem is out of field; jhb@ might > > have some ideas, as I'm not sure what magic happens immediately before > > the root filesystem is mounted. > > > > Those debugging/helping may want "disklabel -r -A ad4s1" output. At > > least you can boot 7.0-RELEASE to get that information. > > > > Regarding hardware: > > > > I myself purchased an Asus P5Q SE board, with an Intel Q9550 CPU earlier > > this week. The board was affordable (barely US$100). One of the > > reasons I went with this board is because it lacks a) Realtek NICs, b) > > Broadcom NICs, c) JMicron SATA controllers, and d) Silicon Image SATA > > controllers. All of those are devices I stay away from. > > > > The Atheros/Attansic L1E NIC is known to have issues under Vista (not > > sure if the issues are with Vista or the actual driver itself), but I > > use XP). FreeBSD supports this NIC under the age(4) driver, also > > maintained by Yong-Hyeon. Of course I haven't tested it yet. > > > > I'll be building the above system today, and will post the results of > > booting/installing FreeBSD on it as a test case. > > Well, I swapped motherboards to a slightly older but similar board with > pretty much identical results. This one's a Gigabyte GA-MA74GM-S2. I > was trying to stick with a MB that has onboard graphics (this is in a > 2u rack case and I don't have a riser card for it so there's no way to > install a video card currently). > > With this board it doesn't get quite as far even. It prints out all the > APIC messages as above then a GEOM message: > > GEOM: new disk ad4 > > And then hangs. Also, the ethernet NIC on this board is the same as the > previous one so it's not found either. > > Bob Wild guess, since it has happened to me often, check /boot/device.hints danny > > > > > -- > > | Jeremy Chadwick jdc at parodius.com | > > | Parodius Networking http://www.parodius.com/ | > > | UNIX Systems Administrator Mountain View, CA, USA | > > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > -- > Bob Willcox All the evidence concerning the universe > bob@immure.com has not yet been collected, so there's still hope. > Austin, TX > _______________________________________________ > 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 Sun Sep 21 05:30:46 2008 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 150861065675 for ; Sun, 21 Sep 2008 05:30:46 +0000 (UTC) (envelope-from brian@brianwhalen.net) Received: from entwistle.sonicboom.org (entwistle.sonicboom.org [66.93.34.170]) by mx1.freebsd.org (Postfix) with ESMTP id DA9FD8FC0C for ; Sun, 21 Sep 2008 05:30:45 +0000 (UTC) (envelope-from brian@brianwhalen.net) Received: from [127.0.0.1] (localhost.sonicboom.org [127.0.0.1]) by entwistle.sonicboom.org (8.14.2/8.14.2) with ESMTP id m8L5Uh67068257 for ; Sat, 20 Sep 2008 22:30:44 -0700 (PDT) (envelope-from brian@brianwhalen.net) Message-ID: <48D5DC03.40403@brianwhalen.net> Date: Sat, 20 Sep 2008 22:30:43 -0700 From: Brian User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <48173C85.1000107@brianwhalen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: freebsd 7 with sata drives 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, 21 Sep 2008 05:30:46 -0000 Brian wrote: > The board in question is an Asus M3A78-EMH HDMI. I have tried the > instructions for a safe kernel compile in /usr/src/updating also. > Even after that, the kernel starts to load, but the root partition > cant be found, and I am left at a mountroot> prompt. If I go > ufs:ad5s1a, that fails as well. > > Brian > I have done much more testing on this. With a pata drive all is well. I can install 7.0-release and run freebsd-update successfully including the subsequent reboots. However, over the weekend I tried to go to stable again, and still, the subsequent reboot leaves me at a mountroot prompt. If I go ufs:ad8s1a at the prompt the root partition, of course I dont want to have to do this each time. If I use the september snapshot, the sata disk is visible. I just tried to run and iinstall a 6.4 prerelease, and then did a make buildworld && make kernel KERNCONF=SMP and that worked successfully. I see this behavior with a 160 gig wd disk as well as a 74 gig raptor(This weekend's test hardware). Brian From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 08:57:57 2008 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 13AD81065675 for ; Sun, 21 Sep 2008 08:57:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D2CDB8FC87 for ; Sun, 21 Sep 2008 08:57:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 03DEC46C1C; Sun, 21 Sep 2008 04:57:53 -0400 (EDT) Date: Sun, 21 Sep 2008 09:57:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: netgeek In-Reply-To: <48D596AD.1070209@bgp4.net> Message-ID: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jo Rhett , freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 21 Sep 2008 08:57:57 -0000 On Sat, 20 Sep 2008, netgeek wrote: >> Don't get me wrong: I would love to see us support all releases for 24 >> months (or even more) after they ship. I think our users would appreciate >> that also. > > Perhaps there is a middle ground here? What about a statement that each > major branch (6.x, 7.x) will be supported for at least 24+ months from its > last production release? Smaller periods of support could be given to minor > releases along the way (7.2, for example), but at least companies would know > that if they installed a 6.x version, they'd have support for a couple of > years, even if that might mean upgrading to a newer minor version if there > was a problem. This is precisely what we already do -- we guarantee we will support the last release on a branch for 24 months after the release. The point of concern being discussed is that we can't tell you for sure which minor release will be the last release at the time that release goes out the door, because the extent to which we keep releasing on old branches depends in large part on how the new branch looks. Right now, it sounds like 6.4 will be the last minor release on the 6.x branch, but I think it would be a mistake to commit to that decision until 7.1 has settled in for a few months and we believe firmly there is a good migration path forwards to the 7.x branch. 7.0 was arguably one of the most stable .0 releases we've ever done (perhaps the most stable -- 4.0 was pretty good though), so it seem almost certain 7.1 will be really stable, but stable is what happens when people install it and it works well in practice, so there's always a wait-and-see element. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 09:54:32 2008 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 9C24710658F7 for ; Sun, 21 Sep 2008 09:54:32 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: from pinus.izb.knu.ac.kr (pinus.izb.knu.ac.kr [IPv6:2001:470:1f05:5f6:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3E48FC18 for ; Sun, 21 Sep 2008 09:54:32 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: by pinus.izb.knu.ac.kr (Postfix, from userid 59) id 370063EA4; Sun, 21 Sep 2008 18:54:28 +0900 (KST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on pinus.izb.knu.ac.kr X-Spam-Level: X-Spam-Status: No, score=-48.6 required=15.1 tests=DKIM_SIGNED,DKIM_VERIFIED autolearn=disabled version=3.2.3 Received: from pinus.izb.knu.ac.kr (localhost.izb.knu.ac.kr [127.0.0.1]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id 53E973EA0; Sun, 21 Sep 2008 18:54:21 +0900 (KST) Comment: DKIM? See http://www.google.com/search?btnI&q=RFC+4871 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=izb.knu.ac.kr; h=subject :from:to:content-type:date:message-id:mime-version: content-transfer-encoding; s=s1024; bh=bWovsMdo7/RvYhcIm5dHFKDEx kBqKZCxexJ4UL7O0rk=; b=P/3IxDq1qiJ0LDIK47E7mN1Hh2hK/JW5ipJcKe9JM eNUSuxtFembWEExJAmNNUjRywZORfYekOvJhIdqgSxCygUs9eADP/fahJlzK7vbn xK/Bx0stWVO8NtVL9aamodZmPf7BU3n4i69Jti+HRsPtAm2/mjAd3YByGmBXBWV5 Rs= Received: from [IPv6:2001:470:1f05:5f8:3::2] (phyll.izb.knu.ac.kr [IPv6:2001:470:1f05:5f8:3::2]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id C6E413E98; Sun, 21 Sep 2008 18:54:19 +0900 (KST) From: Byung-Hee HWANG To: stable@freebsd.org Content-Type: text/plain Organization: InZealBomb Date: Sun, 21 Sep 2008 18:54:23 +0900 Message-Id: <1221990863.929.21.camel@phyll.izb.knu.ac.kr> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: easy way to upgrade from 6.3 to 7.1 (including port packages) 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, 21 Sep 2008 09:54:32 -0000 in my experience, in usual kernel && userland upgrading is good, however, everytime port upgrading have problem, whenever new -REL is released ;; i usually do port upgrading by portupgrade(1). at once(when 6.2-REL was released) i did upgrading port by portupgrade(1) but i met failures on the upgrading. then i did `pkg_delete -af` and then i did installation all packages by pkg_add(1) cause at that time the packages were twisted each other roughly ;; so is there any easy way to upgrade packages ?? can you please help me about this matters? byunghee -- "And I ain't gonna change." -- Nino Valenti, "Chapter 13", page 184 From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 10:22:46 2008 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 C9A8A1065673 for ; Sun, 21 Sep 2008 10:22:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A219E8FC0C for ; Sun, 21 Sep 2008 10:22:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 0D29046B0C; Sun, 21 Sep 2008 06:22:46 -0400 (EDT) Date: Sun, 21 Sep 2008 11:22:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Vlad GALU In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable List Subject: Re: BPF plans for 7.1 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, 21 Sep 2008 10:22:46 -0000 On Sat, 20 Sep 2008, Vlad GALU wrote: > Will the zero-copy bpf(4) changes be merged to the stable branch before > the release? Dear Vlad: Unfortunately, no. The code seems stable in 8-CURRENT, but I don't feel it's had enough actual testing exposure to go into 7.x yet. Also, the libpcap changes to support it have only just gone back into the tcpdump.org distribution of libpcap, and there is non-trivial reworking of that code, so we'd like to let that settle as well. We've had a number of queries so I suspect we'll start maintaining a 7.x MFC candidate patch fairly soon (next couple of months). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 10:29:57 2008 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 0D817106566C; Sun, 21 Sep 2008 10:29:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6003E8FC0C; Sun, 21 Sep 2008 10:29:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 0D52646B0C; Sun, 21 Sep 2008 06:29:55 -0400 (EDT) Date: Sun, 21 Sep 2008 11:29:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Simon L. Nielsen" In-Reply-To: <20080920205645.GI1151@arthur.nitro.dk> Message-ID: References: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <20080920020703.GA82392@phat.za.net> <851F09A2-788D-4343-9E00-A0AB5C3AC063@netconsonance.com> <4d7dd86f0809192057s33dfd92fv598488a4c05ada14@mail.gmail.com> <4B2A556D-B13D-4B71-819A-F9B23C5685AF@netconsonance.com> <20080920205645.GI1151@arthur.nitro.dk> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jo Rhett , freebsd-stable Subject: Re: Upcoming Releases Schedule... 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, 21 Sep 2008 10:29:57 -0000 On Sat, 20 Sep 2008, Simon L. Nielsen wrote: > - The more branches are supported, the more versions of both third > party code and FreeBSD code need to be supported and the more likely > it is that the software differs meaning that we need to adopt the > fix to the branch. The real painful case for this was > FreeBSD-SA-07:01.jail which AFAIR needed 6 different patches. This > is one of the largest time cost with support many branches as this > is by no means a linear cost. The older a branch is, the more > likely it is that the code is much different than newer FreeBSD > versions. > > This also the reason secteam was very happy when we could > discontinue FreeBSD 4 support as it was significantly different from > FreeBSD 5+. In that respect supporting FreeBSD 5 in the end was > much cheaper than supporting FreeBSD 4 in the end. Of course this > is less likely to be a problem in the future like it was with > FreeBSD 4, but still - FreeBSD 5 and FreeBSD 8 are rather different > and would not be fun to support both. Let me give an example from a slightly older branch here as well: we de-supported FreeBSD 3.x for "local" security vulnerabilities because we hit the libncurses security vulnerability. The only real option to pick up the fix was to adopt new version of libncurses, and that radically changed the libcurses API (part of the fix). This, in turn, cascaded into other applications, such as top, vi, etc, which all use ncurses, so the net effect would have been not just a significant API change, but also modifications to countless system utilities. Such a change might not even be appropriate for a minor branch, let alone a security branch where we try to ensure minimalist fixes to avoid security patches leading to other potential regressions. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 10:40:11 2008 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 6EC721065671 for ; Sun, 21 Sep 2008 10:40:11 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from goat.gigo.com (ipv6.gigo.com [IPv6:2001:470:1:18::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2C58FC12 for ; Sun, 21 Sep 2008 10:40:11 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from 201.88.58.13 (201-88-58-13.bsace702.dsl.brasiltelecom.net.br [201.88.58.13]) by goat.gigo.com (Postfix) with ESMTPA id B1F4017047 for ; Sun, 21 Sep 2008 03:40:10 -0700 (PDT) Received: (qmail 74733 invoked by uid 1001); 21 Sep 2008 07:39:40 -0300 Message-ID: <20080921103940.74650.qmail@exxodus.fedaykin.here> Date: Sun, 21 Sep 2008 07:39:40 -0300 From: Mario Sergio Fujikawa Ferreira To: freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: FreeBSD 7.1-PRERELEASE panic rw_rlock (udpinp) 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, 21 Sep 2008 10:40:11 -0000 Hi, I've been running FreeBSD 7.0-STABLE from August 1 without problems. I tried updating to the latest -STABLE but I got a system panic. ---- panic: _rw_rlock (udpinp): wlock already held @ /usr/src/sys/netinet/udp_usrreq.c ---- FreeBSD 7.1-PRERELEASE #18: Sat Sep 20 23:38:22 BRT 2008 Regards, Mario Ferreira ---- - Kernel configuration http://people.freebsd.org/~lioux/panic/2008092100/KERNCONF - syslog output http://people.freebsd.org/~lioux/panic/2008092100/all.log http://people.freebsd.org/~lioux/panic/2008092100/messages - dmesg.boot http://people.freebsd.org/~lioux/panic/2008092100/dmesg.boot - kldstat http://people.freebsd.org/~lioux/panic/2008092100/kldstat.txt - /boot/loader.conf http://people.freebsd.org/~lioux/panic/2008092100/loader.conf - 'pciconf -lv' http://people.freebsd.org/~lioux/panic/2008092100/pciconf.txt - 'sysctl -a' http://people.freebsd.org/~lioux/panic/2008092100/sysctl.txt - /etc/sysctl.conf http://people.freebsd.org/~lioux/panic/2008092100/sysctl.conf -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 10:44:07 2008 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 84F111065682 for ; Sun, 21 Sep 2008 10:44:07 +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 2E64A8FC0A for ; Sun, 21 Sep 2008 10:44:06 +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 <0K7J00736KHG78E0@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Sep 2008 12:44:05 +0200 (CEST) Received: from kg-work2.kg4.no ([80.202.72.201]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0K7J001NEKHFY6H0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Sep 2008 12:44:04 +0200 (CEST) Date: Sun, 21 Sep 2008 12:44:03 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20080921124403.5ad118a7.torfinn.ingolfsen@broadpark.no> In-reply-to: <48D2D744.40304@FreeBSD.org> References: <20080918075306.GA30709@lpthe.jussieu.fr> <200809181618.m8IGIj2P050390@lurza.secnetix.de> <20080918183250.GA48347@lpthe.jussieu.fr> <48D2D744.40304@FreeBSD.org> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) 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: floppy disk controller broken 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, 21 Sep 2008 10:44:07 -0000 On Thu, 18 Sep 2008 23:33:40 +0100 "Bruce M. Simpson" wrote: > Someone was going to pick this up, finish it off, and commit it, but > I haven't heard back from them: > http://people.freebsd.org/~bms/dump/tools/ufdformat/ It compiled fine on FreeBSD 7.0-stable: tingo@kg-work2$ uname -a FreeBSD kg-work2.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Jul 21 20:40:31 CEST 2008 root@kg-work2.kg4.no:/usr/obj/usr/src/sys/GENERIC i386 But when I tried to use, it printed two 'V''s and then seemed to be doing nothing. In /var/log/messages I got these: Sep 21 12:09:35 kg-work2 kernel: umass0: CBI reset failed, TIMEOUT Sep 21 12:09:40 kg-work2 kernel: umass0: CBI bulk-in stall clear failed, TIMEOUT Sep 21 12:09:45 kg-work2 kernel: umass0: CBI bulk-out stall clear failed, TIMEOUT Sep 21 12:11:55 kg-work2 kernel: umass0: CBI reset failed, TIMEOUT Sep 21 12:13:00 kg-work2 kernel: umass0: CBI bulk-in stall clear failed, TIMEOUT Sep 21 12:14:05 kg-work2 kernel: umass0: CBI bulk-out stall clear failed, TIMEOUT Sep 21 12:16:15 kg-work2 kernel: umass0: CBI reset failed, TIMEOUT The funny thing is - that situation seemed to vlock commands from executing, or the terminals from printing outrput. I had several terminal windows up, and a ssh session from another machine. I could type a command, but nothing would happen after I pressed enter. Switching workspaces in X and switching vty's worked fine. In the end, I had to yank the floppy (which panicked the machine as expected). The floppy I used was this one: Sep 21 11:45:58 kg-work2 root: Unknown USB device: vendor 0x0644 product 0x0000 bus uhub1 Sep 21 11:45:59 kg-work2 kernel: umass0: on uhub1 Sep 21 11:45:59 kg-work2 kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Sep 21 11:45:59 kg-work2 kernel: da0: Removable Direct Access SCSI-0 device Sep 21 11:45:59 kg-work2 kernel: da0: 1.000MB/s transfers I will try ufdformat on a different machine now. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 10:48:29 2008 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 0FB48106566B for ; Sun, 21 Sep 2008 10:48:29 +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 716508FC12; Sun, 21 Sep 2008 10:48:28 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48D6268A.3090805@FreeBSD.org> Date: Sun, 21 Sep 2008 11:48:42 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Mario Sergio Fujikawa Ferreira References: <20080921103940.74650.qmail@exxodus.fedaykin.here> In-Reply-To: <20080921103940.74650.qmail@exxodus.fedaykin.here> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 7.1-PRERELEASE panic rw_rlock (udpinp) 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, 21 Sep 2008 10:48:29 -0000 Mario Sergio Fujikawa Ferreira wrote: > Hi, > > I've been running FreeBSD 7.0-STABLE from August 1 without problems. > > I tried updating to the latest -STABLE but I got a system panic. > > ---- > panic: _rw_rlock (udpinp): wlock already held @ /usr/src/sys/netinet/udp_usrreq.c > ---- > > FreeBSD 7.1-PRERELEASE #18: Sat Sep 20 23:38:22 BRT 2008 > > Regards, > Mario Ferreira > > ---- > > - Kernel configuration > http://people.freebsd.org/~lioux/panic/2008092100/KERNCONF > > - syslog output > http://people.freebsd.org/~lioux/panic/2008092100/all.log > http://people.freebsd.org/~lioux/panic/2008092100/messages > > - dmesg.boot > http://people.freebsd.org/~lioux/panic/2008092100/dmesg.boot > > - kldstat > http://people.freebsd.org/~lioux/panic/2008092100/kldstat.txt > > - /boot/loader.conf > http://people.freebsd.org/~lioux/panic/2008092100/loader.conf > > - 'pciconf -lv' > http://people.freebsd.org/~lioux/panic/2008092100/pciconf.txt > > - 'sysctl -a' > http://people.freebsd.org/~lioux/panic/2008092100/sysctl.txt > > - /etc/sysctl.conf > http://people.freebsd.org/~lioux/panic/2008092100/sysctl.conf > - gdb backtrace? Kris From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 11:16:57 2008 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 4D1E81065680 for ; Sun, 21 Sep 2008 11:16:57 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from goat.gigo.com (ipv6.gigo.com [IPv6:2001:470:1:18::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1BA768FC16 for ; Sun, 21 Sep 2008 11:16:57 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from 201.88.58.13 (201-88-58-13.bsace702.dsl.brasiltelecom.net.br [201.88.58.13]) by goat.gigo.com (Postfix) with ESMTPA id 274E817047 for ; Sun, 21 Sep 2008 04:16:56 -0700 (PDT) Received: (qmail 79634 invoked by uid 1001); 21 Sep 2008 08:16:41 -0300 Message-ID: <20080921111641.79555.qmail@exxodus.fedaykin.here> Date: Sun, 21 Sep 2008 08:16:41 -0300 From: Mario Sergio Fujikawa Ferreira To: Kris Kennaway References: <20080921103940.74650.qmail@exxodus.fedaykin.here> <48D6268A.3090805@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48D6268A.3090805@FreeBSD.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 7.1-PRERELEASE panic rw_rlock (udpinp) 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, 21 Sep 2008 11:16:57 -0000 On Sun, Sep 21, 2008 at 11:48:19AM +0100, Kris Kennaway wrote: > Mario Sergio Fujikawa Ferreira wrote: > > Hi, > > > > I've been running FreeBSD 7.0-STABLE from August 1 without problems. > > > > I tried updating to the latest -STABLE but I got a system panic. > > > > ---- > > panic: _rw_rlock (udpinp): wlock already held @ /usr/src/sys/netinet/udp_usrreq.c > > ---- > > > > FreeBSD 7.1-PRERELEASE #18: Sat Sep 20 23:38:22 BRT 2008 > > > > Regards, > > Mario Ferreira > > > > ---- > > > > - Kernel configuration > > http://people.freebsd.org/~lioux/panic/2008092100/KERNCONF > > > > - syslog output > > http://people.freebsd.org/~lioux/panic/2008092100/all.log > > http://people.freebsd.org/~lioux/panic/2008092100/messages > > > > - dmesg.boot > > http://people.freebsd.org/~lioux/panic/2008092100/dmesg.boot > > > > - kldstat > > http://people.freebsd.org/~lioux/panic/2008092100/kldstat.txt > > > > - /boot/loader.conf > > http://people.freebsd.org/~lioux/panic/2008092100/loader.conf > > > > - 'pciconf -lv' > > http://people.freebsd.org/~lioux/panic/2008092100/pciconf.txt > > > > - 'sysctl -a' > > http://people.freebsd.org/~lioux/panic/2008092100/sysctl.txt > > > > - /etc/sysctl.conf > > http://people.freebsd.org/~lioux/panic/2008092100/sysctl.conf > > > > - gdb backtrace? I had a hard lock there. I got the system panic but it locked instead of dumping core. I had to remove the power cord to reboot it. I do not have much experience with kernel traces. How do I force a backtrace? Any unattended ddb scripts? Regards, Mario Ferreira -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 12:09:43 2008 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 33A1F1065670 for ; Sun, 21 Sep 2008 12:09:43 +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 927C88FC13; Sun, 21 Sep 2008 12:09:42 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48D63994.20607@FreeBSD.org> Date: Sun, 21 Sep 2008 13:09:56 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Mario Sergio Fujikawa Ferreira References: <20080921103940.74650.qmail@exxodus.fedaykin.here> <48D6268A.3090805@FreeBSD.org> <20080921111641.79555.qmail@exxodus.fedaykin.here> In-Reply-To: <20080921111641.79555.qmail@exxodus.fedaykin.here> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 7.1-PRERELEASE panic rw_rlock (udpinp) 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, 21 Sep 2008 12:09:43 -0000 Mario Sergio Fujikawa Ferreira wrote: > On Sun, Sep 21, 2008 at 11:48:19AM +0100, Kris Kennaway wrote: >> Mario Sergio Fujikawa Ferreira wrote: >>> Hi, >>> >>> I've been running FreeBSD 7.0-STABLE from August 1 without problems. >>> >>> I tried updating to the latest -STABLE but I got a system panic. >>> >>> ---- >>> panic: _rw_rlock (udpinp): wlock already held @ /usr/src/sys/netinet/udp_usrreq.c >>> ---- >>> >>> FreeBSD 7.1-PRERELEASE #18: Sat Sep 20 23:38:22 BRT 2008 >>> >>> Regards, >>> Mario Ferreira >>> >>> ---- >>> >>> - Kernel configuration >>> http://people.freebsd.org/~lioux/panic/2008092100/KERNCONF >>> >>> - syslog output >>> http://people.freebsd.org/~lioux/panic/2008092100/all.log >>> http://people.freebsd.org/~lioux/panic/2008092100/messages >>> >>> - dmesg.boot >>> http://people.freebsd.org/~lioux/panic/2008092100/dmesg.boot >>> >>> - kldstat >>> http://people.freebsd.org/~lioux/panic/2008092100/kldstat.txt >>> >>> - /boot/loader.conf >>> http://people.freebsd.org/~lioux/panic/2008092100/loader.conf >>> >>> - 'pciconf -lv' >>> http://people.freebsd.org/~lioux/panic/2008092100/pciconf.txt >>> >>> - 'sysctl -a' >>> http://people.freebsd.org/~lioux/panic/2008092100/sysctl.txt >>> >>> - /etc/sysctl.conf >>> http://people.freebsd.org/~lioux/panic/2008092100/sysctl.conf >>> >> - gdb backtrace? > > I had a hard lock there. I got the system panic but it > locked instead of dumping core. I had to remove the power cord to > reboot it. > > I do not have much experience with kernel traces. How do I > force a backtrace? Any unattended ddb scripts? See the developers handbook. Kris From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 13:45:32 2008 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 245E01065671 for ; Sun, 21 Sep 2008 13:45:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0735E8FC12 for ; Sun, 21 Sep 2008 13:45:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id HR3i1a00617UAYkA4RlWlJ; Sun, 21 Sep 2008 13:45:30 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id HRlV1a00D4v8bD78ZRlWUz; Sun, 21 Sep 2008 13:45:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=Es38nrSLPvPHbvKPtmIA:9 a=D9qE4ss_qS73mM-M0pkA:7 a=aLWW3mwk4YHkqSumaj9GG7J4Nr4A:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 6105B17B81A; Sun, 21 Sep 2008 06:45:29 -0700 (PDT) Date: Sun, 21 Sep 2008 06:45:29 -0700 From: Jeremy Chadwick To: Torfinn Ingolfsen Message-ID: <20080921134529.GA977@icarus.home.lan> References: <20080918075306.GA30709@lpthe.jussieu.fr> <200809181618.m8IGIj2P050390@lurza.secnetix.de> <20080918183250.GA48347@lpthe.jussieu.fr> <48D2D744.40304@FreeBSD.org> <20080921124403.5ad118a7.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080921124403.5ad118a7.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: floppy disk controller broken 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, 21 Sep 2008 13:45:32 -0000 On Sun, Sep 21, 2008 at 12:44:03PM +0200, Torfinn Ingolfsen wrote: > On Thu, 18 Sep 2008 23:33:40 +0100 > "Bruce M. Simpson" wrote: > > > Someone was going to pick this up, finish it off, and commit it, but > > I haven't heard back from them: > > http://people.freebsd.org/~bms/dump/tools/ufdformat/ > > It compiled fine on FreeBSD 7.0-stable: > tingo@kg-work2$ uname -a > FreeBSD kg-work2.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Jul 21 > 20:40:31 CEST 2008 > root@kg-work2.kg4.no:/usr/obj/usr/src/sys/GENERIC i386 > > But when I tried to use, it printed two 'V''s and then seemed to be > doing nothing. > > In /var/log/messages I got these: > Sep 21 12:09:35 kg-work2 kernel: umass0: CBI reset failed, TIMEOUT > Sep 21 12:09:40 kg-work2 kernel: umass0: CBI bulk-in stall clear failed, TIMEOUT > Sep 21 12:09:45 kg-work2 kernel: umass0: CBI bulk-out stall clear failed, TIMEOUT > Sep 21 12:11:55 kg-work2 kernel: umass0: CBI reset failed, TIMEOUT > Sep 21 12:13:00 kg-work2 kernel: umass0: CBI bulk-in stall clear failed, TIMEOUT > Sep 21 12:14:05 kg-work2 kernel: umass0: CBI bulk-out stall clear failed, TIMEOUT > Sep 21 12:16:15 kg-work2 kernel: umass0: CBI reset failed, TIMEOUT Remove "device udbp" from your kernel configuration and try again. The problem with bulk pipes is somewhat well-known at this point. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 13:49:39 2008 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 44A511065674 for ; Sun, 21 Sep 2008 13:49:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 291318FC14 for ; Sun, 21 Sep 2008 13:49:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id HNvz1a00B0S2fkCA9RpeNv; Sun, 21 Sep 2008 13:49:38 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id HRpd1a0074v8bD78VRpd2y; Sun, 21 Sep 2008 13:49:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=j-pHpBAHbf4A:10 a=QycZ5dHgAAAA:8 a=QsZEEC68cXKfIhRTLAAA:9 a=Wj3RQzAjbnu5TvWoaqRBkE_COMIA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 69A0917B81A; Sun, 21 Sep 2008 06:49:37 -0700 (PDT) Date: Sun, 21 Sep 2008 06:49:37 -0700 From: Jeremy Chadwick To: yusuf =?iso-8859-1?Q?=F6zbilgin?= Message-ID: <20080921134937.GB977@icarus.home.lan> References: <20080920225314.GA84482@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd custom installation cd 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, 21 Sep 2008 13:49:39 -0000 On Sun, Sep 21, 2008 at 04:47:57AM +0300, yusuf özbilgin wrote: > I added kernel configuration as attachment. > > When I boot system via freebsd live cd > > at boot process > > .... > hptrr: no controller detected. > acd0:DVDR at ata2-master UDMA66 > ad16: 476938MB at ata8-master SATA300 > > then everthing is ok. > > but when I boot via custom installation cd; > > ad16 is not listed at boot screen. then saying no disk at fdisk section. > > I think there is missing kernel module but I couldnt find it. This isn't enough information. We need to see what ata8-master is associated with, device-wise. That means tracking it down like this: ata8-master --> ata8 --> atapciXX We need to see the dmesg information for all of those. Chances are the disk falls under ata(4), but I'm not sure. A brief glimpse shows your kernel configuration looks fine, although incredibly bloated. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 13:51:15 2008 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 D95341065677 for ; Sun, 21 Sep 2008 13:51:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id BEA278FC15 for ; Sun, 21 Sep 2008 13:51:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id HQ8A1a0040lTkoCA4RrFXH; Sun, 21 Sep 2008 13:51:15 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id HRrE1a0084v8bD78QRrEWG; Sun, 21 Sep 2008 13:51:15 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=skJDNnjcuNYz2PMr5qoA:9 a=NL_4djSsY5wA9PUgQtoA:7 a=WXw1soPsTJzRqeXiqM7OpLSmpoAA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 7EAF917B81A; Sun, 21 Sep 2008 06:51:14 -0700 (PDT) Date: Sun, 21 Sep 2008 06:51:14 -0700 From: Jeremy Chadwick To: Brian Message-ID: <20080921135114.GA1108@icarus.home.lan> References: <48173C85.1000107@brianwhalen.net> <48D5DC03.40403@brianwhalen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48D5DC03.40403@brianwhalen.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: freebsd 7 with sata drives 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, 21 Sep 2008 13:51:15 -0000 On Sat, Sep 20, 2008 at 10:30:43PM -0700, Brian wrote: > Brian wrote: >> The board in question is an Asus M3A78-EMH HDMI. I have tried the >> instructions for a safe kernel compile in /usr/src/updating also. >> Even after that, the kernel starts to load, but the root partition >> cant be found, and I am left at a mountroot> prompt. If I go >> ufs:ad5s1a, that fails as well. >> >> Brian >> > I have done much more testing on this. With a pata drive all is well. > I can install 7.0-release and run freebsd-update successfully including > the subsequent reboots. However, over the weekend I tried to go to > stable again, and still, the subsequent reboot leaves me at a mountroot > prompt. If I go ufs:ad8s1a at the prompt the root partition, of course > I dont want to have to do this each time. If I use the september > snapshot, the sata disk is visible. I just tried to run and iinstall a > 6.4 prerelease, and then did a make buildworld && make kernel > KERNCONF=SMP and that worked successfully. I see this behavior with a > 160 gig wd disk as well as a 74 gig raptor(This weekend's test hardware). Others are having this problem, though not prompted with a mountroot> prompt (others are experiencing a hard system lock-up after the "Mount root from ufs..." message. I doubt the problem is you. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 14:35:00 2008 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 8B63F1065670 for ; Sun, 21 Sep 2008 14:35:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 651F08FC15 for ; Sun, 21 Sep 2008 14:35:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 0281446B8D; Sun, 21 Sep 2008 10:35:00 -0400 (EDT) Date: Sun, 21 Sep 2008 15:34:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mario Sergio Fujikawa Ferreira In-Reply-To: <20080921103940.74650.qmail@exxodus.fedaykin.here> Message-ID: References: <20080921103940.74650.qmail@exxodus.fedaykin.here> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 7.1-PRERELEASE panic rw_rlock (udpinp) 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, 21 Sep 2008 14:35:00 -0000 On Sun, 21 Sep 2008, Mario Sergio Fujikawa Ferreira wrote: > I've been running FreeBSD 7.0-STABLE from August 1 without problems. > > I tried updating to the latest -STABLE but I got a system panic. Hi Mario-- This is a known problem, and will hopefully be resolved shortly. In essence, the v4 compatibility path for v6 socket is invoking the v4 code with locks held that upset the v4 code. Robert N M Watson Computer Laboratory University of Cambridge > > ---- > panic: _rw_rlock (udpinp): wlock already held @ /usr/src/sys/netinet/udp_usrreq.c > ---- > > FreeBSD 7.1-PRERELEASE #18: Sat Sep 20 23:38:22 BRT 2008 > > Regards, > Mario Ferreira > > ---- > > - Kernel configuration > http://people.freebsd.org/~lioux/panic/2008092100/KERNCONF > > - syslog output > http://people.freebsd.org/~lioux/panic/2008092100/all.log > http://people.freebsd.org/~lioux/panic/2008092100/messages > > - dmesg.boot > http://people.freebsd.org/~lioux/panic/2008092100/dmesg.boot > > - kldstat > http://people.freebsd.org/~lioux/panic/2008092100/kldstat.txt > > - /boot/loader.conf > http://people.freebsd.org/~lioux/panic/2008092100/loader.conf > > - 'pciconf -lv' > http://people.freebsd.org/~lioux/panic/2008092100/pciconf.txt > > - 'sysctl -a' > http://people.freebsd.org/~lioux/panic/2008092100/sysctl.txt > > - /etc/sysctl.conf > http://people.freebsd.org/~lioux/panic/2008092100/sysctl.conf > > -- > Mario S F Ferreira - DF - Brazil - "I guess this is a signature." > feature, n: a documented bug | bug, n: an undocumented feature > _______________________________________________ > 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 Sun Sep 21 14:57:19 2008 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 6B7611065678; Sun, 21 Sep 2008 14:57:19 +0000 (UTC) (envelope-from bob@immure.com) Received: from maul.immure.com (adsl-66-136-206-1.dsl.austtx.swbell.net [66.136.206.1]) by mx1.freebsd.org (Postfix) with ESMTP id 25CE18FC1F; Sun, 21 Sep 2008 14:57:18 +0000 (UTC) (envelope-from bob@immure.com) Received: from rancor.immure.com (rancor.immure.com [10.1.132.9]) by maul.immure.com (8.14.2/8.14.2) with ESMTP id m8LEvFd2030712; Sun, 21 Sep 2008 09:57:15 -0500 (CDT) (envelope-from bob@immure.com) Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.14.2/8.14.2) with ESMTP id m8LEvFP1021651; Sun, 21 Sep 2008 09:57:15 -0500 (CDT) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.14.2/8.13.8/Submit) id m8LEvFWH021650; Sun, 21 Sep 2008 09:57:15 -0500 (CDT) (envelope-from bob) Date: Sun, 21 Sep 2008 09:57:15 -0500 From: Bob Willcox To: Jeremy Chadwick Message-ID: <20080921145715.GD15275@rancor.immure.com> References: <20080920042418.GB1322@rancor.immure.com> <20080920123914.GA72833@icarus.home.lan> <20080920132429.GA15275@rancor.immure.com> <20080920140456.GA74663@icarus.home.lan> <20080920144510.GB15275@rancor.immure.com> <20080920150533.GA75785@icarus.home.lan> <20080920185024.GC15275@rancor.immure.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080920185024.GC15275@rancor.immure.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-immure-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: m8LEvFd2030712 X-immure-MailScanner: Found to be clean X-immure-MailScanner-From: bob@immure.com X-Spam-Status: No Cc: PYUN Yong-Hyeon , freebsd-stable@freebsd.org Subject: Re: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB - maybe the 8650? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Willcox List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2008 14:57:19 -0000 On Sat, Sep 20, 2008 at 01:50:24PM -0500, Bob Willcox wrote: > On Sat, Sep 20, 2008 at 08:05:33AM -0700, Jeremy Chadwick wrote: > > On Sat, Sep 20, 2008 at 09:45:10AM -0500, Bob Willcox wrote: > > > On Sat, Sep 20, 2008 at 07:04:56AM -0700, Jeremy Chadwick wrote: > > > > On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: [snip] I have since tried installing the 7.1 BETA on a system with the same CPU (a Phenom 8650 X3) and a different motherboard that I have had success running 7.1-PRELEASE on (the system I'm typing this message on, though it has a Phenom 9850 X4) and it still hangs at appx the same point (after enabling the second & third processors). Is there anyone else out there having problems with this CPU on 7.1? Bob -- Bob Willcox All the evidence concerning the universe bob@immure.com has not yet been collected, so there's still hope. Austin, TX From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 15:39:07 2008 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 7095B106564A for ; Sun, 21 Sep 2008 15:39:07 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8F38FC16 for ; Sun, 21 Sep 2008 15:39:07 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1190541wfg.7 for ; Sun, 21 Sep 2008 08:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=jMbjXMNXEzieX1WTbnUfnt1wyv8ZY6Kt+4JX6iR4HLE=; b=EPel9dx/4OYXMFKO1hf7MxXe62RpWkU38MG3hMsiC7AAwjUPLTUWOwRW1rJZmUJRhr aBrc8iE0HTiFSTGwrYZQvZeH6pfMpTHyVnw9v+3TtfrVFejf/Gb0lmTBIODnT9DvUVrm aavufI0gvnb06BptsaAsLloWrD2fr8hzqebHU= 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=nSxcHDLFt+B2BW1Gzl2NyazLzVGb+2MB5pq7+Pgy9TESgnvl/6F6ohVEDtBN6HtLE/ gG/y1YQeChEUr7DZnreV5PNqK+uE1vtVKX4Aw8rgzp18RvdQLPzX20fGVEqfHFujtHI8 jmUrQ/lf83TXxUAAuXU6F+uEmM5+9nRjZ6aHs= Received: by 10.143.32.7 with SMTP id k7mr955546wfj.305.1222011546978; Sun, 21 Sep 2008 08:39:06 -0700 (PDT) Received: by 10.142.222.16 with HTTP; Sun, 21 Sep 2008 08:39:06 -0700 (PDT) Message-ID: <47d0403c0809210839t391b623co3a3a907257c1b315@mail.gmail.com> Date: Sun, 21 Sep 2008 11:39:06 -0400 From: "Ben Kaduk" To: "Aristedes Maniatis" In-Reply-To: <64D99803-C832-42B6-90EF-D46D29E395E6@ish.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> <64D99803-C832-42B6-90EF-D46D29E395E6@ish.com.au> Cc: Jo Rhett , Robert Watson , freebsd-stable Subject: Re: Upcoming Releases Schedule... 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, 21 Sep 2008 15:39:07 -0000 On Sat, Sep 20, 2008 at 9:52 PM, Aristedes Maniatis wrote: > > On 21/09/2008, at 10:34 AM, netgeek wrote: > >> Perhaps there is a middle ground here? What about a statement that each >> major branch (6.x, 7.x) will be supported for at least 24+ months from its >> last production release? Smaller periods of support could be given to minor >> releases along the way (7.2, for example), but at least companies would know >> that if they installed a 6.x version, they'd have support for a couple of >> years, even if that might mean upgrading to a newer minor version if there >> was a problem. > > This is already the case [1]. From each major branch one or more releases > are designated as 'extended' and supported for 24 months. All you have to do > is pick one of those and you've got support for 24 months. For example 6.3 > has extended support in this way. > > RELENG_6 itself will be supported 24 months after the last release. Given > roughly 18 months between major releases and about 12 months of ongoing > releases from the previous branch after that, 4.5 years is roughly how long > each major branch is supported for. That is already clear as could be. I > can't quite understand what Jo Rhett is offering to the community that he is > upset isn't being taken up. I think he wants some other arbitrary point > release to be given extended support, either because in his case 24 months > is not enough, or because he wants every release to have 24 months of > support, or something else, I'm not sure. I think mostly, he just wants to know in advance which releases will have 24 months of support. Also, it would be very nice if those releases overlapped, so that one can jump from one long-tem-support release to the next. > > Jo, you say that he have had to maintain your own patched build of old > FreeBSD releases because you need to keep them in production for longer than > EoL period. Can I suggest that the first step is for you to publish those > patches somewhere public and allow others to have access to them. Then I'll second that. -Ben Kaduk > you'll have a chance of convincing others to contribute to your patch sets > and eventually of convincing FreeBSD to officially sanction them. Go and > create a new sourceforge project or convince your boss to set aside some > space on his web site/svn server/etc for this project. Tell him that if it > goes well, you'll be creating a whole lot of good will for the company in > addition to the prospect of getting other people to contribute and share the > work. > > > Ari Maniatis > > > > [1] http://security.freebsd.org/ > > > > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > > _______________________________________________ > freebsd-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 Sun Sep 21 16:35:21 2008 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 3B2DE106564A for ; Sun, 21 Sep 2008 16:35:21 +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 EA06A8FC22 for ; Sun, 21 Sep 2008 16:35:20 +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 <0K7K00DXH0O4DV80@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Sep 2008 18:33:40 +0200 (CEST) Received: from kg-work2.kg4.no ([80.202.72.201]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0K7K001AS0O4Y6U1@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Sep 2008 18:33:40 +0200 (CEST) Date: Sun, 21 Sep 2008 18:33:39 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20080921183339.1fb39588.torfinn.ingolfsen@broadpark.no> In-reply-to: <20080921124403.5ad118a7.torfinn.ingolfsen@broadpark.no> References: <20080918075306.GA30709@lpthe.jussieu.fr> <200809181618.m8IGIj2P050390@lurza.secnetix.de> <20080918183250.GA48347@lpthe.jussieu.fr> <48D2D744.40304@FreeBSD.org> <20080921124403.5ad118a7.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) 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: floppy disk controller broken 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, 21 Sep 2008 16:35:21 -0000 On Sun, 21 Sep 2008 12:44:03 +0200 Torfinn Ingolfsen wrote: > I will try ufdformat on a different machine now. Ok, on a different machine[1], it works without problems: root@kg-i82# uname -a FreeBSD kg-i82.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #3: Wed May 28 15:59:38 CEST 2008 root@kg-i82.kg4.no:/usr/obj/usr/src/sys/I81K i386 root@kg-i82# ./ufdformat da0 Geometry: 80 cyl 2 heads 18 secpercyl 512 bytespersec current: 2880 blocks, 512 bytes-per-block formatted 0: 2880 blocks, 512 bytes-per-block 1: 1232 blocks, 1024 bytes-per-block 2: 2400 blocks, 512 bytes-per-block Format 1440K floppy `da0'? (y/n): y Processing VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV done. Why it didn't work on the first machine[2] I don't know. References: 1) http://tingox.googlepages.com/i81k 2) http://tingox.googlepages.com/sx270 -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 16:58:24 2008 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 E77541065672 for ; Sun, 21 Sep 2008 16:58:24 +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 A4AD28FC0A for ; Sun, 21 Sep 2008 16:58:24 +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 <0K7K00D161TBDVB0@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Sep 2008 18:58:23 +0200 (CEST) Received: from kg-work2.kg4.no ([80.202.72.201]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0K7K002QC1T6GYQ1@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Sep 2008 18:58:23 +0200 (CEST) Date: Sun, 21 Sep 2008 18:58:18 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20080921185818.afe3f707.torfinn.ingolfsen@broadpark.no> In-reply-to: <20080921134529.GA977@icarus.home.lan> References: <20080918075306.GA30709@lpthe.jussieu.fr> <200809181618.m8IGIj2P050390@lurza.secnetix.de> <20080918183250.GA48347@lpthe.jussieu.fr> <48D2D744.40304@FreeBSD.org> <20080921124403.5ad118a7.torfinn.ingolfsen@broadpark.no> <20080921134529.GA977@icarus.home.lan> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) 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: floppy disk controller broken 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, 21 Sep 2008 16:58:25 -0000 On Sun, 21 Sep 2008 06:45:29 -0700 Jeremy Chadwick wrote: > Remove "device udbp" from your kernel configuration and try again. > The problem with bulk pipes is somewhat well-known at this point. This machine have a GENERIC kernel: tingo@kg-work2$ uname -a FreeBSD kg-work2.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Jul 21 20:40:31 CEST 2008 root@kg-work2.kg4.no:/usr/obj/usr/src/sys/GENERIC i386 And it seems like udbp is commented out in GENERIC: tingo@kg-work2$ grep udbp /sys/i386/conf/GENERIC #device udbp # USB Double Bulk Pipe devices So it might be something else. usb controller / chipset, or whatever. BTW, for completeness, this machine is a Dell OptiPlex SX270[1]. References: 1) http://tingox.googlepages.com/sx270 -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 17:11:17 2008 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 3668A106566B; Sun, 21 Sep 2008 17:11:17 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: from pinus.izb.knu.ac.kr (pinus.izb.knu.ac.kr [IPv6:2001:470:1f05:5f6:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id E7A2E8FC17; Sun, 21 Sep 2008 17:11:16 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: by pinus.izb.knu.ac.kr (Postfix, from userid 59) id 737603EA4; Mon, 22 Sep 2008 02:11:14 +0900 (KST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on pinus.izb.knu.ac.kr X-Spam-Level: X-Spam-Status: No, score=-48.6 required=15.1 tests=DKIM_SIGNED,DKIM_VERIFIED autolearn=disabled version=3.2.3 Received: from pinus.izb.knu.ac.kr (localhost.izb.knu.ac.kr [127.0.0.1]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id 6AD783EA0; Mon, 22 Sep 2008 02:11:10 +0900 (KST) Comment: DKIM? See http://www.google.com/search?btnI&q=RFC+4871 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=izb.knu.ac.kr; h=subject :from:to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; s=s1024; bh=dE3M09LBP8G CVYBcB/dnpGFUH2hhp1A8ECRV+KW3o78=; b=e9sBqFiHgY4qH6EouefXbOz5Smf KItrz5D4qbvou5BGpFzEhjZ7rf7t/0oVJNZf3PRRAQjSvZ20sVU9G/ANtF/5iyb7 hK8gTbsPn8vWdNw1RTMpXo23cdkounskiwSeQjt8y8fAwuvSymOEoKwfzq2jfcEZ XFhFsrHSDA7wuNzc= Received: from [IPv6:2001:470:1f05:5f8:3::2] (phyll.izb.knu.ac.kr [IPv6:2001:470:1f05:5f8:3::2]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id EE0A63E98; Mon, 22 Sep 2008 02:11:08 +0900 (KST) From: Byung-Hee HWANG To: Doug Barton In-Reply-To: <48D67AC0.4040301@FreeBSD.org> References: <1221990863.929.21.camel@phyll.izb.knu.ac.kr> <48D67AC0.4040301@FreeBSD.org> Content-Type: text/plain Organization: InZealBomb Date: Mon, 22 Sep 2008 02:11:12 +0900 Message-Id: <1222017072.932.7.camel@phyll.izb.knu.ac.kr> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: easy way to upgrade from 6.3 to 7.1 (including port packages) 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, 21 Sep 2008 17:11:17 -0000 On Sun, 2008-09-21 at 09:48 -0700, Doug Barton wrote: > Byung-Hee HWANG wrote: > > in my experience, in usual kernel && userland upgrading is good, > > however, everytime port upgrading have problem, whenever new -REL is > > released ;; i usually do port upgrading by portupgrade(1). > > > > at once(when 6.2-REL was released) i did upgrading port by > > portupgrade(1) but i met failures on the upgrading. then i did > > `pkg_delete -af` and then i did installation all packages by pkg_add(1) > > cause at that time the packages were twisted each other roughly ;; > > > > so is there any easy way to upgrade packages ?? > > can you please help me about this matters? > > The generally accepted wisdom (which I am repeating because I agree with > it) is that when updating major versions you should: > > 1. Carefully back up your configuration files and data > 2. Do a clean install of the new version > 3. Update configuration files > 4. Restore data > 5. Re-install your ports. > > What I usually do for step 3 is to un-tar the old configuration files in > a new directory and then diff -ur old/etc /etc, and after ports are > installed I diff -ur old/usr/local/etc /usr/local/etc. > > For step 5, I have a recommended update procedure in the portmaster man > page. Even if you don't intend to use portmaster to re-install your > ports I recommend installing it and reading that part of the man page > before you do your update to get an idea of what is important for you to > restore. > thank you very much because you have spent your beloved time for me. yes, i'll try it. especially i'll use portmaster(8) instead of portupgrade(1). thanks again.. byunghee -- As he drove Johnney home, Nino thought that if that was success, he didn't want it. -- The author's narration, "Chapter 13", page 189 From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 17:14:48 2008 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 B8142106566C for ; Sun, 21 Sep 2008 17:14:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 511618FC13 for ; Sun, 21 Sep 2008 17:14:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 1244 invoked by uid 399); 21 Sep 2008 16:48:06 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 21 Sep 2008 16:48:06 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48D67AC0.4040301@FreeBSD.org> Date: Sun, 21 Sep 2008 09:48:00 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Byung-Hee HWANG References: <1221990863.929.21.camel@phyll.izb.knu.ac.kr> In-Reply-To: <1221990863.929.21.camel@phyll.izb.knu.ac.kr> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: easy way to upgrade from 6.3 to 7.1 (including port packages) 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, 21 Sep 2008 17:14:48 -0000 Byung-Hee HWANG wrote: > in my experience, in usual kernel && userland upgrading is good, > however, everytime port upgrading have problem, whenever new -REL is > released ;; i usually do port upgrading by portupgrade(1). > > at once(when 6.2-REL was released) i did upgrading port by > portupgrade(1) but i met failures on the upgrading. then i did > `pkg_delete -af` and then i did installation all packages by pkg_add(1) > cause at that time the packages were twisted each other roughly ;; > > so is there any easy way to upgrade packages ?? > can you please help me about this matters? The generally accepted wisdom (which I am repeating because I agree with it) is that when updating major versions you should: 1. Carefully back up your configuration files and data 2. Do a clean install of the new version 3. Update configuration files 4. Restore data 5. Re-install your ports. What I usually do for step 3 is to un-tar the old configuration files in a new directory and then diff -ur old/etc /etc, and after ports are installed I diff -ur old/usr/local/etc /usr/local/etc. For step 5, I have a recommended update procedure in the portmaster man page. Even if you don't intend to use portmaster to re-install your ports I recommend installing it and reading that part of the man page before you do your update to get an idea of what is important for you to restore. hope this helps, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 18:57:54 2008 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 D63D9106566B for ; Sun, 21 Sep 2008 18:57:54 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (s4.stradamotorsports.com [64.81.163.122]) by mx1.freebsd.org (Postfix) with ESMTP id 948098FC0C for ; Sun, 21 Sep 2008 18:57:54 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from w16.stradamotorsports.com (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.8/8.13.8) with ESMTP id m8LIHxXR017391 for ; Sun, 21 Sep 2008 11:17:59 -0700 (PDT) (envelope-from jcw@highperformance.net) Message-ID: <48D68FD6.50804@highperformance.net> Date: Sun, 21 Sep 2008 11:17:58 -0700 From: "Jason C. Wells" User-Agent: Thunderbird 2.0.0.4pre (X11/20080205) MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on s4.stradamotorsports.com Subject: Installworld deletes libc 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, 21 Sep 2008 18:57:54 -0000 I have the problem similar to one described in 20071024 UPDATING. The build is running inside a jail. The system is 6.2-RELEASE. I supped this moring. I have the correct lib/Makefile. During installworld I receive an error: install: /lib/libc.so.6: chflags: Operation not permitted *** Error code 71 Stop in /usr/src/lib/libc. My situation is different in the libc is erased in the process. Copying the new libc.so.6 from /usr/obj does not fix the problem. Any ideas? Thanks, Jason From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 19:57:49 2008 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 5B6D01065705 for ; Sun, 21 Sep 2008 19:57:48 +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 5A0448FC0C for ; Sun, 21 Sep 2008 19:57:48 +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 <0K7K00GUQA35EN40@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Sep 2008 21:57:05 +0200 (CEST) Received: from kg-work2.kg4.no ([80.202.72.201]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0K7K00FCUA34HVI0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Sep 2008 21:57:05 +0200 (CEST) Date: Sun, 21 Sep 2008 21:57:04 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20080921215704.eca7300b.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) 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: FreeBSD 6.5-prerelease and if_re - patches needed? 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, 21 Sep 2008 19:57:49 -0000 Hi, The last part of last year and earlier this year a patch for if_re was needed to get it working reliably on my machine[1] (and some others). Now I have upgraded this machine to FreeBSD 6.4-prerelease, more info here [2]. Are the if_re patches included in FreeBSD 6.4-prerelease now, or are they still needed? I ask because while if_re works most of the time in 6.4-prerelease, I still have symptoms like last time (ssh often disconnects with "Bad packet length" and so on). References: 1) http://tingox.googlepages.com/asus_m2a-vm_hdmi 2) http://tingox.googlepages.com/asus_m2a-vm_hdmi_freebsd -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 20:54:54 2008 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 CE98D106567B for ; Sun, 21 Sep 2008 20:54:54 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 690918FC15 for ; Sun, 21 Sep 2008 20:54:54 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fg-out-1718.google.com with SMTP id l26so1126235fgb.35 for ; Sun, 21 Sep 2008 13:54:53 -0700 (PDT) Received: by 10.103.22.11 with SMTP id z11mr2074465mui.106.1222030492882; Sun, 21 Sep 2008 13:54:52 -0700 (PDT) Received: by 10.103.229.14 with HTTP; Sun, 21 Sep 2008 13:54:52 -0700 (PDT) Message-ID: Date: Sun, 21 Sep 2008 23:54:52 +0300 From: "Vlad GALU" To: "Robert Watson" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: FreeBSD Stable List Subject: Re: BPF plans for 7.1 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, 21 Sep 2008 20:54:54 -0000 On Sun, Sep 21, 2008 at 1:22 PM, Robert Watson wrote: > On Sat, 20 Sep 2008, Vlad GALU wrote: > >> Will the zero-copy bpf(4) changes be merged to the stable branch before >> the release? > > Dear Vlad: > > Unfortunately, no. The code seems stable in 8-CURRENT, but I don't feel > it's had enough actual testing exposure to go into 7.x yet. Also, the > libpcap changes to support it have only just gone back into the tcpdump.org > distribution of libpcap, and there is non-trivial reworking of that code, so > we'd like to let that settle as well. We've had a number of queries so I > suspect we'll start maintaining a 7.x MFC candidate patch fairly soon (next > couple of months). > > Robert N M Watson > Computer Laboratory > University of Cambridge > Thanks for your quick reply! I'll start experimenting with HEAD. -- ~/.signature: no such file or directory From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 21:34:37 2008 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 2BDEB106566B for ; Sun, 21 Sep 2008 21:34:37 +0000 (UTC) (envelope-from clint@0lsen.net) Received: from belle.0lsen.net (belle.0lsen.net [75.150.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 135828FC1B for ; Sun, 21 Sep 2008 21:34:36 +0000 (UTC) (envelope-from clint@0lsen.net) Received: by belle.0lsen.net (Postfix, from userid 1001) id 7AAB17967C; Sun, 21 Sep 2008 14:34:26 -0700 (PDT) Date: Sun, 21 Sep 2008 14:34:26 -0700 From: Clint Olsen To: stable@freebsd.org Message-ID: <20080921213426.GA13923@0lsen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: NULlsen Network X-Disclaimer: Mutt Bites! X-0lsen-net-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 7AAB17967C.00210 X-0lsen-net-MailScanner: Found to be clean X-0lsen-net-MailScanner-From: clint@0lsen.net X-Spam-Status: No Cc: Subject: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 21 Sep 2008 21:34:37 -0000 Sep 21 08:57:54 belle fsck: /dev/ad4s1d: 1 DUP I=190 Sep 21 08:57:54 belle fsck: /dev/ad4s1d: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. Ok, so I ran fsck manually (even with -y), but yet it refuses to clear/fix whatever to the questions posed as fsck runs. What does this all mean? Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 21:50:09 2008 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 748161065673 for ; Sun, 21 Sep 2008 21:50:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 543748FC1C for ; Sun, 21 Sep 2008 21:50:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id HZo71a00T17UAYkA3Zq83m; Sun, 21 Sep 2008 21:50:08 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id HZq71a0014v8bD78ZZq7zs; Sun, 21 Sep 2008 21:50:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=JH71NUhKGaAA:10 a=R4Gw6U_aiVgA:10 a=QycZ5dHgAAAA:8 a=qn0buKF21hP9gl7SPPcA:9 a=vwBvr7_JOPZkD0juLrQZHLZzb1gA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id DF06217B81A; Sun, 21 Sep 2008 14:50:06 -0700 (PDT) Date: Sun, 21 Sep 2008 14:50:06 -0700 From: Jeremy Chadwick To: Bob Willcox Message-ID: <20080921215006.GA9494@icarus.home.lan> References: <20080920042418.GB1322@rancor.immure.com> <20080920123914.GA72833@icarus.home.lan> <20080920132429.GA15275@rancor.immure.com> <20080920140456.GA74663@icarus.home.lan> <20080920144510.GB15275@rancor.immure.com> <20080920150533.GA75785@icarus.home.lan> <20080920185024.GC15275@rancor.immure.com> <20080921145715.GD15275@rancor.immure.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080921145715.GD15275@rancor.immure.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: PYUN Yong-Hyeon , freebsd-stable@freebsd.org Subject: Re: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB - maybe the 8650? 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, 21 Sep 2008 21:50:09 -0000 On Sun, Sep 21, 2008 at 09:57:15AM -0500, Bob Willcox wrote: > On Sat, Sep 20, 2008 at 01:50:24PM -0500, Bob Willcox wrote: > > On Sat, Sep 20, 2008 at 08:05:33AM -0700, Jeremy Chadwick wrote: > > > On Sat, Sep 20, 2008 at 09:45:10AM -0500, Bob Willcox wrote: > > > > On Sat, Sep 20, 2008 at 07:04:56AM -0700, Jeremy Chadwick wrote: > > > > > On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: > > [snip] > > I have since tried installing the 7.1 BETA on a system with the same CPU > (a Phenom 8650 X3) and a different motherboard that I have had success > running 7.1-PRELEASE on (the system I'm typing this message on, though > it has a Phenom 9850 X4) and it still hangs at appx the same point > (after enabling the second & third processors). Is there anyone else out > there having problems with this CPU on 7.1? I don't think it's a processor problem. There have been 3 or 4 other reports recently of hanging after the "mount root" part. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 21:51:14 2008 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 AA1911065678 for ; Sun, 21 Sep 2008 21:51:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5278FC3A for ; Sun, 21 Sep 2008 21:51:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id HRoW1a0060b6N64A4ZrECQ; Sun, 21 Sep 2008 21:51:14 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id HZrD1a0024v8bD78PZrDMZ; Sun, 21 Sep 2008 21:51:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=AM-mMR63F45M-jjttSQA:9 a=NGaZz5LPP_0Z5tI8j1cA:7 a=-VWaPQyKPYFT2pK4l-Ej6rehcz0A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 18E2E17B822; Sun, 21 Sep 2008 14:51:13 -0700 (PDT) Date: Sun, 21 Sep 2008 14:51:13 -0700 From: Jeremy Chadwick To: "Jason C. Wells" Message-ID: <20080921215113.GB9494@icarus.home.lan> References: <48D68FD6.50804@highperformance.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48D68FD6.50804@highperformance.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable Subject: Re: Installworld deletes libc 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, 21 Sep 2008 21:51:14 -0000 On Sun, Sep 21, 2008 at 11:17:58AM -0700, Jason C. Wells wrote: > I have the problem similar to one described in 20071024 UPDATING. The > build is running inside a jail. The system is 6.2-RELEASE. I supped this > moring. I have the correct lib/Makefile. During installworld I receive > an error: > > install: /lib/libc.so.6: chflags: Operation not permitted > *** Error code 71 > > Stop in /usr/src/lib/libc. > > My situation is different in the libc is erased in the process. Copying > the new libc.so.6 from /usr/obj does not fix the problem. > > Any ideas? Sounds like kern.securelevel is in the way. See security(7). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 21:52:05 2008 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 12DB81065677 for ; Sun, 21 Sep 2008 21:52:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id EBFA28FC2E for ; Sun, 21 Sep 2008 21:52:04 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id HQUx1a00H0vp7WLA5Zs4c2; Sun, 21 Sep 2008 21:52:04 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id HZs31a0044v8bD78RZs3FY; Sun, 21 Sep 2008 21:52:04 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=QycZ5dHgAAAA:8 a=J72hCp1d3eLMb-sLkDYA:9 a=O_eS6_9oT_91xSQEqUkGmhg03DAA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 6D66117B822; Sun, 21 Sep 2008 14:52:03 -0700 (PDT) Date: Sun, 21 Sep 2008 14:52:03 -0700 From: Jeremy Chadwick To: Clint Olsen Message-ID: <20080921215203.GC9494@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080921213426.GA13923@0lsen.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 21 Sep 2008 21:52:05 -0000 On Sun, Sep 21, 2008 at 02:34:26PM -0700, Clint Olsen wrote: > Sep 21 08:57:54 belle fsck: /dev/ad4s1d: 1 DUP I=190 > Sep 21 08:57:54 belle fsck: /dev/ad4s1d: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. > > Ok, so I ran fsck manually (even with -y), but yet it refuses to clear/fix > whatever to the questions posed as fsck runs. What does this all mean? Are you running fsck on the filesystem while its mounted? Are you doing this in single-user or multi-user mode? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 22:07:22 2008 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 E6949106566C for ; Sun, 21 Sep 2008 22:07:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 8F0E38FC1C for ; Sun, 21 Sep 2008 22:07:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA05.westchester.pa.mail.comcast.net with comcast id HZnk1a0050QuhwU55a7MSx; Sun, 21 Sep 2008 22:07:21 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA02.westchester.pa.mail.comcast.net with comcast id Ha6s1a0084v8bD73Na6s7U; Sun, 21 Sep 2008 22:06:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=QycZ5dHgAAAA:8 a=d-qYR513dP15oS1PmvsA:9 a=GT1Lkp7De-eRngKbhmMA:7 a=qeB8QLzLmwr987GcK2lKhjCzPEkA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id BCB3817B822; Sun, 21 Sep 2008 15:07:20 -0700 (PDT) Date: Sun, 21 Sep 2008 15:07:20 -0700 From: Jeremy Chadwick To: Clint Olsen Message-ID: <20080921220720.GA9847@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080921215930.GA25826@0lsen.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 21 Sep 2008 22:07:23 -0000 On Sun, Sep 21, 2008 at 02:59:30PM -0700, Clint Olsen wrote: > I ran in multi-user mode because the system booted. I figured that it > would have halted the boot if it was serious enough to warrant single-user > mode fsck. That has happened before. > > Thanks, > > -Clint > > On Sep 21, Jeremy Chadwick wrote: > > Are you running fsck on the filesystem while its mounted? Are you doing > > this in single-user or multi-user mode? Re-adding mailing list to the CC list. No, I don't think that is the case, assuming the filesystems are UFS2 and are using softupdates. When booting multi-user, fsck is run in the background, meaning the system is fully up + usable even before the fsck has started. Consider using background_fsck="no" in /etc/rc.conf if you prefer the old behaviour. Otherwise, boot single-user then do the fsck. You could also consider using clri(8) to clear the inode (190). Do this in single-user while the filesystem is not mounted. After using clri, run fsck a couple times. Also, are there any kernel messages about ATA/SCSI disk errors or other anomalies? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 22:24:30 2008 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 28C961065671 for ; Sun, 21 Sep 2008 22:24:30 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (dsl081-163-121.sea1.dsl.speakeasy.net [64.81.163.121]) by mx1.freebsd.org (Postfix) with ESMTP id E68868FC12 for ; Sun, 21 Sep 2008 22:24:24 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from w16.stradamotorsports.com (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.8/8.13.8) with ESMTP id m8LMOM3s022565; Sun, 21 Sep 2008 15:24:22 -0700 (PDT) (envelope-from jcw@highperformance.net) Message-ID: <48D6C995.7060606@highperformance.net> Date: Sun, 21 Sep 2008 15:24:21 -0700 From: "Jason C. Wells" User-Agent: Thunderbird 2.0.0.4pre (X11/20080205) MIME-Version: 1.0 To: Jeremy Chadwick References: <48D68FD6.50804@highperformance.net> <20080921215113.GB9494@icarus.home.lan> In-Reply-To: <20080921215113.GB9494@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on s4.stradamotorsports.com Cc: freebsd-stable Subject: Re: Installworld deletes libc 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, 21 Sep 2008 22:24:30 -0000 Jeremy Chadwick wrote: > On Sun, Sep 21, 2008 at 11:17:58AM -0700, Jason C. Wells wrote: >> I have the problem similar to one described in 20071024 UPDATING. The >> build is running inside a jail. The system is 6.2-RELEASE. I supped this >> moring. I have the correct lib/Makefile. During installworld I receive >> an error: >> >> install: /lib/libc.so.6: chflags: Operation not permitted >> *** Error code 71 >> >> Stop in /usr/src/lib/libc. >> >> My situation is different in the libc is erased in the process. Copying >> the new libc.so.6 from /usr/obj does not fix the problem. >> >> Any ideas? > > Sounds like kern.securelevel is in the way. See security(7). The securelevel would normally prevent the deletion of a file. The secure level of this jail is -1 in any case so the schg flag should be ignored. security.jail.chflags_allowed=0 seems to supersede the securelevel according to sysctl(8). Some part of installworld is misbehaving in the jail. The security mechanisms in securelevel and security.jail.chflags_allowed are not working. Regards, Jason From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 22:29:06 2008 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 70C7E1065672 for ; Sun, 21 Sep 2008 22:29:06 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (dsl081-163-120.sea1.dsl.speakeasy.net [64.81.163.120]) by mx1.freebsd.org (Postfix) with ESMTP id 382558FC16 for ; Sun, 21 Sep 2008 22:29:06 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from w16.stradamotorsports.com (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.8/8.13.8) with ESMTP id m8LMT3BB042020; Sun, 21 Sep 2008 15:29:03 -0700 (PDT) (envelope-from jcw@highperformance.net) Message-ID: <48D6CAAE.9060303@highperformance.net> Date: Sun, 21 Sep 2008 15:29:02 -0700 From: "Jason C. Wells" User-Agent: Thunderbird 2.0.0.4pre (X11/20080205) MIME-Version: 1.0 To: "Jason C. Wells" References: <48D68FD6.50804@highperformance.net> <20080921215113.GB9494@icarus.home.lan> <48D6C995.7060606@highperformance.net> In-Reply-To: <48D6C995.7060606@highperformance.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on s4.stradamotorsports.com Cc: Jeremy Chadwick , freebsd-stable Subject: Re: Installworld deletes libc 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, 21 Sep 2008 22:29:06 -0000 Jason C. Wells wrote: > Jeremy Chadwick wrote: >> On Sun, Sep 21, 2008 at 11:17:58AM -0700, Jason C. Wells wrote: >>> I have the problem similar to one described in 20071024 UPDATING. >>> The build is running inside a jail. The system is 6.2-RELEASE. I >>> supped this moring. I have the correct lib/Makefile. During >>> installworld I receive an error: >>> >>> install: /lib/libc.so.6: chflags: Operation not permitted >>> *** Error code 71 >>> >>> Stop in /usr/src/lib/libc. >>> >>> My situation is different in the libc is erased in the process. >>> Copying the new libc.so.6 from /usr/obj does not fix the problem. >>> >>> Any ideas? >> >> Sounds like kern.securelevel is in the way. See security(7). > > The securelevel would normally prevent the deletion of a file. The > secure level of this jail is -1 in any case so the schg flag should be > ignored. security.jail.chflags_allowed=0 seems to supersede the > securelevel according to sysctl(8). > > Some part of installworld is misbehaving in the jail. The security > mechanisms in securelevel and security.jail.chflags_allowed are not > working. I should add that 'systcl security.jail.chflags_allowed=1' allowed installworld to proceed without error. That solves my immediate problem. There appears to be a bug in the security mechanism. Later, Jason From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 22:47:07 2008 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 7E11D106566B; Sun, 21 Sep 2008 22:47:07 +0000 (UTC) (envelope-from ozbilgin@hotmail.com) Received: from bay0-omc3-s19.bay0.hotmail.com (bay0-omc3-s19.bay0.hotmail.com [65.54.246.219]) by mx1.freebsd.org (Postfix) with ESMTP id 65BEA8FC18; Sun, 21 Sep 2008 22:47:07 +0000 (UTC) (envelope-from ozbilgin@hotmail.com) Received: from BAY138-W24 ([64.4.49.59]) by bay0-omc3-s19.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Sep 2008 15:47:06 -0700 Message-ID: X-Originating-IP: [88.230.246.57] From: =?windows-1254?Q?yusuf_=F6zbilgin?= To: Jeremy Chadwick Date: Mon, 22 Sep 2008 01:47:06 +0300 Importance: Normal In-Reply-To: <20080921134937.GB977@icarus.home.lan> References: <20080920225314.GA84482@icarus.home.lan> <20080921134937.GB977@icarus.home.lan> Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-OriginalArrivalTime: 21 Sep 2008 22:47:06.0919 (UTC) FILETIME=[F95F4B70:01C91C3B] Cc: freebsd-stable@freebsd.org Subject: RE: Freebsd custom installation cd 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, 21 Sep 2008 22:47:07 -0000 ata8-master --> ata8 --> atapci1 and atapci1 is Intel Ahci Controller. I used GENERIC conf file and recompile the kernel but the problem is still exist. (I am using freebsd7) Then I added IDE disk to the system The system didnt detect the ide disk. This mainboard is G33 chipset Intel mainboard (BOXDG33FBC) (first mail was wrong) I try to mount floppy to save the dmesg output while installation but It also gave the error g_vfs_done(): fd0[read(offset=0, length=8192)] error = 6 I thougt that may be floopy or diskette error I tried to mount usb mass storage then It gave the "umass0 BBB reset failed timeout" error and stoped the booting. I tried different G33 chipset Intel mainboard (BOXDG33FBC) but problem continued. I tried with freebsd 6.2 cd it also didnt detect the disk. Freebsd7 installation cd is not giving any error. Thanks. ---------------------------------------- > Date: Sun, 21 Sep 2008 06:49:37 -0700 > From: koitsu@FreeBSD.org > To: ozbilgin@hotmail.com > CC: freebsd-stable@freebsd.org > Subject: Re: Freebsd custom installation cd > > On Sun, Sep 21, 2008 at 04:47:57AM +0300, yusuf özbilgin wrote: >> I added kernel configuration as attachment. >> >> When I boot system via freebsd live cd >> >> at boot process >> >> .... >> hptrr: no controller detected. >> acd0:DVDR at ata2-master UDMA66 >> ad16: 476938MB at ata8-master SATA300 >> >> then everthing is ok. >> >> but when I boot via custom installation cd; >> >> ad16 is not listed at boot screen. then saying no disk at fdisk section. >> >> I think there is missing kernel module but I couldnt find it. > > This isn't enough information. We need to see what ata8-master is > associated with, device-wise. That means tracking it down like > this: > > ata8-master --> ata8 --> atapciXX > > We need to see the dmesg information for all of those. Chances are the > disk falls under ata(4), but I'm not sure. > > A brief glimpse shows your kernel configuration looks fine, although > incredibly bloated. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > 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 Sun Sep 21 23:06:35 2008 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 C01361065673 for ; Sun, 21 Sep 2008 23:06:35 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (s5.stradamotorsports.com [64.81.163.123]) by mx1.freebsd.org (Postfix) with ESMTP id 8A97E8FC0C for ; Sun, 21 Sep 2008 23:06:35 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from w16.stradamotorsports.com (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.8/8.13.8) with ESMTP id m8LN6YxD055281 for ; Sun, 21 Sep 2008 16:06:34 -0700 (PDT) (envelope-from jcw@highperformance.net) Message-ID: <48D6D379.10909@highperformance.net> Date: Sun, 21 Sep 2008 16:06:33 -0700 From: "Jason C. Wells" User-Agent: Thunderbird 2.0.0.4pre (X11/20080205) MIME-Version: 1.0 CC: freebsd-stable References: <48D68FD6.50804@highperformance.net> <20080921215113.GB9494@icarus.home.lan> <48D6C995.7060606@highperformance.net> <48D6CAAE.9060303@highperformance.net> In-Reply-To: <48D6CAAE.9060303@highperformance.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on s4.stradamotorsports.com Subject: Install -S Not Safe was: Re: Installworld deletes libc 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, 21 Sep 2008 23:06:35 -0000 Jason C. Wells wrote: > Jason C. Wells wrote: > I should add that 'systcl security.jail.chflags_allowed=1' allowed > installworld to proceed without error. That solves my immediate problem. > There appears to be a bug in the security mechanism. The reason there appeared to be a bug in the security mechanism is that I performed (IIRC) chflags -noschg on libc as root on the host system outside the jail. But for some reason 'install -S' was not safe. (outside the jail) ~$ chflags noschg /usr/jails/cr/lib/libc.so.6 (inside the jail) [root@s4cr /usr/src/lib/libc]# ls -lao /lib/libc.so.6 -rwxr-xr-x 1 root wheel - 981331 Sep 21 15:57 /lib/libc.so.6 [root@s4cr /usr/src/lib/libc]# sysctl -a | grep secur kern.securelevel: -1 security.jail.chflags_allowed: 0 [root@s4cr /usr/src/lib/libc]# make install install -C -o root -g wheel -m 444 libc.a /usr/lib install -C -o root -g wheel -m 444 libc_p.a /usr/lib install -s -o root -g wheel -m 444 -fschg -S libc.so.6 /lib install: /lib/libc.so.6: chflags: Operation not permitted *** Error code 71 Stop in /usr/src/lib/libc. [root@s4cr /usr/src/lib/libc]# ls -lao /lib/libc.so.6 /libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "ls" [root@s4cr /usr/src/lib/libc]# Regards, Jason From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 00:13:19 2008 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 712A81065671 for ; Mon, 22 Sep 2008 00:13:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 160128FC23 for ; Mon, 22 Sep 2008 00:13:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA01.westchester.pa.mail.comcast.net with comcast id HU6i1a00B16LCl051cDJJn; Mon, 22 Sep 2008 00:13:18 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA06.westchester.pa.mail.comcast.net with comcast id HcDH1a0034v8bD73ScDHNF; Mon, 22 Sep 2008 00:13:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=j-pHpBAHbf4A:10 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=PDPs-Y1_PkxRCOMbFg4A:9 a=1rlS7gWjZGd5izcsEycA:7 a=rwmoq8J0cEg2oZeyLZSvL-t7uegA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id BDB3817B81A; Sun, 21 Sep 2008 17:13:16 -0700 (PDT) Date: Sun, 21 Sep 2008 17:13:16 -0700 From: Jeremy Chadwick To: yusuf =?iso-8859-1?Q?=F6zbilgin?= Message-ID: <20080922001316.GA12112@icarus.home.lan> References: <20080920225314.GA84482@icarus.home.lan> <20080921134937.GB977@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: bu7cher@yandex.ru, freebsd-stable@freebsd.org, sos@freebsd.org Subject: Re: Freebsd custom installation cd 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, 22 Sep 2008 00:13:19 -0000 On Mon, Sep 22, 2008 at 01:47:06AM +0300, yusuf özbilgin wrote: > ata8-master --> ata8 --> atapci1 > and atapci1 is Intel Ahci Controller. > I used GENERIC conf file and recompile the kernel but the problem is still exist. (I am using freebsd7) Before you rebuilt the kernel, did you update /usr/src using csup or cvsup? If so, then it sounds like there's a bug somewhere in the ata(4) code which is causing this problem. The code was recently modified (3 days ago), which sounds very suspicious. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-chipset.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-pci.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-pci.h I've CC'd the responsible parties. They should be able to work with you to find out what the problem is. > Then I added IDE disk to the system The system didnt detect the ide disk. > > This mainboard is G33 chipset Intel mainboard (BOXDG33FBC) (first mail was wrong) I can't explain this one. > I try to mount floppy to save the dmesg output while installation but It also gave the error > g_vfs_done(): fd0[read(offset=0, length=8192)] error = 6 There have been recent reports of the floppy disk driver in FreeBSD not working. > I thougt that may be floopy or diskette error I tried to mount usb mass storage then > It gave the "umass0 BBB reset failed timeout" error and stoped the booting. This is a separate problem and is known. AFAIK there is no fix, other than to try 8.0-CURRENT which contains a new USB stack. > I tried different G33 chipset Intel mainboard (BOXDG33FBC) but problem continued. > > I tried with freebsd 6.2 cd it also didnt detect the disk. > > Freebsd7 installation cd is not giving any error. Can you please provide exact FreeBSD versions and not just generic strings? We need to know if you're talking about FreeBSD 6.2-RELEASE, 6.2-STABLE, 7.0-RELEASE, 7.0-STABLE, 7.1-BETA, etc... -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 00:14:00 2008 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 BA88A1065670 for ; Mon, 22 Sep 2008 00:14:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 611208FC14 for ; Mon, 22 Sep 2008 00:14:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA05.westchester.pa.mail.comcast.net with comcast id HRYh1a00E0EZKEL55cDzw3; Mon, 22 Sep 2008 00:13:59 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA01.westchester.pa.mail.comcast.net with comcast id HcDy1a00D4v8bD73McDzSw; Mon, 22 Sep 2008 00:13:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZATkyH-5bjcA:10 a=6YigLTJI8gAA:10 a=QycZ5dHgAAAA:8 a=InRNKUORHqx8m2ldgBkA:9 a=EK9r6DdPXYp6CyuB8dEA:7 a=jGv_wYzgUXpCLeWW2f1Po1KHz-YA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 5124417B81A; Sun, 21 Sep 2008 17:13:58 -0700 (PDT) Date: Sun, 21 Sep 2008 17:13:58 -0700 From: Jeremy Chadwick To: "Jason C. Wells" Message-ID: <20080922001358.GB12112@icarus.home.lan> References: <48D68FD6.50804@highperformance.net> <20080921215113.GB9494@icarus.home.lan> <48D6C995.7060606@highperformance.net> <48D6CAAE.9060303@highperformance.net> <48D6D379.10909@highperformance.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48D6D379.10909@highperformance.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable Subject: Re: Install -S Not Safe was: Re: Installworld deletes libc 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, 22 Sep 2008 00:14:00 -0000 On Sun, Sep 21, 2008 at 04:06:33PM -0700, Jason C. Wells wrote: > Jason C. Wells wrote: >> Jason C. Wells wrote: > >> I should add that 'systcl security.jail.chflags_allowed=1' allowed >> installworld to proceed without error. That solves my immediate >> problem. There appears to be a bug in the security mechanism. > > The reason there appeared to be a bug in the security mechanism is that > I performed (IIRC) chflags -noschg on libc as root on the host system > outside the jail. > > But for some reason 'install -S' was not safe. > > (outside the jail) > ~$ chflags noschg /usr/jails/cr/lib/libc.so.6 > > (inside the jail) > [root@s4cr /usr/src/lib/libc]# ls -lao /lib/libc.so.6 > -rwxr-xr-x 1 root wheel - 981331 Sep 21 15:57 /lib/libc.so.6 > > [root@s4cr /usr/src/lib/libc]# sysctl -a | grep secur > kern.securelevel: -1 > security.jail.chflags_allowed: 0 > > [root@s4cr /usr/src/lib/libc]# make install > install -C -o root -g wheel -m 444 libc.a /usr/lib > install -C -o root -g wheel -m 444 libc_p.a /usr/lib > install -s -o root -g wheel -m 444 -fschg -S libc.so.6 /lib > install: /lib/libc.so.6: chflags: Operation not permitted > *** Error code 71 > > Stop in /usr/src/lib/libc. > > [root@s4cr /usr/src/lib/libc]# ls -lao /lib/libc.so.6 > /libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "ls" > [root@s4cr /usr/src/lib/libc]# Please file a PR on this matter. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 00:16:45 2008 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 7385A1065688 for ; Mon, 22 Sep 2008 00:16:45 +0000 (UTC) (envelope-from clint@0lsen.net) Received: from belle.0lsen.net (belle.0lsen.net [75.150.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 5462C8FC13 for ; Mon, 22 Sep 2008 00:16:45 +0000 (UTC) (envelope-from clint@0lsen.net) Received: by belle.0lsen.net (Postfix, from userid 1001) id D3C8B79675; Sun, 21 Sep 2008 16:59:50 -0700 (PDT) Date: Sun, 21 Sep 2008 16:59:50 -0700 From: Clint Olsen To: Jeremy Chadwick Message-ID: <20080921235950.GB25826@0lsen.net> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080921220720.GA9847@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Organization: NULlsen Network X-Disclaimer: Mutt Bites! X-0lsen-net-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: D3C8B79675.42A62 X-0lsen-net-MailScanner: Found to be clean X-0lsen-net-MailScanner-From: clint@0lsen.net X-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 22 Sep 2008 00:16:45 -0000 On Sep 21, Jeremy Chadwick wrote: > Re-adding mailing list to the CC list. > > No, I don't think that is the case, assuming the filesystems are UFS2 > and are using softupdates. When booting multi-user, fsck is run in the > background, meaning the system is fully up + usable even before the fsck > has started. The last time things crashed hard, the boot sequence was halted in order to run fsck. > Consider using background_fsck="no" in /etc/rc.conf if you prefer the > old behaviour. Otherwise, boot single-user then do the fsck. Yes, I'll do this. > You could also consider using clri(8) to clear the inode (190). Do this > in single-user while the filesystem is not mounted. After using clri, > run fsck a couple times. Ok, thanks. > Also, are there any kernel messages about ATA/SCSI disk errors or other > anomalies? None. In fact smartctl will not do anything now. It just prints out the quick banner message and exits immediately with no error. -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 00:31:56 2008 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 7CFCA1065672; Mon, 22 Sep 2008 00:31:56 +0000 (UTC) (envelope-from clint@0lsen.net) Received: from belle.0lsen.net (belle.0lsen.net [75.150.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 5D8608FC15; Mon, 22 Sep 2008 00:31:56 +0000 (UTC) (envelope-from clint@0lsen.net) Received: by belle.0lsen.net (Postfix, from userid 1001) id 1889C796CA; Sun, 21 Sep 2008 17:31:49 -0700 (PDT) Date: Sun, 21 Sep 2008 17:31:49 -0700 From: Clint Olsen To: Jeremy Chadwick Message-ID: <20080922003148.GA1552@0lsen.net> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080921220720.GA9847@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Organization: NULlsen Network X-Disclaimer: Mutt Bites! X-0lsen-net-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 1889C796CA.92BE6 X-0lsen-net-MailScanner: Found to be clean X-0lsen-net-MailScanner-From: clint@0lsen.net X-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 22 Sep 2008 00:31:56 -0000 On Sep 21, Jeremy Chadwick wrote: > You could also consider using clri(8) to clear the inode (190). Do this > in single-user while the filesystem is not mounted. After using clri, > run fsck a couple times. Booting single-user and running fsck again seems to have corrected these errors. For some reason it said another disk was not properly dismounted (/dev/ad0s1d - /home) and so it's running fsck in the background since I booted. -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 00:35:00 2008 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 62A191065684 for ; Mon, 22 Sep 2008 00:35:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 072BB8FC12 for ; Mon, 22 Sep 2008 00:34:59 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA02.westchester.pa.mail.comcast.net with comcast id HRZt1a0060xGWP852camE1; Mon, 22 Sep 2008 00:34:46 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA12.westchester.pa.mail.comcast.net with comcast id Hcay1a00J4v8bD73YcayCC; Mon, 22 Sep 2008 00:34:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=QycZ5dHgAAAA:8 a=io9Jqw7sFQ6sJS-SMI4A:9 a=L9ELudH--iosZHh7edoA:7 a=pVct9fTwwdglvdrNspdnH9QxJwUA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 35B2F17B81A; Sun, 21 Sep 2008 17:34:58 -0700 (PDT) Date: Sun, 21 Sep 2008 17:34:58 -0700 From: Jeremy Chadwick To: Clint Olsen Message-ID: <20080922003458.GA12810@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <20080921235950.GB25826@0lsen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080921235950.GB25826@0lsen.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 22 Sep 2008 00:35:00 -0000 On Sun, Sep 21, 2008 at 04:59:50PM -0700, Clint Olsen wrote: > > Also, are there any kernel messages about ATA/SCSI disk errors or other > > anomalies? > > None. In fact smartctl will not do anything now. It just prints out the > quick banner message and exits immediately with no error. With regards to this specific item: can you provide the full smartctl command you're using (including device), and all of the output? I have an idea of what the problem is, but I'd need to see the output first. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 00:40:48 2008 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 DD239106566C; Mon, 22 Sep 2008 00:40:48 +0000 (UTC) (envelope-from clint@0lsen.net) Received: from belle.0lsen.net (belle.0lsen.net [75.150.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id BC5AD8FC0A; Mon, 22 Sep 2008 00:40:48 +0000 (UTC) (envelope-from clint@0lsen.net) Received: by belle.0lsen.net (Postfix, from userid 1001) id CAD27796CA; Sun, 21 Sep 2008 17:40:40 -0700 (PDT) Date: Sun, 21 Sep 2008 17:40:40 -0700 From: Clint Olsen To: Jeremy Chadwick Message-ID: <20080922004040.GB1552@0lsen.net> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <20080921235950.GB25826@0lsen.net> <20080922003458.GA12810@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080922003458.GA12810@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Organization: NULlsen Network X-Disclaimer: Mutt Bites! X-0lsen-net-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: CAD27796CA.D826F X-0lsen-net-MailScanner: Found to be clean X-0lsen-net-MailScanner-From: clint@0lsen.net X-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 22 Sep 2008 00:40:48 -0000 On Sep 21, Jeremy Chadwick wrote: > With regards to this specific item: can you provide the full smartctl > command you're using (including device), and all of the output? I have > an idea of what the problem is, but I'd need to see the output first. # smartctl /dev/ad6 smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 01:00:43 2008 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 473961065673 for ; Mon, 22 Sep 2008 01:00:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id D79998FC1A for ; Mon, 22 Sep 2008 01:00:42 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA05.westchester.pa.mail.comcast.net with comcast id HRZN1a0050cZkys55d0hl7; Mon, 22 Sep 2008 01:00:41 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA10.westchester.pa.mail.comcast.net with comcast id Hd0h1a0024v8bD73Wd0h1s; Mon, 22 Sep 2008 01:00:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=FP58Ms26AAAA:8 a=QycZ5dHgAAAA:8 a=mox_nTlPqd9NbhQznAwA:9 a=t4w6xpOF4mSqnJaKi3cHtOY0cOwA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id D812417B81A; Sun, 21 Sep 2008 18:00:40 -0700 (PDT) Date: Sun, 21 Sep 2008 18:00:40 -0700 From: Jeremy Chadwick To: Clint Olsen Message-ID: <20080922010040.GA13316@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <20080921235950.GB25826@0lsen.net> <20080922003458.GA12810@icarus.home.lan> <20080922004040.GB1552@0lsen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080922004040.GB1552@0lsen.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 22 Sep 2008 01:00:43 -0000 On Sun, Sep 21, 2008 at 05:40:40PM -0700, Clint Olsen wrote: > On Sep 21, Jeremy Chadwick wrote: > > With regards to this specific item: can you provide the full smartctl > > command you're using (including device), and all of the output? I have > > an idea of what the problem is, but I'd need to see the output first. > > # smartctl /dev/ad6 > smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen > Home page is http://smartmontools.sourceforge.net/ The tool is behaving how it should. Try using the -a flag. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 01:02:02 2008 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 553901065671; Mon, 22 Sep 2008 01:02:02 +0000 (UTC) (envelope-from clint@0lsen.net) Received: from belle.0lsen.net (belle.0lsen.net [75.150.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 341A58FC17; Mon, 22 Sep 2008 01:02:02 +0000 (UTC) (envelope-from clint@0lsen.net) Received: by belle.0lsen.net (Postfix, from userid 1001) id 23AB6796CA; Sun, 21 Sep 2008 18:01:55 -0700 (PDT) Date: Sun, 21 Sep 2008 18:01:55 -0700 From: Clint Olsen To: Jeremy Chadwick Message-ID: <20080922010155.GA3109@0lsen.net> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <20080921235950.GB25826@0lsen.net> <20080922003458.GA12810@icarus.home.lan> <20080922004040.GB1552@0lsen.net> <20080922010040.GA13316@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080922010040.GA13316@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Organization: NULlsen Network X-Disclaimer: Mutt Bites! X-0lsen-net-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 23AB6796CA.E5098 X-0lsen-net-MailScanner: Found to be clean X-0lsen-net-MailScanner-From: clint@0lsen.net X-Spam-Status: No Cc: stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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, 22 Sep 2008 01:02:02 -0000 On Sep 21, Jeremy Chadwick wrote: > The tool is behaving how it should. Try using the -a flag. Ok, I feel dumb now :) Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 01:59:38 2008 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 30152106564A for ; Mon, 22 Sep 2008 01:59:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by mx1.freebsd.org (Postfix) with ESMTP id F180B8FC0C for ; Mon, 22 Sep 2008 01:59:31 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so668422tid.3 for ; Sun, 21 Sep 2008 18:59:22 -0700 (PDT) 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=VjXGrJiYUfARH+4I4T1fUqqmh+uiK7eFG4xn40kXcpg=; b=GI1G6xuRpcgZLRE3Byn2VQxmZGmc4eAzjEjCUViHf1GHmXFflvmiYPc3S/7d5OBKTY 5pWJHi4o40zZwV7dGlMXxT3vRWZZ5Kvdh/UG4GkWkYH+txe5Z/XmsazKE0aWei/mBMg+ ogc09bEggbekeMMkmj99UoS1gtEqEK4Oat+Us= 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=GgncVgEy0BjRPxghRqR+mYRZZWS1BSLUEkM7o/pBT3Tpl6KmSoY8Fs8DzQgn7qdMXs eatF2/rlNqq96SMrNrJRvyWmweOuep2C0DzFC71Ck4sAAofC4VyHADtQmIynVevNQwKN 131jpdQ5fQG2SVJ2Sg1EvUyo84zUq4mRYo570= Received: by 10.110.70.17 with SMTP id s17mr4596877tia.18.1222048762025; Sun, 21 Sep 2008 18:59:22 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id a14sm11188603tia.0.2008.09.21.18.59.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Sep 2008 18:59:20 -0700 (PDT) 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 m8M1vMc8026898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 10:57:22 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m8M1vJQO026897; Mon, 22 Sep 2008 10:57:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 22 Sep 2008 10:57:19 +0900 From: PYUN Yong-Hyeon To: Bob Willcox Message-ID: <20080922015718.GB26294@cdnetworks.co.kr> References: <20080920042418.GB1322@rancor.immure.com> <20080920123914.GA72833@icarus.home.lan> <20080920132429.GA15275@rancor.immure.com> <20080920140456.GA74663@icarus.home.lan> <20080920144510.GB15275@rancor.immure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080920144510.GB15275@rancor.immure.com> User-Agent: Mutt/1.4.2.1i Cc: Jeremy Chadwick , freebsd-stable@FreeBSD.org Subject: Re: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB 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: Mon, 22 Sep 2008 01:59:38 -0000 On Sat, Sep 20, 2008 at 09:45:10AM -0500, Bob Willcox wrote: > On Sat, Sep 20, 2008 at 07:04:56AM -0700, Jeremy Chadwick wrote: > > On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: [...] > > > none3@pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 > > > vendor = 'Realtek Semiconductor' > > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > > class = network > > > subclass = ethernet > > > > Regarding the Realtek issue: I've CC'd PYUN Yong-Hyeon (surname in > > caps), who maintains the re(4) driver for FreeBSD. He might have a > > patch available for you to try, or help determine how to get this NIC > > working on FreeBSD. He'll probably need more than just pciconf -lv > > output, but should be able to work with you. > > Ok, that'd be great. I must say that I'm close to simply returning this > MB and going with something not quite so new that is more likely to > work. I was hoping to get this system up and running this weekend. :( > There is one unresolved issue in re(4), some newer controllers does not respond to PHY access so re(4) fails to attach driver. If you can see a message like 'PHY write failed' in boot it indicates you're suffering from the issue. I have a local patch for this but it needs more testing as I don't have that hardware that exhibits the issue. Did you see the message? If you can't see 'PHY write failed' message during boot you might have a newer controller. Please post dmesg output for the case to add your device id to re(4). -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 02:12:27 2008 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 AB17B106564A for ; Mon, 22 Sep 2008 02:12:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by mx1.freebsd.org (Postfix) with ESMTP id 26EFB8FC0A for ; Mon, 22 Sep 2008 02:12:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so670828tid.3 for ; Sun, 21 Sep 2008 19:12:25 -0700 (PDT) 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=3pFZsT58b+PwuqNFI9JY0D57IMTRuUdUjT3Rm2mSNxk=; b=diVitu7ri2EvgvsAQMytTGs7QKMwNu9s9as/bI/o//iBhEHUiZBnieeyT4tQZzq3Rc mceya63hi/24VULpNnpipeoKfCYdOS0s5WG3JbRQ/UHNUG1x5WCCItC6MXIwXzL1z3yo zuikRCAiool00uLQeqLVmhvDZxls66Vvr4OFg= 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=jymG9yNo1opEk30NDZmgV0DoU22sy2eNS0oCYcuG/jH2X7jdohHqc7AKiLchx+ujpO eHUiD+1tU31FDnKuxTxofGjKCFBOxpP0wKyaitNhkNHmVbK/gVt/H0ljqU3xlRa6I9Dh Q6/tGn9MMBWWO2lEU1VlE+12cTkh10PLZaH5w= Received: by 10.110.43.20 with SMTP id q20mr4619296tiq.14.1222049545755; Sun, 21 Sep 2008 19:12:25 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id y3sm11207261tia.3.2008.09.21.19.12.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Sep 2008 19:12:24 -0700 (PDT) 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 m8M2APEo026982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 11:10:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m8M2AN5X026981; Mon, 22 Sep 2008 11:10:23 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 22 Sep 2008 11:10:23 +0900 From: Pyun YongHyeon To: Torfinn Ingolfsen Message-ID: <20080922021022.GC26294@cdnetworks.co.kr> References: <20080921215704.eca7300b.torfinn.ingolfsen@broadpark.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080921215704.eca7300b.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.5-prerelease and if_re - patches needed? 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: Mon, 22 Sep 2008 02:12:27 -0000 On Sun, Sep 21, 2008 at 09:57:04PM +0200, Torfinn Ingolfsen wrote: > Hi, > > The last part of last year and earlier this year a patch for if_re was > needed to get it working reliably on my machine[1] (and some others). > Now I have upgraded this machine to FreeBSD 6.4-prerelease, more info > here [2]. > Are the if_re patches included in FreeBSD 6.4-prerelease now, or are > they still needed? > Due to lack of time and energy the change made in HEAD wasn't MFCed to RELENG_6 so you may still need some patch. stable/7 should have no such problems though. > I ask because while if_re works most of the time in 6.4-prerelease, I > still have symptoms like last time (ssh often disconnects with "Bad > packet length" and so on). > Maybe the issue you're seeing comes from misuse of bus_dma(9) which was corrected in stable/7. > References: > 1) http://tingox.googlepages.com/asus_m2a-vm_hdmi > 2) http://tingox.googlepages.com/asus_m2a-vm_hdmi_freebsd > -- -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 04:59:10 2008 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 7E3F41065671 for ; Mon, 22 Sep 2008 04:59:10 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forwards4.yandex.ru (forwards4.yandex.ru [77.88.32.20]) by mx1.freebsd.org (Postfix) with ESMTP id 3085B8FC0C for ; Mon, 22 Sep 2008 04:59:10 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp15.yandex.ru (smtp15.yandex.ru [77.88.32.85]) by forwards4.yandex.ru (Postfix) with ESMTP id CB6031934B4; Mon, 22 Sep 2008 08:59:06 +0400 (MSD) Received: from mail.kirov.so-cdu.ru ([77.72.136.145]:32240 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S1377290AbYIVE7A (ORCPT + 1 other); Mon, 22 Sep 2008 08:59:00 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp15 X-Yandex-TimeMark: 1222059540 X-MsgDayCount: 2 X-Comment: RFC 2476 MSA function at smtp15.yandex.ru logged sender identity as: bu7cher Message-ID: <48D7260C.9020503@yandex.ru> Date: Mon, 22 Sep 2008 08:58:52 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Joseph Olatt References: <20080915192515.A13327@eskimo.com> In-Reply-To: <20080915192515.A13327@eskimo.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: unsupported NVIDIA SATA controller 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, 22 Sep 2008 04:59:10 -0000 Joseph Olatt wrote: > Hello, > > I have the following SATA controller card on my system that appears to > be unsupported by FreeBSD 7-STABLE. Does anybody know if this card is > supported or will be supported in the near future? > > > none13@pci0:0:14:0: class=0x010485 card=0x01371025 chip=0x07f810de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > class = mass storage > subclass = RAID Do you still have this problem? It seems that your controller is AHCI-capable. I can make a patch if is it needed. -- WBR, Andrey V. Elsukov From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 08:40:07 2008 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 CAB26106564A; Mon, 22 Sep 2008 08:40:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A8B378FC0C; Mon, 22 Sep 2008 08:40:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 42AD646B2A; Mon, 22 Sep 2008 04:40:07 -0400 (EDT) Date: Mon, 22 Sep 2008 09:40:07 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Norbert Papke , lioux@FreeBSD.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: stable@FreeBSD.org Subject: Possible UDP deadlock/panic fix 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, 22 Sep 2008 08:40:07 -0000 Attached is an MFC candidate for a patch I just merged to 8.x, which corrects the UDP lock recursion issue both of you were running into. If it settles well for a couple of days in HEAD then I'll go ahead and request an MFC from re@, but your confirmation as to whether or not this corrects the specific symptoms you are seeing would be very helpful. I was able to confirm that it eliminated what appeared to be the same problem here when I attempted to reproduce it based on the information you provided, so I'm hopeful.\ Thanks, Robert N M Watson Computer Laboratory University of Cambridge Property changes on: . ___________________________________________________________________ Modified: svn:mergeinfo Merged /head/sys:r183265 Index: netinet6/udp6_usrreq.c =================================================================== --- netinet6/udp6_usrreq.c (revision 183265) +++ netinet6/udp6_usrreq.c (working copy) @@ -975,13 +975,23 @@ error = EINVAL; goto out; } + + /* + * XXXRW: We release UDP-layer locks before calling + * udp_send() in order to avoid recursion. However, + * this does mean there is a short window where inp's + * fields are unstable. Could this lead to a + * potential race in which the factors causing us to + * select the UDPv4 output routine are invalidated? + */ + INP_WUNLOCK(inp); + INP_INFO_WUNLOCK(&udbinfo); if (sin6) in6_sin6_2_sin_in_sock(addr); pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs; - error = ((*pru->pru_send)(so, flags, m, addr, control, + /* addr will just be freed in sendit(). */ + return ((*pru->pru_send)(so, flags, m, addr, control, td)); - /* addr will just be freed in sendit(). */ - goto out; } } #endif From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 10:12:51 2008 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 7C6621065674 for ; Mon, 22 Sep 2008 10:12:51 +0000 (UTC) (envelope-from jv1967@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 39C2C8FC1B for ; Mon, 22 Sep 2008 10:12:51 +0000 (UTC) (envelope-from jv1967@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so219925yxb.13 for ; Mon, 22 Sep 2008 03:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=sTVClbXj37RZq/Z+75CuRS4MD40LxOhw9ZJM66iwVsA=; b=gv+pUVRC+W7o++OgUvNgqtiPQ73mAUMzXODXB1ylg+e9UbKp/VIYa6Sq5KfYSO587j j3u1Gux/zIV0zK20ko7mX4b+KhtEC4atSgsgpNnGcvCF+myx0niWE4QQ5l26CPlSa05d F8osaHC0osoN7ZjotLm4KDGMTRQJP5keVLXso= 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=BBRt9as0OxrVs1hXajUIkBl3XGv7EcS/d1LoT8511mRh3yxfxuMk1I4ugzZFqjZ5Ni yHCFwkpYn/vNcEBnsoQjnE03gYSRZNnVBIp3KMvlLJLTNMy88f4F74Ru1KKriIKK7Jfh 4UASVhP3bnM79S9NY8EbxdOdciKYzphicd03o= Received: by 10.151.147.16 with SMTP id z16mr6991972ybn.117.1222077122467; Mon, 22 Sep 2008 02:52:02 -0700 (PDT) Received: by 10.150.206.15 with HTTP; Mon, 22 Sep 2008 02:52:02 -0700 (PDT) Message-ID: <7dfad9e60809220252k469c2ab8q63910fcf62da1d4f@mail.gmail.com> Date: Mon, 22 Sep 2008 11:52:02 +0200 From: jv1967@gmail.com 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: Unsupported Marvel 88SX6145 SATA controller 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, 22 Sep 2008 10:12:51 -0000 Hi, I have an Asus P5BV-C/4L mainboard with two onboard SATA controllers. One of them, the Marvell 88SX6145, isn't support by FreeBSD 7. It seems to be detected as an ata controller: atapci0: port 0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe40f mem 0xfbfffc00-0xfbffffff irq 17 at device 0.0 on pci6 atapci0@pci0:6:0:0: class=0x01048f card=0x82201043 chip=0x614511ab rev=0xa1 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '? Add-on IC to provide 4x SATA Ports, attached to ICH7 (SthBridge?) via PCI-Express.' class = mass storage subclass = RAID Is there a driver/patch available for FreeBSD-7? Jos From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 12:57:45 2008 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 94F7C106568D for ; Mon, 22 Sep 2008 12:57:45 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 67FA18FC28 for ; Mon, 22 Sep 2008 12:57:45 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1371914rvf.43 for ; Mon, 22 Sep 2008 05:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=YnlD0CP7Iogpgvt1QTEs+XxQfDt9m2nWMG1azvEnWZI=; b=UyZBVapL1XvuiLO3BbrbmsZiucf8gZLFwFyto3EuHPeGJ2sA366ejIrLgOf8XLuCdX rNyyS5CKTKjXPqbfP9PbK24uQmYj53CqQ9p9YbEOiJ9+pds0/zhbkIn0cmgVWlTXKuNW RxJfBdTZrnBanXrAuUsdFyBE5M6DTYu7eqFwk= 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=LJGoV5dPTG0Zcev7IJ1HcBt2Zoi0zYgDK87RL6I8MwgauOuOzGUa1k9hqulUpZu8AM mzzdSeNo3RsQqtv1d4yodPhmFn6hzjVxKzCoU1oNhhjELgVxVtYtZIQmLicYULbbWskB 7jIMy9KYV+7DtMLttVynLHi8jkMq0nJhxgy/A= Received: by 10.141.106.14 with SMTP id i14mr1919969rvm.178.1222086977185; Mon, 22 Sep 2008 05:36:17 -0700 (PDT) Received: by 10.141.189.15 with HTTP; Mon, 22 Sep 2008 05:36:16 -0700 (PDT) Message-ID: <3a142e750809220536j51d0ed08ja3a87e6bff3b1c30@mail.gmail.com> Date: Mon, 22 Sep 2008 14:36:16 +0200 From: "Paul B. Mahol" To: "Jason C. Wells" In-Reply-To: <48D6CAAE.9060303@highperformance.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48D68FD6.50804@highperformance.net> <20080921215113.GB9494@icarus.home.lan> <48D6C995.7060606@highperformance.net> <48D6CAAE.9060303@highperformance.net> Cc: Jeremy Chadwick , freebsd-stable Subject: Re: Installworld deletes libc 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, 22 Sep 2008 12:57:45 -0000 On 9/22/08, Jason C. Wells wrote: > Jason C. Wells wrote: >> Jeremy Chadwick wrote: >>> On Sun, Sep 21, 2008 at 11:17:58AM -0700, Jason C. Wells wrote: >>>> I have the problem similar to one described in 20071024 UPDATING. >>>> The build is running inside a jail. The system is 6.2-RELEASE. I >>>> supped this moring. I have the correct lib/Makefile. During >>>> installworld I receive an error: >>>> >>>> install: /lib/libc.so.6: chflags: Operation not permitted >>>> *** Error code 71 >>>> >>>> Stop in /usr/src/lib/libc. >>>> >>>> My situation is different in the libc is erased in the process. >>>> Copying the new libc.so.6 from /usr/obj does not fix the problem. >>>> >>>> Any ideas? >>> >>> Sounds like kern.securelevel is in the way. See security(7). >> >> The securelevel would normally prevent the deletion of a file. The >> secure level of this jail is -1 in any case so the schg flag should be >> ignored. security.jail.chflags_allowed=0 seems to supersede the >> securelevel according to sysctl(8). >> >> Some part of installworld is misbehaving in the jail. The security >> mechanisms in securelevel and security.jail.chflags_allowed are not >> working. > > I should add that 'systcl security.jail.chflags_allowed=1' allowed > installworld to proceed without error. That solves my immediate problem. > There appears to be a bug in the security mechanism. sysctl -d security.jail.chflags_allowed security.jail.chflags_allowed: Processes in jail can alter system file flags It is not bug in security mechanism. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 13:39:49 2008 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 E7A14106566C; Mon, 22 Sep 2008 13:39:49 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2818FC0C; Mon, 22 Sep 2008 13:39:49 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id m8MDdauW001497; Mon, 22 Sep 2008 14:39:36 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KhldX-0005Sy-T0; Mon, 22 Sep 2008 14:39:35 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id m8MDdZeM076625; Mon, 22 Sep 2008 14:39:35 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id m8MDdX9a076624; Mon, 22 Sep 2008 14:39:33 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Dan Allen In-Reply-To: <1220550536.94705.18.camel@buffy.york.ac.uk> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 22 Sep 2008 14:39:33 +0100 Message-Id: <1222090773.43647.16.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: Peter Jeremy , wxs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: iwn(4) (Intel 4965 wireless) backport (was: Re: Inspiron 1525 Hardware) 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, 22 Sep 2008 13:39:50 -0000 On Thu, 2008-09-04 at 18:48 +0100, Gavin Atkinson wrote: > On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: > > On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: > > > > > This is supported by the iwn(4) driver in CURRENT, and it should be > > > quite easy to port the driver to 7-STABLE. If you're interested in > > > reinstalling FreeBSD and testing a backported driver, I'm sure this > > > can be sorted. > > > > I am interested in doing this. Please advise on how I can get these > > bits. > > I've got hold of a laptop with the 4965 chipset in it, if nobody beats > me to it I'll have a go at backporting the driver. OK, I've backported the iwn(4) driver for the Intel 4965 wireless chipset to 7-STABLE. You need both of: http://people.freebsd.org/~gavin/iwn-7/iwn-7.tgz http://people.freebsd.org/~gavin/iwn-7/iwn-7.diff Both are relative to /usr and are against 7-STABLE (although may well apply to 7.0-RELEASE cleanly). Please note that there are a couple of issues with this driver that aren't seen with the driver in -HEAD. Firstly, it only supports B/G channels, it doesn't work with 802.11a. Apparently this is due to a firmware issue which the driver in -HEAD works around, although I don't know how yet. Secondly, there may be a slight issue with regulatory domains. I'm not certain about this, but I was seeing issues while trying to associate to an access point on channel 13g, changing the AP to channel 1g fixes things. Even with those two caveats, I can say that so far in my testing it's been working very well. However, even if the driver works for you, I'm pretty sure it's too late for a merge before 7.1. Lastly, as the laptop is on loan to me and I'm going to have to give it back soon, I don't know if I'll have a chance to do any further work on this driver. I'm still interested in stories of success or otherwise. Thanks, Gavin From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 19:07:39 2008 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 191D91065674 for ; Mon, 22 Sep 2008 19:07:39 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id EB5838FC0A for ; Mon, 22 Sep 2008 19:07:38 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 7A0E51A000B0F for ; Mon, 22 Sep 2008 12:07:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4ry2uyIcx0sc for ; Mon, 22 Sep 2008 12:07:28 -0700 (PDT) Received: from coal (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 0F4321A000B27 for ; Mon, 22 Sep 2008 12:07:28 -0700 (PDT) From: Freddie Cash To: freebsd-stable@freebsd.org Date: Mon, 22 Sep 2008 12:07:26 -0700 User-Agent: KMail/1.9.9 References: <851F09A2-788D-4343-9E00-A0AB5C3AC063@netconsonance.com> <20080920044148.GA60230@in-addr.com> In-Reply-To: <20080920044148.GA60230@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809221207.26824.fjwcash@gmail.com> Subject: Re: Upcoming Releases Schedule... 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, 22 Sep 2008 19:07:39 -0000 On September 19, 2008 09:41 pm Gary Palmer wrote: > On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote: > > Without input from the current release team extending the support > > schedule is not possible. > > Inquiry - is release team the constraint? > > Or to put it another way, what to you is "support" in terms of > FreeBSD releases? > > As far as I am aware, if you stick on a RELENG_X_Y_Z_RELEASE tag RELENG_X_Y_Z_RELEASE never changes. That tag gives you the same bits that are on the FreeBSD X.Y.Z install CD. RELENG_X_Y is the security branch for FreeBSD X.Y. This branch gets the security updates, and the occasional major bug fix. RELENG_X is the -STABLE development branch for FreeBSD X. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 19:08:11 2008 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 AE04B1065672; Mon, 22 Sep 2008 19:08:11 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 842418FC13; Mon, 22 Sep 2008 19:08:11 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8MJ843X011104; Mon, 22 Sep 2008 12:08:04 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.421] Message-Id: <58B648A5-4F9D-4C02-9A1C-21E1294DEB7A@netconsonance.com> From: Jo Rhett To: Robert Watson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 12:07:58 -0700 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 22 Sep 2008 19:08:11 -0000 On Sep 20, 2008, at 3:37 AM, Robert Watson wrote: > The tension here is between making promises we can definitely keep > and starting to make promises that we can't. We'd like to err on > the former, rather than latter, side. Yes. This is well understood and I agree with those priorities. > You already identified the end goal: extend support lifetimes. You > placed constraint on how that could be accomplished: you were going > to do the work. What I've done is identified our normal model for > getting from the current starting point (a guy on a mailing list > who, while enthusiastic, hasn't shown us the beef) to the proposed > outcome (a guy on the security-officer team, commit access required > to participate in the support process, etc). Here are the subgoals > I broke it out into: Again, what you are saying makes a lot of sense, and I have no problem with it. We're just missing the crucial bit -- what is it going to take to reach that goal? Regardless of commit bits, etc and such forth. Is 10 hours a week of one person enough? Does it really need 4 people with 10 hours a week? How do we get from here to there? This is where I think we're missing each other. Achieving a commit bit -- sure, no problem with what you have outlined. But you haven't finished the thought enough to confirm whether me having a commit bit would solve the problem we are trying to solve. I mean honestly, is one person with a commit bit and some time enough to solve the problem? I've been involved with enough projects to know that the real answer might be, "no, we actually have all the people we need with commit bits but our infrastructure makes doing this difficult right now". >> If you've seen the appropriate Southpark episode: "Step 3: >> Profit!" "Dude, what's step 2?" > > Let's make sure we understand each other clearly: the reason you're > getting replies using words like "demand" is that it is easy to read > your e-mails in exactly the above light. It is not a stretch to > interpret them as reading, "Put me on the security officer team > without having gone through any of the normal processes used to vet > a new member". Well, I find it really sad that I would refer to a hilarious episode about, of all things, Underpants Gnomes! and you would find some way to read it as a demand. Someone is going pretty far to think that, enough such that I doubt it could be empirically proven, given that I have repeatedly stated that I could give a darn about a commit bit - and that my only goal is to make it easier for businesses like my $EMPLOYER to sustain deployment. And furthermore, over 90-something percent of my questions have only had the goal of acquiring information. Without that information, I'm not even certain that my skillset is what is necessary to improve this situation. Once that information is made public, I may end up looking at it and saying either "this isn't something my skills can contribute to in a worthwhile fashion", "this isn't feasible based on what I know of resources that could be brought to the table", etc etc and such forth. I mean seriously, Robert -- if I wanted to demand something I'd be SoL because I haven't the vaguest clue what to demand. I've facing this high black wall of no information. Nobody (on this side of that wall) can make intelligent decisions about what the right thing to do would be. I'm sorry, there is another way to think about this. Yes, I am "demanding" (not a word I would prefer to use, but...). I would like the release team to be specific about what resource limitations prevent it from from longer support periods for -REL branches. IF and WHEN such information is made available, my $EMPLOYER and a few others would be interested in discussing what resources we could bring to the table to help resolve those resource limitations. At that point we would determine how to best use those resources in a manner that the FreeBSD developers are capable of integrating and sustaining in the long term. (ie what you've outlined in your past two messages) > We can talk about changing the process, but I think you can't > contribute to that conversation constructively without understanding > the process. Simply demanding change (and that's how it reads) > shows a lack of respect for how we got to where we are, and puts > people people on the defensive. Or offensive, in some cases. :-) I've never demanded change. I spent the whole afternoon yesterday rereading every post I've made to this list in the last 6 months, and nothing there demanded anything other than information about the resource limitations that were alluded to but never spelled out. And yes, offensive seems to be the default selection by FreeBSD developers. > If you approach a software company and say "Look, we like your > product, but it would really help us if you supported each minor > release for 24 instead of 18 months, and the way you're going to do > this is put our employee on your security response team", I think > you'd see a lot of raised eyebrows there as well. That's the point. I've never said anything like that. And a software company would totally understand the question as originally phrased. "What resource limitations prevent you from supporting this product for a longer period?" Any company would fairly promptly come back with an answer. FWIW, there are at least 3 companies whose software product is supported on FreeBSD, or with Apache, or various other things because of my integration work for them. We approached them and said "We would like you to support XYZ. What do you need to do this?" The software company chatted with us about it, and everyone decided it was easier to have me do the integration work for them as opposed to paying them more. (other companies we paid for them to do the work, etc) This is how things work. You ask a question, somebody answers the question and you sit and chat about solutions that meet everyone's needs. This situation with FreeBSD has been downright shocking because I've never before in my life been attacked for saying "We need this. How can I help?" -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 19:08:42 2008 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 078BE106564A; Mon, 22 Sep 2008 19:08:42 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id D7A318FC16; Mon, 22 Sep 2008 19:08:41 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8MJ843Y011104; Mon, 22 Sep 2008 12:08:39 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: 0.571 X-Spam-Level: X-Spam-Status: No, score=0.571 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=-1.171, DATE_IN_FUTURE_48_96=3.182] Message-Id: <320CA2E9-2358-4E3A-A1D3-F8918B70A6C2@netconsonance.com> From: Jo Rhett To: Gary Palmer In-Reply-To: <20080920190450.GB60230@in-addr.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 12:08:39 -0700 References: <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <20080920190450.GB60230@in-addr.com> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-stable , Robert Watson Subject: Re: Upcoming Releases Schedule... 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, 22 Sep 2008 19:08:42 -0000 On Sep 20, 2008, at 12:04 PM, Gary Palmer wrote: > Actually Robert, to be fair to Jo, I suspect it is more proper to say > "$COMPANY wants extended support lifetimes. What can I, or $COMPANY, > do to help make that happen?". I think its been misinterpreted as > Jo saying "Let me do the work". He has offered to see if his company > will let him help on company time, but I do not believe the constraint > is quite as you phrased it above. The goal is the same, but throw it > open to a wider contraint set - what resources does the project need > to make it happen? Money? Test labs? Server hosting? Twinkies? Exactly. Thank you for phrasing it so very well. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 19:14:18 2008 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 7FD561065673 for ; Mon, 22 Sep 2008 19:14:18 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8838FC19 for ; Mon, 22 Sep 2008 19:14:18 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8MJEFNb011267; Mon, 22 Sep 2008 12:14:15 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.419] Message-Id: <34CE6F7C-DFB9-4B82-88F1-0B847283FC73@netconsonance.com> From: Jo Rhett To: "Simon L. Nielsen" In-Reply-To: <20080920205645.GI1151@arthur.nitro.dk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 12:14:10 -0700 References: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <20080920020703.GA82392@phat.za.net> <851F09A2-788D-4343-9E00-A0AB5C3AC063@netconsonance.com> <4d7dd86f0809192057s33dfd92fv598488a4c05ada14@mail.gmail.com> <4B2A556D-B13D-4B71-819A-F9B23C5685AF@netconsonance.com> <20080920205645.GI1151@arthur.nitro.dk> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-stable Subject: Re: Upcoming Releases Schedule... 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, 22 Sep 2008 19:14:18 -0000 On Sep 20, 2008, at 1:56 PM, Simon L. Nielsen wrote: >> 2 years for each supported branch would be excellent, although I'm >> open to alternatives. Right now 6.4 will EoL before 6.3 will :-( > > Eh, where did you get that information? AFAIK the EoL date of 6.4 has > not yet been decided (and I should know though of course I could have I asked specifically on this list. First I was told it hadn't been decided. My response was to point out that this makes it very hard for a company to decide to commit resources to test it, if there may never be a reasonable chance for deployment. Then I was told it was 1 year, or perhaps just 6 months if it was ruled to be an unstable version. Either answer is less than 6.3's support period. > If, when we get closer to the actual release, still is the plan for > 6.4 to be the last RELENG_6 release I'm almost certain 6.4 will be a > Extended Support release. That would be excellent. As soon as you know if this will be true, I'll be able to convince $EMPLOYER to allow me to spend time testing this release. If its not an extended support release, then it will expire before 6.3 (which is already tested) and thus $EMPLOYER gains no value in the effort. FWIW, this is why I'm in favor of consistent support periods. When you align the business benefit with the community benefit, you can get the business to help improve the community product. (remainder snipped to a different subject line) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 19:42:00 2008 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 02B2D1065677 for ; Mon, 22 Sep 2008 19:42:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AFADC8FC15 for ; Mon, 22 Sep 2008 19:41:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 49CF746B2A; Mon, 22 Sep 2008 15:41:59 -0400 (EDT) Date: Mon, 22 Sep 2008 20:41:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jo Rhett In-Reply-To: <58B648A5-4F9D-4C02-9A1C-21E1294DEB7A@netconsonance.com> Message-ID: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <58B648A5-4F9D-4C02-9A1C-21E1294DEB7A@netconsonance.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 22 Sep 2008 19:42:00 -0000 On Mon, 22 Sep 2008, Jo Rhett wrote: > Again, what you are saying makes a lot of sense, and I have no problem with > it. We're just missing the crucial bit -- what is it going to take to reach > that goal? Regardless of commit bits, etc and such forth. Is 10 hours a > week of one person enough? Does it really need 4 people with 10 hours a > week? How do we get from here to there? > > This is where I think we're missing each other. Achieving a commit bit -- > sure, no problem with what you have outlined. But you haven't finished the > thought enough to confirm whether me having a commit bit would solve the > problem we are trying to solve. > > I mean honestly, is one person with a commit bit and some time enough to > solve the problem? I've been involved with enough projects to know that the > real answer might be, "no, we actually have all the people we need with > commit bits but our infrastructure makes doing this difficult right now". Lack of human resources, to use a vile term, is currently the limiting factor. What happens when that is cleared is another question, but in the end there aren't a whole lot of paths to greater efficiency here: for each vulnerability, we generally start with the HEAD of the tree working back by age, for each branch identifying: - Whether the vulnerability, or broad class of vulnerabilities, exists - If the same patch applies, whether it fixes all instances of the problem in the next branch as well - Generate commit candidate - Test builds and runs - Generate binary updates - Generate appropriate security advisory information This is an inherently manual process because security patches touch a variety of parts of the system and each has different implications, the tendency for vulnerabilities to come in classes, etc. None of us remembers the format string vulnerability's arrival on the scene fondly since it became necessary to modify the compiler to try to mechanically sweep the tree for similar issues, for example. The older a branch, the more likely it is that it requires a different analysis and a different patch, hence the sigh of relief when 5.x fell off the support list -- not because it was a bad branch, but because there was significant divergence and maintaining three active development branches at once (5.x, 6.x, and 7.x) was a serious stretch. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 19:49:27 2008 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 1CA831065676; Mon, 22 Sep 2008 19:49:27 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id EF9008FC47; Mon, 22 Sep 2008 19:49:26 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8MJnO4E011994; Mon, 22 Sep 2008 12:49:24 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.417] Message-Id: <75E31E23-23BA-4A5D-90F1-984C8C0AC895@netconsonance.com> From: Jo Rhett To: "Simon L. Nielsen" In-Reply-To: <20080920205645.GI1151@arthur.nitro.dk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 12:49:18 -0700 References: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <20080920020703.GA82392@phat.za.net> <851F09A2-788D-4343-9E00-A0AB5C3AC063@netconsonance.com> <4d7dd86f0809192057s33dfd92fv598488a4c05ada14@mail.gmail.com> <4B2A556D-B13D-4B71-819A-F9B23C5685AF@netconsonance.com> <20080920205645.GI1151@arthur.nitro.dk> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-stable Subject: Release team resources 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, 22 Sep 2008 19:49:27 -0000 Thank you for answering the resources problem in detail, I appreciate it. > For what secteam support of the base system costs, it's mainly time > for the members of the security team which is the cost. The more > branches, the more time is required. This is not a linear cost and > has multiple parts to it: ... > There is also a cost in hardware for supported branches though this is > less of an issue. ... > > The more releases are supported, the more disk-space is also needed > for freebsd-update mirrors. Again, far from an unsolvable problem by > any means, but also a factor This is what I suspected, but having the detail backing it up helps tremendously. Has there been done any work on metrics for the support needs? Obviously these are a bit of hand waving because the number and type of security problems are hard to predict, but it does help to provide a useful model for understanding "costs" In specific, is it known how many man-hours would be necessary to extend support for a recent release? NOTE that I am not trying to extend the support for 4.x or 5.x or even 6.x once 8 has shipped. I think that 2 full releases is perfectly reasonable. I'm just asking about the recent releases. > While I'm not going more into the general discussion of how long to > support branches, I will note that as rwatson has said - adding more > people to secteam is not as simple as it sounds (though we are in the > process of expanding right now). I assumed not. I was curious to what extent outside people could help support the process, while leaving commits to the internal people. For example, for everything except the jail vulnerability in the last 4 years the security problems were related to third party utilities, and were widely published in security mailing lists. Someone without a commit bit could certainly build the patch, test the patch on relevant versions, etc. Likewise, if a patch was created for the latest version, an outside person could test the patch on a desired-to-support build, confirm that it works and/or change the patch as necessary for the older build (like when third party utility versions were different between major releases). Is the overhead of supporting these "not-committers" such that it is not useful for the secteam as a whole? (obviously the longer term goal would be to determine which of the outside testers would be useful for promoting within the group) > Newer patches also wouldn't make it to freebsd-update > as that is managed by secteam. For my needs/desires I'd rather focus on something that would get pushed to freebsd-update. > We have had one case where a committer was interested in supporting an > older release and back-ported patches from security advisories for a > while. The patches for the older releases were then reviewed in each > case by the security team before commit, but that only lasted for a > while and was a couple of years ago AFAIR. In theory this could > happen again if the Security Officer at the time is OK with it - I > haven't talked with Colin about this in a while, so I can't recall is > position. There would still need to be committer which is the > interface to secteam and do the commits. Most issues (though of > course not all) which gets advisories are not public at the time of > the advisory, so a fix to older branches would be likely be delayed > some compared to initial disclosure. As noted above, very few of the security releases were based on information not available to the general public (who read security- related mailing lists, anyway) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 19:54:50 2008 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 18E50106567C; Mon, 22 Sep 2008 19:54:50 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id DF4578FC13; Mon, 22 Sep 2008 19:54:49 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8MJsbuV012120; Mon, 22 Sep 2008 12:54:37 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Amavis-Modified: Mail body modified (defanged) by mail.netconsonance.com X-Quarantine-ID: X-Virus-Scanned: amavisd-new at netconsonance.com X-Amavis-Alert: BAD HEADER, Header line longer than 998 characters: References: <12...\n X-Spam-Flag: NO X-Spam-Score: -1.025 X-Spam-Level: X-Spam-Status: No, score=-1.025 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.415] Message-Id: <7FC02881-91A6-4A2B-B58F-A4D1671B9978@netconsonance.com> From: Jo Rhett To: Robert Watson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 12:54:32 -0700 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> X-Mailer: Apple Mail (2.929.2) Cc: netgeek , freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 22 Sep 2008 19:54:50 -0000 On Sep 21, 2008, at 1:57 AM, Robert Watson wrote: > This is precisely what we already do -- we guarantee we will support > the last release on a branch for 24 months after the release. The > point of concern being discussed is that we can't tell you for sure > which minor release will be the last release at the time that > release goes out the door, because the extent to which we keep > releasing on old branches depends in large part on how the new > branch looks. I think you are using "last release" in a different way. "the last release" is always the most release release. Right now 6.3 will have support for longer than 6.4 will, which is the nature of the problem I raised. If you always supported the most recent release for 24 months then we wouldn't have any problem. I mean seriously, if you were to say "We will support 6.4 for 24 months *unless* we find it necessary to release 6.5 then I'd be totally happy. But that's not what is being said. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 20:01:06 2008 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 79FFD1065684; Mon, 22 Sep 2008 20:01:06 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4DB688FC12; Mon, 22 Sep 2008 20:01:06 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8MK0w8l012258; Mon, 22 Sep 2008 13:00:59 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Amavis-Modified: Mail body modified (defanged) by mail.netconsonance.com X-Quarantine-ID: X-Virus-Scanned: amavisd-new at netconsonance.com X-Amavis-Alert: BAD HEADER, Header line longer than 998 characters: References: <12...\n X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.414] Message-Id: From: Jo Rhett To: Robert Watson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 13:00:53 -0700 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <58B648A5-4F9D-4C02-9A1C-21E1294DEB7A@netconsonance.com> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 22 Sep 2008 20:01:06 -0000 On Sep 22, 2008, at 12:41 PM, Robert Watson wrote: > Lack of human resources, to use a vile term, is currently the > limiting factor. What happens when that is cleared is another > question, but in the end there aren't a whole lot of paths to > greater efficiency here: ... > This is an inherently manual process because security patches touch > a variety of parts of the system and each has different > implications, the tendency for vulnerabilities to come in classes, > etc. Great, thanks. Do we have any idea how much additional human resources would be necessary to extend the support period? > because there was significant divergence and maintaining three > active development branches at once (5.x, 6.x, and 7.x) was a > serious stretch. I've never suggested maintaining 3 different release versions, and I wouldn't suggest trying. When Sun, Microsoft, et al decide that they don't have the resources to support 3 major revisions, it's a pretty good reason to think that FreeBSD can't either ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 20:08:41 2008 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 13BB61065681; Mon, 22 Sep 2008 20:08:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C16748FC12; Mon, 22 Sep 2008 20:08:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 736D646B46; Mon, 22 Sep 2008 16:08:40 -0400 (EDT) Date: Mon, 22 Sep 2008 21:08:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jo Rhett In-Reply-To: <75E31E23-23BA-4A5D-90F1-984C8C0AC895@netconsonance.com> Message-ID: References: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <20080920020703.GA82392@phat.za.net> <851F09A2-788D-4343-9E00-A0AB5C3AC063@netconsonance.com> <4d7dd86f0809192057s33dfd92fv598488a4c05ada14@mail.gmail.com> <4B2A556D-B13D-4B71-819A-F9B23C5685AF@netconsonance.com> <20080920205645.GI1151@arthur.nitro.dk> <75E31E23-23BA-4A5D-90F1-984C8C0AC895@netconsonance.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable , "Simon L. Nielsen" Subject: Re: Release team resources 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, 22 Sep 2008 20:08:41 -0000 On Mon, 22 Sep 2008, Jo Rhett wrote: > I assumed not. I was curious to what extent outside people could help > support the process, while leaving commits to the internal people. For > example, for everything except the jail vulnerability in the last 4 years > the security problems were related to third party utilities, and were widely > published in security mailing lists. Someone without a commit bit could > certainly build the patch, test the patch on relevant versions, etc. I'm not sure I agree with this analysis. From a FreeBSD-centric perspective, vulnerabilities fall into four classes: - FreeBSD-generated code - Third party code blended with out code (arguably ours also) - "contrib" code that is in our revision control - Ports We dropped ports from our advisory scope because the number of vulnerabilities skyrocketted due to ports growing and the number of vulnerabilities discovered in them growing. We do provide a database of known-vulnerable ports and versions, but that's not generally the responsibility of the base security team, rather a separate ports security team. I think this is the right trade-off -- among our fears is that we over-release advisories, which would devalue the usefulness of advisories over time as referring specifically to critical issues. Extracted from the list of advisories on security.FreeBSD.org going back to the beginning of last year: Advisory Class FreeBSD-SA-08:09.icmp6 Blended FreeBSD-SA-08:08.nmount FreeBSD FreeBSD-SA-08:07.amd64 FreeBSD FreeBSD-SA-08:06.bind Contrib FreeBSD-SA-08:05.openssh Contrib FreeBSD-SA-08:03.sendfile FreeBSD FreeBSD-SA-08:02.libc Blended FreeBSD-SA-08:04.ipsec Blended FreeBSD-SA-08:01.pty FreeBSD FreeBSD-SA-07:10.gtar Contrib FreeBSD-SA-07:09.random FreeBSD FreeBSD-SA-07:08.openssl Contrib FreeBSD-SA-07:07.bind Contrib FreeBSD-SA-07:06.tcpdump Contrib FreeBSD-SA-07:05.libarchive FreeBSD FreeBSD-SA-07:04.file Contrib FreeBSD-SA-07:03.ipv6 Blended FreeBSD-SA-07:02.bind Contrib FreeBSD-SA-07:01.jail FreeBSD Counting on my fingers, that's 7 FreeBSD-specific, 4 that lie in code we basically maintain, and 8 that are in externally maintained software. Seems like a pretty even split. In the case of most third party code vulnerabilities, I believe we received non-trivial advanced warning of the impending vulnerability announcement. > As noted above, very few of the security releases were based on information > not available to the general public (who read security-related mailing > lists, anyway) I'm not sure I agree with this assertion either. While there are exceptions, most vulnerabilities are known to the security team in advance of public discussion. Depends a bit on which security lists you read, of course... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 20:32:13 2008 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 ED2BC1065671 for ; Mon, 22 Sep 2008 20:32:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A66D98FC27 for ; Mon, 22 Sep 2008 20:32:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 3CC9246B42; Mon, 22 Sep 2008 16:32:13 -0400 (EDT) Date: Mon, 22 Sep 2008 21:32:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jo Rhett In-Reply-To: Message-ID: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <58B648A5-4F9D-4C02-9A1C-21E1294DEB7A@netconsonance.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 22 Sep 2008 20:32:14 -0000 On Mon, 22 Sep 2008, Jo Rhett wrote: > On Sep 22, 2008, at 12:41 PM, Robert Watson wrote: >> Lack of human resources, to use a vile term, is currently the limiting >> factor. What happens when that is cleared is another question, but in the >> end there aren't a whole lot of paths to greater efficiency here: > ... >> This is an inherently manual process because security patches touch a >> variety of parts of the system and each has different implications, the >> tendency for vulnerabilities to come in classes, etc. > > Great, thanks. Do we have any idea how much additional human resources > would be necessary to extend the support period? Short answer: no. Long answer: we're under-manned for our current commitments, and have seen longer advisory cycles than we would like. My guess is that we could eat the first 25% of a person just catching up on current obligations so as to reduce latency on advisories, handle back-analysis of reports that don't appear to be vulnerabilities but we'd like to be sure, etc. Another hand-wave: 50%-75% of a person would allow us to move into extending our obligations as well as put more resources into proactive work. You don't have to be on the security team to work on security work (and many people who do aren't), but certainly one obligation that comes with being on the team is to try to proactively address vulnerability classes and improve infrastructure for issuing advisories, providing updates, etc. All hand-waving, understand. Depends a lot on the person, the season (reports don't arrive at a constant rate), etc. >> because there was significant divergence and maintaining three active >> development branches at once (5.x, 6.x, and 7.x) was a serious stretch. > > I've never suggested maintaining 3 different release versions, and I > wouldn't suggest trying. When Sun, Microsoft, et al decide that they don't > have the resources to support 3 major revisions, it's a pretty good reason > to think that FreeBSD can't either ;-) Tricky balance -- if you cut a major release every 18-24 months, you have a 24-month support cycle on the final point release on each branch, and you continue to release minor releases after the .0 of the next branch in order to allow .0's to settle for a bit before forcing migration forward, it's hard not to end up in the many-branch support game. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 20:54:50 2008 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 ADE05106564A for ; Mon, 22 Sep 2008 20:54:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 789588FC16 for ; Mon, 22 Sep 2008 20:54:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 136A646B03; Mon, 22 Sep 2008 16:54:50 -0400 (EDT) Date: Mon, 22 Sep 2008 21:54:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jo Rhett In-Reply-To: <7FC02881-91A6-4A2B-B58F-A4D1671B9978@netconsonance.com> Message-ID: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> <7FC02881-91A6-4A2B-B58F-A4D1671B9978@netconsonance.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: netgeek , freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 22 Sep 2008 20:54:50 -0000 On Mon, 22 Sep 2008, Jo Rhett wrote: > On Sep 21, 2008, at 1:57 AM, Robert Watson wrote: >> This is precisely what we already do -- we guarantee we will support the >> last release on a branch for 24 months after the release. The point of >> concern being discussed is that we can't tell you for sure which minor >> release will be the last release at the time that release goes out the >> door, because the extent to which we keep releasing on old branches depends >> in large part on how the new branch looks. > > I think you are using "last release" in a different way. "the last release" > is always the most release release. Right now 6.3 will have support for > longer than 6.4 will, which is the nature of the problem I raised. If you > always supported the most recent release for 24 months then we wouldn't have > any problem. My calendar disagrees with you on this point -- 18 months from September, 2008, is after 24 months from January, 2008. And I think it's much more likely the release will go out in October. > I mean seriously, if you were to say "We will support 6.4 for 24 months > *unless* we find it necessary to release 6.5 then I'd be totally happy. > But that's not what is being said. I think we pretty much are saying that: whatever the final release is will be supported for 24 months. 6.4 will likely be it on 6.x, but we're not 100% committed to that being the final decision because we want to see 7.1 shake out well. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 21:56:09 2008 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 C272C106564A for ; Mon, 22 Sep 2008 21:56:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC588FC29 for ; Mon, 22 Sep 2008 21:56:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 22764 invoked by uid 399); 22 Sep 2008 21:56:08 -0000 Received: from localhost (HELO ?192.168.0.12?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Sep 2008 21:56:08 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48D81476.4050309@FreeBSD.org> Date: Mon, 22 Sep 2008 14:56:06 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Jo Rhett References: <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <20080920020703.GA82392@phat.za.net> <851F09A2-788D-4343-9E00-A0AB5C3AC063@netconsonance.com> <20080920044148.GA60230@in-addr.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: Upcoming Releases Schedule... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 21:56:09 -0000 Jo Rhett wrote: > On Sep 19, 2008, at 9:41 PM, Gary Palmer wrote: >> Or to put it another way, what to you is "support" in terms of >> FreeBSD releases. As far as I am aware, if you stick on a >> RELENG_X_Y_Z_RELEASE tag >> then the most you get is security fixes. No new features, >> no new drivers, no bugfixes. So if I am interpreting things >> correctly, you are asking for security fixes to be ported to >> RELEASE tagged branches for longer? > > That is what I and my $EMPLOYER want yes, although as I said I am > willing to support other efforts. (ie I am unlikely to be the > difference between make or break on this effort, so if more support was > something that got other businesses involved enough to achieve that > change, then....) Just to be clear, what you are interested in is a longer support period for security patches to be merged into a branch such as RELENG_6_3 (which only has security fixes applied to it now). Is that correct? Assuming that I'm correct on that assumption, I would suggest that you gather a community of people who share a similar interest and quite simply do the work. It should be pretty obvious based on any given security advisory what will need to change, and if you get enough people involved there won't be that much work for any one person or company. There is even a mailing list for this sort of thing, freebsd-eol. It's not very active right now, but that doesn't mean you can't change that. As Robert pointed out, project history is such that those who identify a given need and fill it are generally "absorbed" into the "official" canon as it were, so at some point in the future you (pl.) might actually become part of the answer to the "more resources" questions that you keep insisting on an answer to. I'd also like to point out that there is another chicken-egg problem that has been glossed over in this thread. You have said many times that it's hard for a company to devote resources to testing a given release candidate without knowing in advance how long that release will be supported. Several people (including Robert, who is part of the release team) have said that we can't make a firm conclusion on how long a given release will be supported until we have a pretty good idea how "successful" a given release will be, which requires people actually testing and using it. Do you see the problem? Finally I would like to suggest that everyone interested in the problems of supporting releases for longer than their announced EOL to please take that discussion to the freebsd-eol list. AFAICT it isn't really on topic for -stable. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 22:04:40 2008 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 96BC81065675 for ; Mon, 22 Sep 2008 22:04:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 1F79F8FC17 for ; Mon, 22 Sep 2008 22:04:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 26415 invoked by uid 399); 22 Sep 2008 21:37:59 -0000 Received: from localhost (HELO ?192.168.0.12?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Sep 2008 21:37:59 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48D81034.6080607@FreeBSD.org> Date: Mon, 22 Sep 2008 14:37:56 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Dylan Cochran References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Benefits of multiple release branches (Was: Re: Upcoming Releases Schedule...) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 22:04:40 -0000 Dylan Cochran wrote: > One of the biggest (and most prominent, though not obviously so) > issues is the lack of concurrency with regards to releases. With the > default system, having multiple freebsd releases side by side (both > different versions, and different architectures) is infeasible. This > makes the choice more critical, while hindering flexibility. The > necessity of long support schedules is one of the symptoms. While on the one hand I can understand the users' frustration on this point, IMO having at least 2 release branches is necessary. We are trying to walk the fine line between pleasing those who want new features (including new drivers), better performance, etc. that a newer release branch offers (in this case 7.x) and those that want long-term API stability, and other forms of stability that an "established" release offers. The only practical way to accomplish both of those goals is with 2 release branches. Speaking only for myself, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 22:27:59 2008 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 C38FB106564A; Mon, 22 Sep 2008 22:27:59 +0000 (UTC) (envelope-from ozbilgin@hotmail.com) Received: from bay0-omc3-s18.bay0.hotmail.com (bay0-omc3-s18.bay0.hotmail.com [65.54.246.218]) by mx1.freebsd.org (Postfix) with ESMTP id A22E38FC13; Mon, 22 Sep 2008 22:27:59 +0000 (UTC) (envelope-from ozbilgin@hotmail.com) Received: from BAY138-W45 ([64.4.49.80]) by bay0-omc3-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Sep 2008 15:27:59 -0700 Message-ID: X-Originating-IP: [88.230.246.57] From: =?windows-1254?Q?yusuf_=F6zbilgin?= To: Jeremy Chadwick Date: Tue, 23 Sep 2008 01:27:58 +0300 Importance: Normal In-Reply-To: <20080922001316.GA12112@icarus.home.lan> References: <20080920225314.GA84482@icarus.home.lan> <20080921134937.GB977@icarus.home.lan> <20080922001316.GA12112@icarus.home.lan> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Sep 2008 22:27:59.0409 (UTC) FILETIME=[77D0EA10:01C91D02] Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bu7cher@yandex.ru, freebsd-stable@freebsd.org, sos@freebsd.org Subject: RE: Freebsd custom installation cd 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, 22 Sep 2008 22:27:59 -0000 I updated /usr/src with cvsup and recompiled the kernel This error still continue. :( System is 7.0-RELEASE. > Date: Sun, 21 Sep 2008 17:13:16 -0700> From: koitsu@FreeBSD.org> To: ozbilgin@hotmail.com> CC: bu7cher@yandex.ru; freebsd-stable@freebsd.org; sos@freebsd.org> Subject: Re: Freebsd custom installation cd> > On Mon, Sep 22, 2008 at 01:47:06AM +0300, yusuf özbilgin wrote:> > ata8-master --> ata8 --> atapci1> > and atapci1 is Intel Ahci Controller.> > I used GENERIC conf file and recompile the kernel but the problem is still exist. (I am using freebsd7)> > Before you rebuilt the kernel, did you update /usr/src using csup or> cvsup? If so, then it sounds like there's a bug somewhere in the ata(4)> code which is causing this problem.> > The code was recently modified (3 days ago), which sounds very> suspicious.> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-chipset.c> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-pci.c> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-pci.h> > I've CC'd the responsible parties. They should be able to work with y ou> to find out what the problem is.> > > Then I added IDE disk to the system The system didnt detect the ide disk.> > > > This mainboard is G33 chipset Intel mainboard (BOXDG33FBC) (first mail was wrong)> > I can't explain this one.> > > I try to mount floppy to save the dmesg output while installation but It also gave the error > > g_vfs_done(): fd0[read(offset=0, length=8192)] error = 6> > There have been recent reports of the floppy disk driver in FreeBSD not> working.> > > I thougt that may be floopy or diskette error I tried to mount usb mass storage then > > It gave the "umass0 BBB reset failed timeout" error and stoped the booting.> > This is a separate problem and is known. AFAIK there is no fix, other> than to try 8.0-CURRENT which contains a new USB stack.> > > I tried different G33 chipset Intel mainboard (BOXDG33FBC) but problem continued.> > > > I tried with freebsd 6.2 cd it also didnt detect the disk.> > > > Freebsd7 installation cd is not giving any error. > > Can you please provide exact FreeBSD versions and not just generic> strings? We need to know if you're talking about FreeBSD 6.2-RELEASE,> 6.2-STABLE, 7.0-RELEASE, 7.0-STABLE, 7.1-BETA, etc...> > -- > | Jeremy Chadwick jdc at parodius.com |> | Parodius Networking http://www.parodius.com/ |> | UNIX Systems Administrator Mountain View, CA, USA |> | Making life hard for others since 1977. PGP: 4BD6C0CB |> > _______________________________________________> 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 Sep 22 22:46:21 2008 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 6893B1065672 for ; Mon, 22 Sep 2008 22:46:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3211A8FC1A for ; Mon, 22 Sep 2008 22:46:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 9C78E46B32; Mon, 22 Sep 2008 18:46:20 -0400 (EDT) Date: Mon, 22 Sep 2008 23:46:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jo Rhett In-Reply-To: Message-ID: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> <7FC02881-91A6-4A2B-B58F-A4D1671B9978@netconsonance.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: netgeek , freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 22 Sep 2008 22:46:21 -0000 On Mon, 22 Sep 2008, Robert Watson wrote: >> I think you are using "last release" in a different way. "the last >> release" is always the most release release. Right now 6.3 will have >> support for longer than 6.4 will, which is the nature of the problem I >> raised. If you always supported the most recent release for 24 months then >> we wouldn't have any problem. > > My calendar disagrees with you on this point -- 18 months from September, > 2008, is after 24 months from January, 2008. And I think it's much more > likely the release will go out in October. ... but the wrong calendar -- I was using 18 rather than 12 months, not sure where that came from. >> I mean seriously, if you were to say "We will support 6.4 for 24 months >> *unless* we find it necessary to release 6.5 then I'd be totally happy. But >> that's not what is being said. > > I think we pretty much are saying that: whatever the final release is will > be supported for 24 months. 6.4 will likely be it on 6.x, but we're not > 100% committed to that being the final decision because we want to see 7.1 > shake out well. The key point here holds, however: I think we should not ever be in the position of telling people that support lifetime on a release has been reduced. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 23:18:21 2008 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 6E715106564A for ; Mon, 22 Sep 2008 23:18:21 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB648FC0C for ; Mon, 22 Sep 2008 23:18:20 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: by gxk10 with SMTP id 10so3621151gxk.19 for ; Mon, 22 Sep 2008 16:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=D9nOmOdCFMX4iufT7KL4+j1eHd//vmLBDavA7nnhBnw=; b=j7bJ/tFtsJVKmnJ0StYbfjGXIUf5VUjRASRN5eUBjmzzXUvab3gHWr+BggKeKx6i2F o9wDttEHQT8BRqQvrczrLV3X+48qRX/wWZv4YL62p9moXfnCkqPEgJAgeiELEEKpggbj LPuJKODJzXQ7fZ8TvHDU2dYs97+Vx3y9nEIOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=RqLbTPB/sPjjb6x9kMI9oJXvZKBtvz/lXlsuYBcbu1moBilcnuJvMyYP/EH/jOtVof CRY34AbIsYbjooOI2owfazCyKD0hHzEV3GXQqyzaZ0GVnZq/Z0paNeeoWjIesT3Ji9pm GE+LTxuHs1VOsdjlg5JcWYcmWvU4eUEQzXu3g= Received: by 10.90.33.5 with SMTP id g5mr5416389agg.50.1222125500231; Mon, 22 Sep 2008 16:18:20 -0700 (PDT) Received: by 10.90.80.14 with HTTP; Mon, 22 Sep 2008 16:18:20 -0700 (PDT) Message-ID: Date: Mon, 22 Sep 2008 19:18:20 -0400 From: "Dylan Cochran" Sender: heliocentric@gmail.com To: freebsd-stable@freebsd.org In-Reply-To: <48D81034.6080607@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <48D81034.6080607@FreeBSD.org> X-Google-Sender-Auth: 0e7e1cc5df7cf699 Subject: Re: Benefits of multiple release branches (Was: Re: Upcoming Releases Schedule...) 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, 22 Sep 2008 23:18:21 -0000 On Mon, Sep 22, 2008 at 5:37 PM, Doug Barton wrote: > Dylan Cochran wrote: >> One of the biggest (and most prominent, though not obviously so) >> issues is the lack of concurrency with regards to releases. With the >> default system, having multiple freebsd releases side by side (both >> different versions, and different architectures) is infeasible. This >> makes the choice more critical, while hindering flexibility. The >> necessity of long support schedules is one of the symptoms. > > While on the one hand I can understand the users' frustration on this > point, IMO having at least 2 release branches is necessary. We are > trying to walk the fine line between pleasing those who want new > features (including new drivers), better performance, etc. that a newer > release branch offers (in this case 7.x) and those that want long-term > API stability, and other forms of stability that an "established" > release offers. The only practical way to accomplish both of those goals > is with 2 release branches. I agree completely. My point is that as of right now, there is a large degree of collisions that take place, that prevent an install of 6.3-RELEASE and 7.0-RELEASE from existing at the same time on the same drive, and being trivial to switch between the two if need be. Same as with i386/amd64. This is an artificial construct, and doesn't /have/ to continue existing. Which imo, will be far more useful then expecting a large amount of time expended to dead-end branches of code that are well past their expiration date, and begin suffering from massive bitrot. At the very least, it will make the default system more robust by moving the majority of the upgrade procedure from being /replacements/ of files, to creating new files coupled with an atomic activation 'switch'. Please don't misinterpret my ideas as being supporting his viewpoint, merely pointing out a perspective to the problem which hasn't been mentioned. From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 00:00:32 2008 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 F0755106564A; Tue, 23 Sep 2008 00:00:32 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id CC0068FC08; Tue, 23 Sep 2008 00:00:32 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8N00UI6016237; Mon, 22 Sep 2008 17:00:30 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.412] Message-Id: From: Jo Rhett To: Robert Watson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 17:00:24 -0700 References: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <20080920020703.GA82392@phat.za.net> <851F09A2-788D-4343-9E00-A0AB5C3AC063@netconsonance.com> <4d7dd86f0809192057s33dfd92fv598488a4c05ada14@mail.gmail.com> <4B2A556D-B13D-4B71-819A-F9B23C5685AF@netconsonance.com> <20080920205645.GI1151@arthur.nitro.dk> <75E31E23-23BA-4A5D-90F1-984C8C0AC895@netconsonance.com> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-stable , "Simon L. Nielsen" Subject: Re: Release team resources 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, 23 Sep 2008 00:00:33 -0000 On Sep 22, 2008, at 1:08 PM, Robert Watson wrote: > I'm not sure I agree with this analysis ... > Counting on my fingers, that's 7 FreeBSD-specific, 4 that lie in > code we basically maintain, and 8 that are in externally maintained > software. Seems like a pretty even split. Acknowledged, sorry I was working from memory and forgot that the things we had to patch for already went through a "does it affect us" filter :-( You're right. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 00:05:55 2008 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 6FEBC1065672; Tue, 23 Sep 2008 00:05:55 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 44B928FC14; Tue, 23 Sep 2008 00:05:55 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8N05n7P016318; Mon, 22 Sep 2008 17:05:49 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Amavis-Modified: Mail body modified (defanged) by mail.netconsonance.com X-Quarantine-ID: <92mje9vkoLPM> X-Virus-Scanned: amavisd-new at netconsonance.com X-Amavis-Alert: BAD HEADER, Header line longer than 998 characters: References: <12...\n X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.410] Message-Id: From: Jo Rhett To: Robert Watson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 17:05:43 -0700 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <58B648A5-4F9D-4C02-9A1C-21E1294DEB7A@netconsonance.com> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 23 Sep 2008 00:05:55 -0000 On Sep 22, 2008, at 1:32 PM, Robert Watson wrote: > Long answer: we're under-manned for our current commitments, and > have seen longer advisory cycles than we would like. My guess is > that we could eat the first 25% of a person just catching up on > current obligations so as to reduce latency on advisories, handle > back-analysis of reports that don't appear to be vulnerabilities but > we'd like to be sure, etc. > > Another hand-wave: 50%-75% of a person would allow us to move into > extending our obligations as well as put more resources into > proactive work. You don't have to be on the security team to work > on security work (and many people who do aren't), but certainly one > obligation that comes with being on the team is to try to > proactively address vulnerability classes and improve infrastructure > for issuing advisories, providing updates, etc. > > All hand-waving, understand. Depends a lot on the person, the > season (reports don't arrive at a constant rate), etc. Thanks for the detail, and I think we all understand the necessary vagueness. Is "a person" 40 hours a week? So if I could commit 10 hours a week, I'm 1/4 of a person in this context? (assuming there was enough trust/etc that I could even do the work -- just for discussion) > Tricky balance -- if you cut a major release every 18-24 months, you > have a 24-month support cycle on the final point release on each > branch, and you continue to release minor releases after the .0 of > the next branch in order to allow .0's to settle for a bit before > forcing migration forward, it's hard not to end up in the many- > branch support game. > That's true. I've never been a huge fan of "release often" in production systems ;-) That being said, I was working on Debian when they went through the Woody/Sarge era, and frankly I think that distinct production/ development tracks work even less well so it's not like I have useful advice here ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 00:10:09 2008 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 BC02F106566C; Tue, 23 Sep 2008 00:10:09 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 93E5D8FC15; Tue, 23 Sep 2008 00:10:09 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8N09vq8016416; Mon, 22 Sep 2008 17:09:57 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.408] Message-Id: <10CD6E03-D560-4F58-9157-0CC511EBFB48@netconsonance.com> From: Jo Rhett To: Robert Watson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 17:09:51 -0700 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> <7FC02881-91A6-4A2B-B58F-A4D1671B9978@netconsonance.com> X-Mailer: Apple Mail (2.929.2) Cc: netgeek , freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 23 Sep 2008 00:10:09 -0000 On Sep 22, 2008, at 1:54 PM, Robert Watson wrote: >>> This is precisely what we already do -- we guarantee we will >>> support the last release on a branch for 24 months after the >>> release. The point of concern being discussed is that we can't >>> tell you for sure which minor release will be the last release at >>> the time that release goes out the door, because the extent to >>> which we keep releasing on old branches depends in large part on >>> how the new branch looks. >> >> I think you are using "last release" in a different way. "the last >> release" is always the most recent release. Right now 6.3 will >> have support for longer than 6.4 will, which is the nature of the >> problem I raised. If you always supported the most recent release >> for 24 months then we wouldn't have any problem. > > My calendar disagrees with you on this point -- 18 months from > September, 2008, is after 24 months from January, 2008. And I think > it's much more likely the release will go out in October. As I understand it, 6.3 will EoL in January of 2010. 6.4 will EoL in October of 2009. This is the head-scratcher that leaves me so very confused, and unable to figure out how to explain this to a businessperson. If it worked as you said -- the "latest release" is guaranteed 24 months but any previous release support ends at some point after the next release is out, then it's easy to explain to management. "Doing this upgrade gives you a minimum of 24 months of support" >> I mean seriously, if you were to say "We will support 6.4 for 24 >> months *unless* we find it necessary to release 6.5 then I'd be >> totally happy. But that's not what is being said. > > I think we pretty much are saying that: whatever the final release > is will be supported for 24 months. 6.4 will likely be it on 6.x, > but we're not 100% committed to that being the final decision > because we want to see 7.1 shake out well. Again, how do you explain that? And how do you explain a 3 month window where 6.3 is supported longer than 6.4? (not trying to be accusative or demanding, it's just a fairly odd situation) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 00:12:13 2008 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 842C0106566B for ; Tue, 23 Sep 2008 00:12:13 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 630918FC0C for ; Tue, 23 Sep 2008 00:12:13 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8N0CBaa016557 for ; Mon, 22 Sep 2008 17:12:11 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.407] Message-Id: <1E49BF55-D408-4E84-8E32-19D5112D89FB@netconsonance.com> From: Jo Rhett To: freebsd-stable In-Reply-To: <48D81476.4050309@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 17:12:05 -0700 References: <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <20080920020703.GA82392@phat.za.net> <851F09A2-788D-4343-9E00-A0AB5C3AC063@netconsonance.com> <20080920044148.GA60230@in-addr.com> <48D81476.4050309@FreeBSD.org> X-Mailer: Apple Mail (2.929.2) Cc: Subject: Re: Upcoming Releases Schedule... 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, 23 Sep 2008 00:12:13 -0000 On Sep 22, 2008, at 2:56 PM, Doug Barton wrote: > I'd also like to point out that there is another chicken-egg problem > that has been glossed over in this thread. You have said many times > that > it's hard for a company to devote resources to testing a given release > candidate without knowing in advance how long that release will be > supported. Several people (including Robert, who is part of the > release > team) have said that we can't make a firm conclusion on how long a > given > release will be supported until we have a pretty good idea how > "successful" a given release will be, which requires people actually > testing and using it. Do you see the problem? Yes, I do. And I'm confused as to why the release cycle is structured to keep this problem going. This is your own chicken and egg, and it's a fairly easy one to solve. Nobody else is creating the chicken and egg for FreeBSD, it's being created by the existing policy. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 00:18:40 2008 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 A388C1065676; Tue, 23 Sep 2008 00:18:40 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7727E8FC0C; Tue, 23 Sep 2008 00:18:40 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8N0ISxe016665; Mon, 22 Sep 2008 17:18:28 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Amavis-Modified: Mail body modified (defanged) by mail.netconsonance.com X-Quarantine-ID: X-Virus-Scanned: amavisd-new at netconsonance.com X-Amavis-Alert: BAD HEADER, Header line longer than 998 characters: References: <12...\n X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.405] Message-Id: From: Jo Rhett To: Robert Watson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 17:18:22 -0700 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> <7FC02881-91A6-4A2B-B58F-A4D1671B9978@netconsonance.com> X-Mailer: Apple Mail (2.929.2) Cc: netgeek , freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 23 Sep 2008 00:18:40 -0000 On Sep 22, 2008, at 3:46 PM, Robert Watson wrote: > The key point here holds, however: I think we should not ever be in > the position of telling people that support lifetime on a release > has been reduced. I agree. However, there are other ways of doing this than to create overlapping windows of support. (totally whistling in the wind for a moment) This isn't an absolute number, but what about something like this? (it should probably be rewritten) -REL will be supported for a minimum of 12 months. It will be extended if * if no other release of the major version is planned, it will be extended 12 additional months. (24 total) * if another release is planned, it will be supported for 3 months past the date of the next release. This isn't actually all that much different from the actuality of your existing practice, but it provides a reasonable guideline that a business can understand. It's also always incrementally forward, and doesn't reward a business for staying behind on a previous release - like your existing policy is doing right now. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 02:47:30 2008 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 05830106564A for ; Tue, 23 Sep 2008 02:47:30 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 87CE08FC1C for ; Tue, 23 Sep 2008 02:47:29 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so464762eyi.7 for ; Mon, 22 Sep 2008 19:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=wPGxQt11cmu0IWqBzquOStUqDmvA5EoVeekuIkU+pwo=; b=iv9SSLrBAVZbWj/eGLMwm2C1aBT5JtoNSOb9AYgkkIOVvRHMMw8luxEl2DfSzh+jCD cor+YhpXN86dItxz98Tnw8Edgwwh/KrUKZf7janJIJ9EImhiBURO8VEI7BoevO3RwApS 54e3hx0lf/YA92Np2RExMypvor/pOIFVef2U0= 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=IIAGiEGi69aIJuyBSCUxm65ojogpOSWD7cN3gjOmb/4UI29mSoxU9CeUqpA2NF1lBN nwEX7JiMwY8cqMVrc8M3F8S0XE9DpoRpih0gAGyLNEaqF+lWZ2RQqHmwcpFJpkKY89Wg DBl1l8xFcXbFR3ppi1oQse89xWgUPP5gqa2kE= Received: by 10.102.253.6 with SMTP id a6mr3292075mui.92.1222138047557; Mon, 22 Sep 2008 19:47:27 -0700 (PDT) Received: by 10.103.231.14 with HTTP; Mon, 22 Sep 2008 19:47:27 -0700 (PDT) Message-ID: Date: Mon, 22 Sep 2008 23:47:27 -0300 From: "Carlos A. M. dos Santos" To: "Jeff Blank" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080910203445.GA8561@mr-happy.com> Cc: freebsd-stable@freebsd.org Subject: Re: can't see non-root writes to /dev/console 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, 23 Sep 2008 02:47:30 -0000 On Wed, Sep 10, 2008 at 10:54 PM, Carlos A. M. dos Santos wrote: > On Wed, Sep 10, 2008 at 5:34 PM, Jeff Blank wrote: >> I just upgraded a RELENG_7 (amd64) box from 20080714 to "latest" >> (which seems to be from a few days ago--no changes from Monday >> morning's csup to today's) and can no longer see the effect of writing >> to /dev/console as non-root. When I log in using xdm, my user owns >> /dev/console, mode 0622 (-rw--w--w-), and I start an 'xterm -C'. But >> when I, for example, >> >> echo foo > /dev/console >> >> I see nothing in the console xterm. No error messages, and echo exits >> 0. If I su to root and do the same, I get 'foo' in the same console >> xterm. Syslog messages to /dev/console also appear, of course. All >> the above applies to xconsole as well, not just xterm. I did >> recompile xterm from 20080616 ports, but it didn't fix the issue >> (didn't expect it to, as xterm clearly has no trouble attaching and >> reading). So my echo is getting lost in the kernel, I guess. >> >> Known problem? Intentional change? Something else? > > I have seen this problem since 6.x times and still on 7.x. I also > noticed that if I send something to the console after xconsole starts > then I can sned messages as an ordinary user. My workaround was > modifying the Xsetup_0 script (I used xdm for login), adding a line > with > > (sleep 3; date >> "$dev_console") & > > just after starting xconsole. > > I didn't have time to set up a machine with 8-CURRENT yet, so I could > not check if the new mp-safe tty implementation fixes this, either > intentionally or by a fortunate side effect. > > -- > cd /usr/ports/sysutils/life > make clean What happens if you use xconsole -f /dev/console ? -- cd /usr/ports/sysutils/life make clean From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 02:54:28 2008 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 6E65C1065678 for ; Tue, 23 Sep 2008 02:54:28 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from goat.gigo.com (ipv6.gigo.com [IPv6:2001:470:1:18::2]) by mx1.freebsd.org (Postfix) with ESMTP id 54E608FC1E for ; Tue, 23 Sep 2008 02:54:28 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from 201.88.58.13 (201-88-58-13.bsace702.dsl.brasiltelecom.net.br [201.88.58.13]) by goat.gigo.com (Postfix) with ESMTPA id 2F25517074 for ; Mon, 22 Sep 2008 19:54:27 -0700 (PDT) Received: (qmail 59270 invoked from network); 22 Sep 2008 23:47:38 -0300 Received: from unknown (HELO exxodus.fedaykin.here) (127.0.0.1) by exxodus.fedaykin.here with SMTP; 22 Sep 2008 23:47:38 -0300 Message-ID: <48D858CA.4020003@uol.com.br> Date: Mon, 22 Sep 2008 23:47:38 -0300 From: Mario Sergio Fujikawa Ferreira User-Agent: Thunderbird 2.0.0.16 (X11/20080802) MIME-Version: 1.0 To: Robert Watson References: <20080921103940.74650.qmail@exxodus.fedaykin.here> (sfid-20080921_11541_F7911005) In-Reply-To: (sfid-20080921_11541_F7911005) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 7.1-PRERELEASE panic rw_rlock (udpinp) 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, 23 Sep 2008 02:54:28 -0000 Hi, That seems to be working. I've been up and running for 2 hours now with your patch. The machine is a bit slow but I have both WITNESS and INVARIANTS enabled to make sure everything is fine. Rergads, Mario Robert Watson wrote: > > On Sun, 21 Sep 2008, Mario Sergio Fujikawa Ferreira wrote: > >> I've been running FreeBSD 7.0-STABLE from August 1 without problems. >> >> I tried updating to the latest -STABLE but I got a system panic. > > Hi Mario-- > > This is a known problem, and will hopefully be resolved shortly. In > essence, the v4 compatibility path for v6 socket is invoking the v4 code > with locks held that upset the v4 code. > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> ---- >> panic: _rw_rlock (udpinp): wlock already held @ >> /usr/src/sys/netinet/udp_usrreq.c >> ---- >> >> FreeBSD 7.1-PRERELEASE #18: Sat Sep 20 23:38:22 BRT 2008 >> >> Regards, >> Mario Ferreira >> >> ---- >> >> - Kernel configuration >> http://people.freebsd.org/~lioux/panic/2008092100/KERNCONF >> >> - syslog output >> http://people.freebsd.org/~lioux/panic/2008092100/all.log >> http://people.freebsd.org/~lioux/panic/2008092100/messages >> >> - dmesg.boot >> http://people.freebsd.org/~lioux/panic/2008092100/dmesg.boot >> >> - kldstat >> http://people.freebsd.org/~lioux/panic/2008092100/kldstat.txt >> >> - /boot/loader.conf >> http://people.freebsd.org/~lioux/panic/2008092100/loader.conf >> >> - 'pciconf -lv' >> http://people.freebsd.org/~lioux/panic/2008092100/pciconf.txt >> >> - 'sysctl -a' >> http://people.freebsd.org/~lioux/panic/2008092100/sysctl.txt >> >> - /etc/sysctl.conf >> http://people.freebsd.org/~lioux/panic/2008092100/sysctl.conf >> >> -- >> Mario S F Ferreira - DF - Brazil - "I guess this is a signature." >> feature, n: a documented bug | bug, n: an undocumented feature >> _______________________________________________ >> 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" >> > _______________________________________________ > 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 Tue Sep 23 05:12:11 2008 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 B1E04106564A; Tue, 23 Sep 2008 05:12:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forwards3.yandex.ru (forwards3.yandex.ru [213.180.223.174]) by mx1.freebsd.org (Postfix) with ESMTP id 2B35B8FC15; Tue, 23 Sep 2008 05:12:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp5.yandex.ru (smtp5.yandex.ru [77.88.32.24]) by forwards3.yandex.ru (Postfix) with ESMTP id E8ED24C57BD; Tue, 23 Sep 2008 09:12:08 +0400 (MSD) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:3816 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S1053120AbYIWFMA (ORCPT + 2 others); Tue, 23 Sep 2008 09:12:00 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp5 X-Yandex-TimeMark: 1222146720 X-MsgDayCount: 3 X-Comment: RFC 2476 MSA function at smtp5.yandex.ru logged sender identity as: bu7cher Message-ID: <48D87A9D.60108@yandex.ru> Date: Tue, 23 Sep 2008 09:11:57 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Joseph Olatt References: <20080915192515.A13327@eskimo.com> <48D7260C.9020503@yandex.ru> <20080922082957.A20123@eskimo.com> In-Reply-To: <20080922082957.A20123@eskimo.com> Content-Type: multipart/mixed; boundary="------------020703090304020505010506" Cc: FreeBSD Mailing List , =?UTF-8?B?U8O4cmVu?= =?UTF-8?B?IFNjaG1pZHQ=?= Subject: Re: unsupported NVIDIA SATA controller 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, 23 Sep 2008 05:12:11 -0000 This is a multi-part message in MIME format. --------------020703090304020505010506 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Joseph Olatt wrote: >>> none13@pci0:0:14:0: class=0x010485 card=0x01371025 chip=0x07f810de rev=0xa2 hdr=0x00 >>> vendor = 'Nvidia Corp' >>> class = mass storage >>> subclass = RAID >> Do you still have this problem? >> It seems that your controller is AHCI-capable. >> I can make a patch if is it needed. > > Yes, I'm still have the above problem. And, yes, the controller appears > to be ACHI-capable (at least according to Ubuntu. see [1]) > > I would greatly appreciate a patch if you can provide one. > > regards, > joseph > > > [1]: http://www.eskimo.com/~joji/nvidia_sata/ Hi, Joseph. Try attached patch. -- WBR, Andrey V. Elsukov --------------020703090304020505010506 Content-Type: text/plain; name="ata_nvidia_ahci.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ata_nvidia_ahci.diff" SW5kZXg6IHNyYy9zeXMvZGV2L2F0YS9hdGEtY2hpcHNldC5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNT IGZpbGU6IC9uY3ZzL3NyYy9zeXMvZGV2L2F0YS9hdGEtY2hpcHNldC5jLHYKcmV0cmlldmlu ZyByZXZpc2lvbiAxLjIyNQpkaWZmIC11IC1wIC1yMS4yMjUgYXRhLWNoaXBzZXQuYwotLS0g c3JjL3N5cy9kZXYvYXRhL2F0YS1jaGlwc2V0LmMJMTUgQXVnIDIwMDggMTA6NTU6MTEgLTAw MDAJMS4yMjUKKysrIHNyYy9zeXMvZGV2L2F0YS9hdGEtY2hpcHNldC5jCTIzIFNlcCAyMDA4 IDA1OjA2OjI4IC0wMDAwCkBAIC0zMzcyLDcgKzMzNzIsOSBAQCBhdGFfbnZpZGlhX2lkZW50 KGRldmljZV90IGRldikKICAgICAgeyBBVEFfTkZPUkNFX01DUDYxX1MzLCAwLCAwLCAgICAg ICAgIE5WNHxOVlEsIEFUQV9TQTMwMCwgIm5Gb3JjZSBNQ1A2MSIgfSwKICAgICAgeyBBVEFf TkZPUkNFX01DUDY1LCAgICAwLCBBTUROVklESUEsIE5WSURJQSwgIEFUQV9VRE1BNiwgIm5G b3JjZSBNQ1A2NSIgfSwKICAgICAgeyBBVEFfTkZPUkNFX01DUDY3LCAgICAwLCBBTUROVklE SUEsIE5WSURJQSwgIEFUQV9VRE1BNiwgIm5Gb3JjZSBNQ1A2NyIgfSwKKyAgICAgeyBBVEFf TkZPUkNFX01DUDY3X0ExLCAwLCAwLCAgICAgICAgIE5WQUhDSSwgIEFUQV9TQTMwMCwgIm5G b3JjZSBNQ1A2NyIgfSwKICAgICAgeyBBVEFfTkZPUkNFX01DUDczLCAgICAwLCBBTUROVklE SUEsIE5WSURJQSwgIEFUQV9VRE1BNiwgIm5Gb3JjZSBNQ1A3MyIgfSwKKyAgICAgeyBBVEFf TkZPUkNFX01DUDczX0ExLCAwLCAwLCAgICAgICAgIE5WQUhDSSwgIEFUQV9TQTMwMCwgIm5G b3JjZSBNQ1A3MyIgfSwKICAgICAgeyBBVEFfTkZPUkNFX01DUDc3LCAgICAwLCBBTUROVklE SUEsIE5WSURJQSwgIEFUQV9VRE1BNiwgIm5Gb3JjZSBNQ1A3NyIgfSwKICAgICAgeyAwLCAw LCAwLCAwLCAwLCAwfX0gOwogCkBAIC0zMzgwLDcgKzMzODIsMTIgQEAgYXRhX252aWRpYV9p ZGVudChkZXZpY2VfdCBkZXYpCiAJcmV0dXJuIEVOWElPOwogCiAgICAgYXRhX3NldF9kZXNj KGRldik7Ci0gICAgY3Rsci0+Y2hpcGluaXQgPSBhdGFfbnZpZGlhX2NoaXBpbml0OworCisg ICAgaWYgKGN0bHItPmNoaXAtPmNmZzIgPT0gTlZBSENJKQorCWN0bHItPmNoaXBpbml0ID0g YXRhX2FoY2lfY2hpcGluaXQ7CisgICAgZWxzZQorCWN0bHItPmNoaXBpbml0ID0gYXRhX252 aWRpYV9jaGlwaW5pdDsKKwogICAgIHJldHVybiAwOwogfQogCkluZGV4OiBzcmMvc3lzL2Rl di9hdGEvYXRhLXBjaS5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9uY3ZzL3NyYy9zeXMv ZGV2L2F0YS9hdGEtcGNpLmgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuODkKZGlmZiAtdSAt cCAtcjEuODkgYXRhLXBjaS5oCi0tLSBzcmMvc3lzL2Rldi9hdGEvYXRhLXBjaS5oCTEwIEp1 bCAyMDA4IDIxOjM2OjUzIC0wMDAwCTEuODkKKysrIHNyYy9zeXMvZGV2L2F0YS9hdGEtcGNp LmgJMjMgU2VwIDIwMDggMDU6MDY6MjggLTAwMDAKQEAgLTI0Myw4ICsyNDMsMTAgQEAgc3Ry dWN0IGF0YV9jb25uZWN0X3Rhc2sgewogI2RlZmluZSBBVEFfTkZPUkNFX01DUDYxX1MyICAg ICAweDAzZjYxMGRlCiAjZGVmaW5lIEFUQV9ORk9SQ0VfTUNQNjFfUzMgICAgIDB4MDNmNzEw ZGUKICNkZWZpbmUgQVRBX05GT1JDRV9NQ1A2NSAgICAgICAgMHgwNDQ4MTBkZQorI2RlZmlu ZSBBVEFfTkZPUkNFX01DUDY3X0ExICAgICAweDA1NTAxMGRlCiAjZGVmaW5lIEFUQV9ORk9S Q0VfTUNQNjcgICAgICAgIDB4MDU2MDEwZGUKICNkZWZpbmUgQVRBX05GT1JDRV9NQ1A3MyAg ICAgICAgMHgwNTZjMTBkZQorI2RlZmluZSBBVEFfTkZPUkNFX01DUDczX0ExICAgICAweDA3 ZjgxMGRlCiAjZGVmaW5lIEFUQV9ORk9SQ0VfTUNQNzcgICAgICAgIDB4MDc1OTEwZGUKIAog I2RlZmluZSBBVEFfUFJPTUlTRV9JRCAgICAgICAgICAweDEwNWEKQEAgLTQ1MCw2ICs0NTIs NyBAQCBzdHJ1Y3QgYXRhX2Nvbm5lY3RfdGFzayB7CiAjZGVmaW5lIE5WSURJQSAgICAgICAg ICAweDAwMDQKICNkZWZpbmUgTlY0ICAgICAgICAgICAgIDB4MDAxMAogI2RlZmluZSBOVlEg ICAgICAgICAgICAgMHgwMDIwCisjZGVmaW5lIE5WQUhDSSAgICAgICAgICAweDAwNDAKICNk ZWZpbmUgVklBQ0xLICAgICAgICAgIDB4MDEwMAogI2RlZmluZSBWSUFCVUcgICAgICAgICAg MHgwMjAwCiAjZGVmaW5lIFZJQUJBUiAgICAgICAgICAweDA0MDAK --------------020703090304020505010506-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 07:45:15 2008 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 C49DF106566B for ; Tue, 23 Sep 2008 07:45:15 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 20EA08FC1B for ; Tue, 23 Sep 2008 07:45:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id m8N7jCrB065050; Tue, 23 Sep 2008 17:45:12 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 23 Sep 2008 17:45:11 +1000 (EST) From: Ian Smith To: Jo Rhett In-Reply-To: <7FC02881-91A6-4A2B-B58F-A4D1671B9978@netconsonance.com> Message-ID: <20080923163556.H76357@sola.nimnet.asn.au> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> <7FC02881-91A6-4A2B-B58F-A4D1671B9978@netconsonance.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable , Robert Watson , "Simon L. Nielsen" Subject: Re: Upcoming Releases Schedule... 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, 23 Sep 2008 07:45:15 -0000 On Mon, 22 Sep 2008, Jo Rhett wrote: > On Sep 21, 2008, at 1:57 AM, Robert Watson wrote: > > This is precisely what we already do -- we guarantee we will support the > > last release on a branch for 24 months after the release. The point of > > concern being discussed is that we can't tell you for sure which minor > > release will be the last release at the time that release goes out the > > door, because the extent to which we keep releasing on old branches depends > > in large part on how the new branch looks. > > I think you are using "last release" in a different way. "the last release" > is always the most release release. Right now 6.3 will have support for > longer than 6.4 will, which is the nature of the problem I raised. If you > always supported the most recent release for 24 months then we wouldn't have > any problem. Jo, it seems to be you who are trying to use "last" in an unusual way. The "last release on a branch" is not the latest one, but the last one. For 4.x that was .11 and for 5.x it was .5, where last means just that. > I mean seriously, if you were to say "We will support 6.4 for 24 months > *unless* we find it necessary to release 6.5 then I'd be totally happy. But > that's not what is being said. I believe that's exactly what has been said. rwatson@ and simon@ have both made it exceedingly clear, to me anyway, that if 6.4 is to be the last release on the 6.x branch - as appears to be likely but cannot be stated definitely at this time, for reasons clearly given and understood - then it will indeed be supported for 24 months. It doesn't seem reasonable to expect 24 months stated support for 6.4 if it turns out not to be the last release - that would then apply to 6.5. It also doesn't seem reasonable to expect that decision to be rushed in advance of the necessary evaluation of the success or otherwise of both 6.4 and 7.1 releases - especially when we're talking about these being only a month or so away anyway. While I do thank Robert and others for the level of patient detail gone into to explain all of this and other aspects of release and security engineering to you, me and everyone else, I rather hope re@ can be let alone to get on with the real work, beyond this 90+ message thread .. my 1.1%, Ian From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 09:46:27 2008 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 92FE1106567B for ; Tue, 23 Sep 2008 09:46:27 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6D2638FC18 for ; Tue, 23 Sep 2008 09:46:27 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id D1EE616562F for ; Tue, 23 Sep 2008 05:46:26 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 23 Sep 2008 05:46:26 -0400 X-Sasl-enc: CzBlP4opuzn+HkcFFmJb+MDVTaDUaWL3HPVnPpQEZfBs 1222163186 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 61AE820403 for ; Tue, 23 Sep 2008 05:46:26 -0400 (EDT) Message-ID: <48D8BAF1.1020602@incunabulum.net> Date: Tue, 23 Sep 2008 10:46:25 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: FreeBSD stable X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: fxp multicast forwarding 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: Tue, 23 Sep 2008 09:46:27 -0000 Hi, Whilst doing some QA work on XORP on my desktop, which has fxp0 and msk0, fxp0 got totally hosed. I was running PIM-SM and IGMPv2 router-mode on the box at the time. I wonder if this is related to the problems with fxp multicast transmission I saw back in April. I'm a bit concerned about this as fxp is still a very widespread and useful network chip. I am running 7.0-RELEASE-p4/amd64. sysctls for dev.fxp.0 are set to their default values. I'm not expert on the fxp driver internals, but perhaps someone else has seen this kind of problem before. Multicast-promiscuous mode (aka ALLMULTI) was enabled on the interface. I know some NICs have problems with this, or don't even support it. The errors look like this: fxp0: SCB timeout: 0x10 0x0 0x80 0x0 fxp0: SCB timeout: 0x10 0x0 0x80 0x0 fxp0: DMA timeout ... repeated ... Attempted workarounds which don't work to un-wedge the chip: Reload the fxp0 microcode with "ifconfig fxp0 link0" Forcibly unloading the kernel module and reloading it Unpatching and repatching at the switch (a cheap 10/100 one) Enabling and disabling promiscuous mode Twiddling dev.fxp.0.noflow The link status looks fine, but the card will not send or receive traffic. A warm reboot was enough to get things back up again. regards, BMS From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 10:06:03 2008 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 E5E5B106572A for ; Tue, 23 Sep 2008 10:06:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 939098FC19 for ; Tue, 23 Sep 2008 10:06:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA10.westchester.pa.mail.comcast.net with comcast id JA0d1a0030vyq2s5AA62a9; Tue, 23 Sep 2008 10:06:02 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA05.westchester.pa.mail.comcast.net with comcast id JA611a00A4v8bD73RA62yy; Tue, 23 Sep 2008 10:06:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=-Pjz0un6Z4JgZXN2MLQA:9 a=OE4EJ9pC7vIz1pNyk1RriTVXyPcA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 6E33117B81A; Tue, 23 Sep 2008 03:06:01 -0700 (PDT) Date: Tue, 23 Sep 2008 03:06:01 -0700 From: Jeremy Chadwick To: Bruce M Simpson Message-ID: <20080923100601.GA52531@icarus.home.lan> References: <48D8BAF1.1020602@incunabulum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48D8BAF1.1020602@incunabulum.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD stable , Jack Vogel Subject: Re: fxp multicast forwarding 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: Tue, 23 Sep 2008 10:06:04 -0000 On Tue, Sep 23, 2008 at 10:46:25AM +0100, Bruce M Simpson wrote: > Hi, > > Whilst doing some QA work on XORP on my desktop, which has fxp0 and > msk0, fxp0 got totally hosed. > I was running PIM-SM and IGMPv2 router-mode on the box at the time. > > I wonder if this is related to the problems with fxp multicast > transmission I saw back in April. > I'm a bit concerned about this as fxp is still a very widespread and > useful network chip. > > I am running 7.0-RELEASE-p4/amd64. > sysctls for dev.fxp.0 are set to their default values. > > I'm not expert on the fxp driver internals, but perhaps someone else has > seen this kind of problem before. Multicast-promiscuous mode (aka > ALLMULTI) was enabled on the interface. I know some NICs have problems > with this, or don't even support it. > > The errors look like this: > fxp0: SCB timeout: 0x10 0x0 0x80 0x0 > fxp0: SCB timeout: 0x10 0x0 0x80 0x0 > fxp0: DMA timeout > ... repeated ... > > Attempted workarounds which don't work to un-wedge the chip: > Reload the fxp0 microcode with "ifconfig fxp0 link0" > Forcibly unloading the kernel module and reloading it > Unpatching and repatching at the switch (a cheap 10/100 one) > Enabling and disabling promiscuous mode > Twiddling dev.fxp.0.noflow > > The link status looks fine, but the card will not send or receive traffic. > A warm reboot was enough to get things back up again. > > regards, > BMS Adding Jack Vogel, who's responsible for fxp(4). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 10:19:31 2008 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 8E5A31065670 for ; Tue, 23 Sep 2008 10:19:31 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from smtp.uol.com.br (smtpout5.uol.com.br [200.221.4.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1FE238FC19 for ; Tue, 23 Sep 2008 10:19:30 +0000 (UTC) (envelope-from lioux-list@uol.com.br) Received: from localhost (localhost [127.0.0.1]) by socom5.uol.com.br (Postfix) with ESMTP id 4A95F565 for ; Tue, 23 Sep 2008 07:05:54 -0300 (BRT) Received: from 201.88.58.13 (201-88-58-13.bsace702.dsl.brasiltelecom.net.br [201.88.58.13]) by socom5.uol.com.br (Postfix) with ESMTP id BB1285F9 for ; Tue, 23 Sep 2008 07:05:53 -0300 (BRT) Received: (qmail 14399 invoked from network); 23 Sep 2008 07:05:30 -0300 Received: from unknown (HELO exxodus.fedaykin.here) (127.0.0.1) by exxodus.fedaykin.here with SMTP; 23 Sep 2008 07:05:30 -0300 Message-ID: <48D8BF69.6060206@uol.com.br> Date: Tue, 23 Sep 2008 07:05:29 -0300 From: Mario Sergio Fujikawa Ferreira User-Agent: Thunderbird 2.0.0.16 (X11/20080802) MIME-Version: 1.0 To: Robert Watson References: (sfid-20080922_05543_31152F2E) In-Reply-To: (sfid-20080922_05543_31152F2E) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SIG5: 12a97db36798ace547330aca6452eea7 Cc: Norbert Papke , stable@FreeBSD.org Subject: Re: Possible UDP deadlock/panic fix 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, 23 Sep 2008 10:19:31 -0000 Hi, That seems to be working. I've been up and running for 7 hours now with your patch. The machine is a bit slow but I have both WITNESS and INVARIANTS enabled so as to make sure everything is fine. Rergads, Mario Robert Watson wrote: > > Attached is an MFC candidate for a patch I just merged to 8.x, which > corrects the UDP lock recursion issue both of you were running into. If > it settles well for a couple of days in HEAD then I'll go ahead and > request an MFC from re@, but your confirmation as to whether or not this > corrects the specific symptoms you are seeing would be very helpful. I > was able to confirm that it eliminated what appeared to be the same > problem here when I attempted to reproduce it based on the information > you provided, so I'm hopeful.\ > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > > > Property changes on: . > ___________________________________________________________________ > Modified: svn:mergeinfo > Merged /head/sys:r183265 > > Index: netinet6/udp6_usrreq.c > =================================================================== > --- netinet6/udp6_usrreq.c (revision 183265) > +++ netinet6/udp6_usrreq.c (working copy) > @@ -975,13 +975,23 @@ > error = EINVAL; > goto out; > } > + > + /* > + * XXXRW: We release UDP-layer locks before calling > + * udp_send() in order to avoid recursion. However, > + * this does mean there is a short window where inp's > + * fields are unstable. Could this lead to a > + * potential race in which the factors causing us to > + * select the UDPv4 output routine are invalidated? > + */ > + INP_WUNLOCK(inp); > + INP_INFO_WUNLOCK(&udbinfo); > if (sin6) > in6_sin6_2_sin_in_sock(addr); > pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs; > - error = ((*pru->pru_send)(so, flags, m, addr, control, > + /* addr will just be freed in sendit(). */ > + return ((*pru->pru_send)(so, flags, m, addr, control, > td)); > - /* addr will just be freed in sendit(). */ > - goto out; > } > } > #endif > _______________________________________________ > 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 Tue Sep 23 12:37:01 2008 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 3EAAE106566B; Tue, 23 Sep 2008 12:37:01 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id 89E528FC1F; Tue, 23 Sep 2008 12:37:00 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from [10.20.1.5] (unknown [10.0.0.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by netasq.netasq.com (Postfix) with ESMTP id AE70E2E65E; Tue, 23 Sep 2008 14:04:11 +0200 (CEST) Message-Id: <02117AD8-A70C-4B2A-9EA1-56A4847D845F@netasq.com> From: Fabien Thomas To: FreeBSD Stable List , FreeBSD Hackers In-Reply-To: <84dead720807122205i33bf6eb0p998d473df9e52304@mail.gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-30--948915904; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 23 Sep 2008 14:03:39 +0200 References: <84dead720807122205i33bf6eb0p998d473df9e52304@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Joseph Koshy Subject: Re: Announcement: PmcTools callchain capture for RELENG_7 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, 23 Sep 2008 12:37:01 -0000 --Apple-Mail-30--948915904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hello, A new patch is available that was done just after dtrace backport. You can find it like the previous one on the pmc wiki. It also include some new bugfix from head. Fabien Le 13 juil. 08 =E0 07:05, Joseph Koshy a =E9crit : > Hello List(s), > > I am very pleased to announce a patch, by Fabien Thomas, that brings > PmcTools' callchain capture features to 7-STABLE. Thank you, Fabien! > > The patch is linked to from the PmcTools wiki page: > http://wiki.freebsd.org/PmcTools. > > The current file name is: "patch-callchain-FreeBSD-7-=20 > STABLE-2008-07-12.gz". > As the file name indicates, it should apply against a 7-STABLE tree of > 2008-07-12 > vintage. > > To apply the patch: > % cd /home/src-7x # or whereever your RELENG_7 tree resides > % patch < PATCH-FILE > > Then you should follow the full procedure to update userland > and kernel from source as spelled out in src/UPDATING. > > Please note that HWPMC(4) log files that contain callchain =20 > information are > not binary compatible with prior versions of pmc(3) and pmcstat(8). > > Please do test on your systems and let Fabien and me know > how you fared. > > Koshy > --Apple-Mail-30--948915904-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 13:08:36 2008 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 1581F1065673 for ; Tue, 23 Sep 2008 13:08:36 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 476248FC23 for ; Tue, 23 Sep 2008 13:08:33 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 9EDFF1B10EF3; Tue, 23 Sep 2008 15:08:31 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 2F2631B10EF1; Tue, 23 Sep 2008 15:08:29 +0200 (CEST) Message-ID: <48D8EA4C.2090002@moneybookers.com> Date: Tue, 23 Sep 2008 16:08:28 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.16 (X11/20080813) MIME-Version: 1.0 To: Gavin Atkinson References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <1222090773.43647.16.camel@buffy.york.ac.uk> In-Reply-To: <1222090773.43647.16.camel@buffy.york.ac.uk> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94/8316/Tue Sep 23 11:40:56 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: Peter Jeremy , Dan Allen , freebsd-stable@FreeBSD.org, wxs@FreeBSD.org Subject: Re: iwn(4) (Intel 4965 wireless) backport 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, 23 Sep 2008 13:08:36 -0000 Hi Gavin, Gavin Atkinson wrote: > On Thu, 2008-09-04 at 18:48 +0100, Gavin Atkinson wrote: > >> On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: >> >>> On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: >>> >>> >>>> This is supported by the iwn(4) driver in CURRENT, and it should be >>>> quite easy to port the driver to 7-STABLE. If you're interested in >>>> reinstalling FreeBSD and testing a backported driver, I'm sure this >>>> can be sorted. >>>> >>> I am interested in doing this. Please advise on how I can get these >>> bits. >>> >> I've got hold of a laptop with the 4965 chipset in it, if nobody beats >> me to it I'll have a go at backporting the driver. >> > > OK, I've backported the iwn(4) driver for the Intel 4965 wireless > chipset to 7-STABLE. > > You need both of: > http://people.freebsd.org/~gavin/iwn-7/iwn-7.tgz > Loading if_iwn.ko make a nice reboot on my laptop. No messages just a reset... FreeBSD 7.0-STABLE #29: Tue Jul 29 16:13:47 EEST 2008 i386 May be I should try with more recent -stable ? > http://people.freebsd.org/~gavin/iwn-7/iwn-7.diff > > Both are relative to /usr and are against 7-STABLE (although may well > apply to 7.0-RELEASE cleanly). > > Please note that there are a couple of issues with this driver that > aren't seen with the driver in -HEAD. Firstly, it only supports B/G > channels, it doesn't work with 802.11a. Apparently this is due to a > firmware issue which the driver in -HEAD works around, although I don't > know how yet. > > Secondly, there may be a slight issue with regulatory domains. I'm not > certain about this, but I was seeing issues while trying to associate to > an access point on channel 13g, changing the AP to channel 1g fixes > things. > > Even with those two caveats, I can say that so far in my testing it's > been working very well. However, even if the driver works for you, I'm > pretty sure it's too late for a merge before 7.1. > > Lastly, as the laptop is on loan to me and I'm going to have to give it > back soon, I don't know if I'll have a chance to do any further work on > this driver. I'm still interested in stories of success or otherwise. > > Thanks, > > Gavin > _______________________________________________ > 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" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 14:11:18 2008 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 DC5B1106566C for ; Tue, 23 Sep 2008 14:11:18 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 5303B8FC1A for ; Tue, 23 Sep 2008 14:11:12 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id m8NEB9PJ004300; Tue, 23 Sep 2008 15:11:09 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Ki8bd-0003c3-RR; Tue, 23 Sep 2008 15:11:09 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id m8NEB9wB082516; Tue, 23 Sep 2008 15:11:09 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id m8NEB9H1082515; Tue, 23 Sep 2008 15:11:09 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Stefan Lambrev In-Reply-To: <48D8EA4C.2090002@moneybookers.com> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <1222090773.43647.16.camel@buffy.york.ac.uk> <48D8EA4C.2090002@moneybookers.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 23 Sep 2008 15:11:09 +0100 Message-Id: <1222179069.80882.19.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-stable@FreeBSD.org Subject: Re: iwn(4) (Intel 4965 wireless) backport 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, 23 Sep 2008 14:11:19 -0000 On Tue, 2008-09-23 at 16:08 +0300, Stefan Lambrev wrote: > Hi Gavin, > > Gavin Atkinson wrote: > > On Thu, 2008-09-04 at 18:48 +0100, Gavin Atkinson wrote: > > > >> On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: > >> > >>> On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: > >>> > >>> > >>>> This is supported by the iwn(4) driver in CURRENT, and it should be > >>>> quite easy to port the driver to 7-STABLE. If you're interested in > >>>> reinstalling FreeBSD and testing a backported driver, I'm sure this > >>>> can be sorted. > >>>> > >>> I am interested in doing this. Please advise on how I can get these > >>> bits. > >>> > >> I've got hold of a laptop with the 4965 chipset in it, if nobody beats > >> me to it I'll have a go at backporting the driver. > >> > > > > OK, I've backported the iwn(4) driver for the Intel 4965 wireless > > chipset to 7-STABLE. > > > > You need both of: > > http://people.freebsd.org/~gavin/iwn-7/iwn-7.tgz > > > Loading if_iwn.ko make a nice reboot on my laptop. > No messages just a reset... FreeBSD 7.0-STABLE #29: Tue Jul 29 16:13:47 > EEST 2008 i386 > May be I should try with more recent -stable ? Are you loading this while in X or on the console? If X, can you try from a console and see if anything else happens before the reboot (like a panic)? I don't believe there are any changes between 7.0 and stable that would result in a panic under an earlier version. You could try recompiling your kernel with "options GDB/KDB/DDB" and "makeoptions DEBUG=-g" and see if you get dropped to the debugger, if you do the result of the command "bt" would be very useful. Thanks, Gavin From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 14:49:11 2008 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 4E4941065676 for ; Tue, 23 Sep 2008 14:49:11 +0000 (UTC) (envelope-from fbsd-ml@scrapper.ca) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 16D858FC20 for ; Tue, 23 Sep 2008 14:49:10 +0000 (UTC) (envelope-from fbsd-ml@scrapper.ca) Received: from pd6ml1no-ssvc.prod.shaw.ca ([10.0.153.160]) by pd5mo1no-svcs.prod.shaw.ca with ESMTP; 23 Sep 2008 08:49:10 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=QV7RSNHABshzVYuhNucA:9 a=nULaEcLgH-yetzZ0bZ4y9J9zLz0A:4 a=ctAZk84f7NoA:10 Received: from s010600121729c74c.vc.shawcable.net (HELO proven.lan) ([24.85.241.34]) by pd6ml1no-dmz.prod.shaw.ca with ESMTP; 23 Sep 2008 08:49:08 -0600 Received: from proven.lan (localhost [127.0.0.1]) by proven.lan (8.14.3/8.14.3) with ESMTP id m8NEn9xq032115 for ; Tue, 23 Sep 2008 07:49:09 -0700 (PDT) (envelope-from fbsd-ml@scrapper.ca) Received: from localhost (localhost [[UNIX: localhost]]) by proven.lan (8.14.3/8.14.3/Submit) id m8NEn9rd032114 for freebsd-stable@freebsd.org; Tue, 23 Sep 2008 07:49:09 -0700 (PDT) (envelope-from fbsd-ml@scrapper.ca) X-Authentication-Warning: proven.lan: npapke set sender to fbsd-ml@scrapper.ca using -f From: Norbert Papke Organization: Archaeological Filing To: freebsd-stable@freebsd.org Date: Tue, 23 Sep 2008 07:49:08 -0700 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809230749.08982.fbsd-ml@scrapper.ca> Subject: Re: Possible UDP deadlock/panic fix 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, 23 Sep 2008 14:49:11 -0000 On September 22, 2008, Robert Watson wrote: > your confirmation as to whether or not this corrects the > specific symptoms you are seeing would be very helpful. 14+ hours under load with the patch and all is well. Thanks! -- Norbert. From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 16:01:40 2008 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 DE0C4106566C for ; Tue, 23 Sep 2008 16:01:40 +0000 (UTC) (envelope-from det135@psu.edu) Received: from f05n03.cac.psu.edu (f05s03.cac.psu.edu [128.118.141.46]) by mx1.freebsd.org (Postfix) with ESMTP id 990468FC15 for ; Tue, 23 Sep 2008 16:01:40 +0000 (UTC) (envelope-from det135@psu.edu) Received: from hoenikker.aset.psu.edu (hoenikker.aset.psu.edu [128.118.99.49]) by f05n03.cac.psu.edu (8.13.2/8.13.2) with ESMTP id m8NAaL6s114778; Tue, 23 Sep 2008 06:36:22 -0400 Received: from hoenikker.aset.psu.edu (hoenikker.aset.psu.edu [128.118.99.49]) by hoenikker.aset.psu.edu (8.14.2/8.14.2) with ESMTP id m8NAaL0I064554; Tue, 23 Sep 2008 06:36:21 -0400 (EDT) (envelope-from det135@hoenikker.aset.psu.edu) Received: (from det135@localhost) by hoenikker.aset.psu.edu (8.14.2/8.14.2/Submit) id m8NAaLTx064553; Tue, 23 Sep 2008 06:36:21 -0400 (EDT) (envelope-from det135) Date: Tue, 23 Sep 2008 06:36:21 -0400 From: Derek Taylor To: freebsd-stable@freebsd.org Message-ID: <20080923103621.GG6930@psu.edu> Mail-Followup-To: freebsd-stable@freebsd.org References: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> <7FC02881-91A6-4A2B-B58F-A4D1671B9978@netconsonance.com> <20080923163556.H76357@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080923163556.H76357@sola.nimnet.asn.au> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: by amavisd-new Subject: Re: Upcoming Releases Schedule... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Derek Taylor List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2008 16:01:40 -0000 On Tue, 23 Sep 2008, Ian Smith wrote: >On Mon, 22 Sep 2008, Jo Rhett wrote: > > I think you are using "last release" in a different way. "the last release" > > is always the most release release. Right now 6.3 will have support for > > longer than 6.4 will, which is the nature of the problem I raised. If you > > always supported the most recent release for 24 months then we wouldn't have > > any problem. > >Jo, it seems to be you who are trying to use "last" in an unusual way. >The "last release on a branch" is not the latest one, but the last one. >For 4.x that was .11 and for 5.x it was .5, where last means just that. Let's stop using the word "last" for the time being and instead circumvent the ambiguity via "previous" and "final", perhaps? Maybe if official documentation were updated to avoid this same ambiguity there'd be less misunderstanding too. -Derek. From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 17:48:01 2008 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 8BF37106566B for ; Tue, 23 Sep 2008 17:48:01 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id 690448FC15 for ; Tue, 23 Sep 2008 17:48:01 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 19534 invoked from network); 23 Sep 2008 17:21:21 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 Sep 2008 17:21:20 -0000 Message-ID: <48D92589.8000200@aldan.algebra.com> Date: Tue, 23 Sep 2008 13:21:13 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 7.0-stable: a hung process - scheduler 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: Tue, 23 Sep 2008 17:48:01 -0000 Hello! I was trying to build OpenOffice using all of my 4 CPUs. To be able to do other work on the machine comfortably, I ran the build under nice, and assigned real-time priority to the two Xorg processes. The build started at about 23:10 last night, and hung at 23:46. The procstat output for the make's process group is: PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM 8371 2425 8371 2425 2425 1 mi wait FreeBSD ELF64 make 12254 8371 8371 2425 2425 1 mi wait FreeBSD ELF64 sh 12255 12254 8371 2425 2425 1 mi pause FreeBSD ELF64 tcsh 12262 12255 8371 2425 2425 1 mi wait FreeBSD ELF64 perl5.8.8 33010 12262 8371 2425 2425 1 mi wait FreeBSD ELF64 perl5.8.8 33011 33010 8371 2425 2425 1 mi wait FreeBSD ELF64 sh 33012 33011 8371 2425 2425 1 mi wait FreeBSD ELF64 dmake 37126 33012 8371 2425 2425 1 mi - FreeBSD ELF64 dmake The last line worries me greatly... According to "procstat -t", there is only one thread there: PID TID COMM TDNAME CPU PRI STATE WCHAN 37126 100724 dmake - 1 193 sleep - And trying to "ktrace -p 37126" returns (even to root, even in /tmp): ktrace: ktrace.out: Operation not permitted There are no problems ktrace-ing 33012, but nothing comes from there, as that process simply waits for its child. I guess, the child -- 37126 was (v)forked to launch a compiler or some such and remains stuck in between (v)fork and exec somewhere... The OS is: FreeBSD 7.0-STABLE/amd64 from Sat Jul 26, 2008 and the box is otherwise perfectly functional. The scheduling-related options are set as such: options SCHED_4BSD # 4BSD scheduler options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions Let me know, what else I can do to help fix this bug -- I'm going to reboot the machine tonight... Should I switch to SCHED_ULE as a work-around? Thanks! Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 17:55:04 2008 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 E2522106564A for ; Tue, 23 Sep 2008 17:55:04 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id 3AEED8FC0A for ; Tue, 23 Sep 2008 17:55:03 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.2/8.14.2) with ESMTP id m8NHRI5v091034 for ; Wed, 24 Sep 2008 01:27:18 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.14.2/8.14.2/Submit) id m8NHRIXM091006 for stable@freebsd.org; Wed, 24 Sep 2008 01:27:18 +0800 (KRAST) (envelope-from eugen) Date: Wed, 24 Sep 2008 01:27:18 +0800 From: Eugene Grosbein To: stable@freebsd.org Message-ID: <20080923172718.GA86225@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RELENG_7: buildworld failed with MODULES_WITH_WORLD= 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, 23 Sep 2008 17:55:05 -0000 Hi! I've just tried to build NanoBSD from 7.0-STABLE sources with MODULES_WITH_WORLD knob enabled and it failed. Note that NanoBSD uses make -j3 by default and I have dualcore system. ===> sys/modules/nfslockd (depend) @ -> /usr/local/src/sys machine -> /usr/local/src/sys/i386/include echo "#define INET6 1" > opt_inet6.h awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I. -I@ -I@/contrib/altq /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_clnt.c /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_server.c /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_svc.c /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_xdr.c /usr/local/src/sys/modules/nfslockd/../../nlm/sm_inter_xdr.c In file included from /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c:48: @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory In file included from /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:56: @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory mkdep: compile failed *** Error code 1 Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 18:31:53 2008 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 4104C106564A; Tue, 23 Sep 2008 18:31:53 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 162BB8FC16; Tue, 23 Sep 2008 18:31:52 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [172.16.12.8] (covad-jrhett.meer.net [209.157.140.144]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8NIVngp056705; Tue, 23 Sep 2008 11:31:50 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=-0.960] Message-Id: From: Jo Rhett To: Ian Smith In-Reply-To: <20080923163556.H76357@sola.nimnet.asn.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 23 Sep 2008 11:31:49 -0700 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> <7FC02881-91A6-4A2B-B58F-A4D1671B9978@netconsonance.com> <20080923163556.H76357@sola.nimnet.asn.au> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-stable , Robert Watson , "Simon L. Nielsen" Subject: Re: Upcoming Releases Schedule... 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, 23 Sep 2008 18:31:53 -0000 On Sep 23, 2008, at 12:45 AM, Ian Smith wrote: >> I mean seriously, if you were to say "We will support 6.4 for 24 >> months >> *unless* we find it necessary to release 6.5 then I'd be totally >> happy. But >> that's not what is being said. > > I believe that's exactly what has been said. rwatson@ and simon@ have > both made it exceedingly clear, to me anyway, that if 6.4 is to be the > last release on the 6.x branch - as appears to be likely but cannot be > stated definitely at this time, for reasons clearly given and > understood > - then it will indeed be supported for 24 months. > > It doesn't seem reasonable to expect 24 months stated support for > 6.4 if > it turns out not to be the last release - that would then apply to > 6.5. Have you read any of the existing thread? Right now 6.4 will go out of support 3 months before 6.3. Which might or might not change at some point in the future. Isn't this obviously a fairly major problem for any business or even any person to want to spend any time to test/evaluate/etc 6.4? What I proposed in my message (which you completely ignored) was an incremental support policy that builds on each release, instead of actually promoting the idea of skipping releases. This may not be a good idea -- it was just a toss out there, but it makes a lot more sense than the existing policy. Could you at least respond to the issues raised here? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 18:36:24 2008 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 0DA6D106567D; Tue, 23 Sep 2008 18:36:24 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id D710C8FC12; Tue, 23 Sep 2008 18:36:23 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [172.16.12.8] (covad-jrhett.meer.net [209.157.140.144]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8NIaKKv056811; Tue, 23 Sep 2008 11:36:20 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=-0.959] Message-Id: <6DEC0D55-6D22-48AB-81D3-4740CFABD2FD@netconsonance.com> From: Jo Rhett To: Ian Smith In-Reply-To: <20080923163556.H76357@sola.nimnet.asn.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 23 Sep 2008 11:36:20 -0700 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> <7FC02881-91A6-4A2B-B58F-A4D1671B9978@netconsonance.com> <20080923163556.H76357@sola.nimnet.asn.au> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-stable , Robert Watson , "Simon L. Nielsen" Subject: Re: Upcoming Releases Schedule... 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, 23 Sep 2008 18:36:24 -0000 On Sep 23, 2008, at 12:45 AM, Ian Smith wrote: > It also doesn't seem reasonable to expect that decision to be rushed > in > advance of the necessary evaluation of the success or otherwise of > both > 6.4 and 7.1 releases - especially when we're talking about these being > only a month or so away anyway. Let me try to say this one other way. If you want businesses or anyone really who doesn't have unlimited time and energy to help evaluate, test, etc this release prior to it coming out, shouldn't you make it worth their while? Supporting 6.3 for longer than 6.4 doesn't make it worth anyone's time or attention to evaluate 6.4. Which means that it becomes significantly more likely that 6.4 will ship with a major problem that could or should have been caught in pre- release testing. The current policy of "not deciding until after the fact" for support periods could in fact be implemented with a reasonable policy that doesn't require a psychic to determine the likely failure or not of a release. I've proposed one. I'm sure that there are better ways to say it, but I'd really appreciate it if you guys would take the problem seriously. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 18:44:48 2008 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 A138F1065671 for ; Tue, 23 Sep 2008 18:44:48 +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 7A97D8FC13 for ; Tue, 23 Sep 2008 18:44:48 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 8497 invoked from network); 23 Sep 2008 18:44:48 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 Sep 2008 18:44:47 -0000 Message-ID: <48D93914.3020502@aldan.algebra.com> Date: Tue, 23 Sep 2008 14:44:36 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: "Paul B. Mahol" References: <48D92589.8000200@aldan.algebra.com> <3a142e750809231125o579445baufb5f2676e4d9a2ca@mail.gmail.com> In-Reply-To: <3a142e750809231125o579445baufb5f2676e4d9a2ca@mail.gmail.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org Subject: Re: 7.0-stable: a hung process - scheduler 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: Tue, 23 Sep 2008 18:44:48 -0000 Paul B. Mahol ÎÁÐÉÓÁ×(ÌÁ): >> Let me know, what else I can do to help fix this bug -- I'm going to >> reboot the machine tonight... Should I switch to SCHED_ULE as a >> work-around? >> > > SCHED_BSD4 is suboptimal for 4 CPUs, and it is replaced with SCHED_ULE > on 7 STABLE. > Thanks, Paul for the explanation. I've heard of some problems still lingering in the ULE and figured, I'll stay with the BSD-scheduler for a while. I guess, it is time to switch. However, what I'm seeing on my system today is evidence of the scheduler having a bug, rather than merely being suboptimal. If the old scheduler is still maintained and supposed to work (however sub-optimally) in 4-CPU configurations, I'd expect either inquiries for more debug-information or assurances, that the bug is known and worked on. In the July 26th sys/conf/NOTES file the SCHED_BSD4 is still on the default option.... Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 18:51:27 2008 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 DE3601065682 for ; Tue, 23 Sep 2008 18:51:27 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 200EF8FC1E for ; Tue, 23 Sep 2008 18:51:21 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m8NIE1at059558 for ; Wed, 24 Sep 2008 02:14:01 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m8NIE1lR059557 for stable@freebsd.org; Wed, 24 Sep 2008 02:14:01 +0800 (KRAST) (envelope-from eugen) Date: Wed, 24 Sep 2008 02:14:01 +0800 From: Eugene Grosbein To: stable@freebsd.org Message-ID: <20080923181401.GA59382@svzserv.kemerovo.su> References: <20080923172718.GA86225@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080923172718.GA86225@grosbein.pp.ru> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: RELENG_7: buildworld failed with MODULES_WITH_WORLD= 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, 23 Sep 2008 18:51:28 -0000 On Wed, Sep 24, 2008 at 01:27:18AM +0800, Eugene Grosbein wrote: > I've just tried to build NanoBSD from 7.0-STABLE sources > with MODULES_WITH_WORLD knob enabled and it failed. > Note that NanoBSD uses make -j3 by default and I have dualcore system. > > ===> sys/modules/nfslockd (depend) > @ -> /usr/local/src/sys > machine -> /usr/local/src/sys/i386/include > echo "#define INET6 1" > opt_inet6.h > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h > rm -f .depend > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I. -I@ > -I@/contrib/altq /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_clnt.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_server.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_svc.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_xdr.c > /usr/local/src/sys/modules/nfslockd/../../nlm/sm_inter_xdr.c > In file included from > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c:48: > @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory > In file included from > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:56: > @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory > mkdep: compile failed > *** Error code 1 This is easily repeatable without involving NanoBSD stuff, just with 'cd /usr/src; make -j3 MODULES_WITH_WORLD=yes buildworld'. I think this patch should be applied, at least it works for me: --- sys/modules/nfslockd/Makefile.orig 2008-08-09 16:07:45.000000000 +0800 +++ sys/modules/nfslockd/Makefile 2008-09-24 02:02:23.000000000 +0800 @@ -10,7 +10,7 @@ nlm_prot_svc.c \ nlm_prot_xdr.c \ sm_inter_xdr.c -SRCS+= opt_inet6.h +SRCS+= opt_inet6.h opt_nfs.h .if !defined(KERNBUILDDIR) NFS_INET6?= 1 # 0/1 - requires INET6 to be configured in kernel @@ -19,6 +19,9 @@ opt_inet6.h: echo "#define INET6 1" > ${.TARGET} .endif + +opt_nfs.h: + echo -n > ${.TARGET} .endif .include From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 18:55:23 2008 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 C6750106569E for ; Tue, 23 Sep 2008 18:55:23 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 97D3D8FC19 for ; Tue, 23 Sep 2008 18:55:18 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1969038rvf.43 for ; Tue, 23 Sep 2008 11:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=48YcwhBEQLefLVfg44kF+D62SYmz2GSm+rYsFz8+HRo=; b=bEQ7HpPwtlUuPy/c7tLj6WblzU02FCkbj2dLAEwzHMhDoAX3uE0VJzPr9q2q1cIcvX KtfULRi77jpuR6ez4DT2An0+em6wa6rpPIuemSi+Z5RlZqDJUCj5sCHFbioaB0akAYCY UpdGC7NOyQz9aODYgFK33uFlxkXkp9+atI4L8= 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=LP2Y0qbUJEiaKJKSdyq8CP45Rscua0JbpIkdV5X+oSwvgr422XL51aOxwqDmCmV0Ys qxIwLs8n949mxlf0ZNjTufeXERCfN1tp8mlRb9FhTD/BGwbMRDf1bPZ8Xeojl3BY9Itf UXYY9N6j/aE0GstPLiT0I5rzeZ5XJP0XUYWAw= Received: by 10.141.3.17 with SMTP id f17mr2904417rvi.180.1222194305356; Tue, 23 Sep 2008 11:25:05 -0700 (PDT) Received: by 10.141.189.15 with HTTP; Tue, 23 Sep 2008 11:25:05 -0700 (PDT) Message-ID: <3a142e750809231125o579445baufb5f2676e4d9a2ca@mail.gmail.com> Date: Tue, 23 Sep 2008 20:25:05 +0200 From: "Paul B. Mahol" To: "Mikhail Teterin" In-Reply-To: <48D92589.8000200@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48D92589.8000200@aldan.algebra.com> Cc: stable@freebsd.org Subject: Re: 7.0-stable: a hung process - scheduler 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: Tue, 23 Sep 2008 18:55:23 -0000 On 9/23/08, Mikhail Teterin wrote: > Hello! > > I was trying to build OpenOffice using all of my 4 CPUs. To be able to > do other work on the machine comfortably, I ran the build under nice, > and assigned real-time priority to the two Xorg processes. > The build started at about 23:10 last night, and hung at 23:46. The > procstat output for the make's process group is: > > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL > COMM > 8371 2425 8371 2425 2425 1 mi wait FreeBSD ELF64 make > 12254 8371 8371 2425 2425 1 mi wait FreeBSD ELF64 sh > 12255 12254 8371 2425 2425 1 mi pause FreeBSD ELF64 > tcsh > 12262 12255 8371 2425 2425 1 mi wait FreeBSD ELF64 > perl5.8.8 > 33010 12262 8371 2425 2425 1 mi wait FreeBSD ELF64 > perl5.8.8 > 33011 33010 8371 2425 2425 1 mi wait FreeBSD ELF64 sh > 33012 33011 8371 2425 2425 1 mi wait FreeBSD ELF64 dmake > 37126 33012 8371 2425 2425 1 mi - FreeBSD ELF64 dmake > > The last line worries me greatly... According to "procstat -t", there is > only one thread there: > > PID TID COMM TDNAME CPU PRI STATE > WCHAN > 37126 100724 dmake - 1 193 sleep - > > And trying to "ktrace -p 37126" returns (even to root, even in /tmp): > > ktrace: ktrace.out: Operation not permitted > > There are no problems ktrace-ing 33012, but nothing comes from there, as > that process simply waits for its child. I guess, the child -- 37126 was > (v)forked to launch a compiler or some such and remains stuck in between > (v)fork and exec somewhere... > > The OS is: FreeBSD 7.0-STABLE/amd64 from Sat Jul 26, 2008 and the box is > otherwise perfectly functional. The scheduling-related options are set > as such: > > options SCHED_4BSD # 4BSD scheduler > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B > real-time extensions > > Let me know, what else I can do to help fix this bug -- I'm going to > reboot the machine tonight... Should I switch to SCHED_ULE as a > work-around? SCHED_BSD4 is suboptimal for 4 CPUs, and it is replaced with SCHED_ULE on 7 STABLE. From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 19:06:32 2008 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 1CFD110656A1 for ; Tue, 23 Sep 2008 19:06:32 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by mx1.freebsd.org (Postfix) with ESMTP id 9B70C8FC21 for ; Tue, 23 Sep 2008 19:06:31 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so2250181fkk.11 for ; Tue, 23 Sep 2008 12:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=A6nBB0rlWI3npo1xLa8wnl5qJYbfOec5KU0Bgg/SGxI=; b=KK/oXou/x/jlKwhII0z62Rz9X7bzt0U+olyxwbgUs1Q7DMhyrznNyWVft+hVQUGX3F j8pAF16VCiSfIZ16+2OnYaBsK9Q7ib8AgJFolLqerjtDh3wZEbvJztmQYT00mrHyby4F G6f8HeQTOzYLmrq00zejgYcuu7yIwW39xJhiY= 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=jXog3e6cIOcQFI2i4+C4Ede9GxKr9kn4P3bSK7mnFlGuFKgVX9X1D5wENZt8kerjRc AhHmL97yKus4Sjf9HCAoQExvieWUeXOSI6GET+YyqKxjSidYsCC/8K0gjcEndbiPLOvx WL82W/AEmgil6YdJecvp/rHSmMK/EO0OUrgJQ= Received: by 10.180.230.6 with SMTP id c6mr4175825bkh.27.1222194998259; Tue, 23 Sep 2008 11:36:38 -0700 (PDT) Received: by 10.180.208.16 with HTTP; Tue, 23 Sep 2008 11:36:38 -0700 (PDT) Message-ID: <2a41acea0809231136o51201085g3ba38dfb625ef217@mail.gmail.com> Date: Tue, 23 Sep 2008 11:36:38 -0700 From: "Jack Vogel" To: "Jeremy Chadwick" In-Reply-To: <20080923100601.GA52531@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48D8BAF1.1020602@incunabulum.net> <20080923100601.GA52531@icarus.home.lan> Cc: Bruce M Simpson , FreeBSD stable Subject: Re: fxp multicast forwarding 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: Tue, 23 Sep 2008 19:06:32 -0000 LOL, sorry to disappoint you but I'm not responsible for fxp, Intel didn't write it, and i've never touched it :) Now that wouldnt mean that I can't look at it, but I am very busy right now, so unless there's no alternative I'd rather not. Jack On Tue, Sep 23, 2008 at 3:06 AM, Jeremy Chadwick wrote: > On Tue, Sep 23, 2008 at 10:46:25AM +0100, Bruce M Simpson wrote: >> Hi, >> >> Whilst doing some QA work on XORP on my desktop, which has fxp0 and >> msk0, fxp0 got totally hosed. >> I was running PIM-SM and IGMPv2 router-mode on the box at the time. >> >> I wonder if this is related to the problems with fxp multicast >> transmission I saw back in April. >> I'm a bit concerned about this as fxp is still a very widespread and >> useful network chip. >> >> I am running 7.0-RELEASE-p4/amd64. >> sysctls for dev.fxp.0 are set to their default values. >> >> I'm not expert on the fxp driver internals, but perhaps someone else has >> seen this kind of problem before. Multicast-promiscuous mode (aka >> ALLMULTI) was enabled on the interface. I know some NICs have problems >> with this, or don't even support it. >> >> The errors look like this: >> fxp0: SCB timeout: 0x10 0x0 0x80 0x0 >> fxp0: SCB timeout: 0x10 0x0 0x80 0x0 >> fxp0: DMA timeout >> ... repeated ... >> >> Attempted workarounds which don't work to un-wedge the chip: >> Reload the fxp0 microcode with "ifconfig fxp0 link0" >> Forcibly unloading the kernel module and reloading it >> Unpatching and repatching at the switch (a cheap 10/100 one) >> Enabling and disabling promiscuous mode >> Twiddling dev.fxp.0.noflow >> >> The link status looks fine, but the card will not send or receive traffic. >> A warm reboot was enough to get things back up again. >> >> regards, >> BMS > > Adding Jack Vogel, who's responsible for fxp(4). > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 19:09:14 2008 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 452B31065683 for ; Tue, 23 Sep 2008 19:09:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id DB5D48FC34 for ; Tue, 23 Sep 2008 19:09:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KiDG3-000M8t-IZ; Tue, 23 Sep 2008 22:09:11 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8NJ98JH098982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 22:09:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8NJ98kJ035211; Tue, 23 Sep 2008 22:09:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m8NJ98Sa035210; Tue, 23 Sep 2008 22:09:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 23 Sep 2008 22:09:08 +0300 From: Kostik Belousov To: Eugene Grosbein Message-ID: <20080923190908.GY47828@deviant.kiev.zoral.com.ua> References: <20080923172718.GA86225@grosbein.pp.ru> <20080923181401.GA59382@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kUoBhQsr7LsiFken" Content-Disposition: inline In-Reply-To: <20080923181401.GA59382@svzserv.kemerovo.su> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KiDG3-000M8t-IZ 884de3cfd22beab70a2c9b760112a671 X-Terabit: YES Cc: stable@freebsd.org, ps@freebsd.org Subject: Re: RELENG_7: buildworld failed with MODULES_WITH_WORLD= 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, 23 Sep 2008 19:09:14 -0000 --kUoBhQsr7LsiFken Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 24, 2008 at 02:14:01AM +0800, Eugene Grosbein wrote: > On Wed, Sep 24, 2008 at 01:27:18AM +0800, Eugene Grosbein wrote: >=20 > > I've just tried to build NanoBSD from 7.0-STABLE sources > > with MODULES_WITH_WORLD knob enabled and it failed. > > Note that NanoBSD uses make -j3 by default and I have dualcore system. > >=20 > > =3D=3D=3D> sys/modules/nfslockd (depend) > > @ -> /usr/local/src/sys > > machine -> /usr/local/src/sys/i386/include > > echo "#define INET6 1" > opt_inet6.h > > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p > > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q > > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h > > rm -f .depend > > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I. -I@ > > -I@/contrib/altq /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advl= ock.c > > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_clnt.c > > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c > > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_server.c > > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_svc.c > > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_xdr.c > > /usr/local/src/sys/modules/nfslockd/../../nlm/sm_inter_xdr.c > > In file included from > > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c:48: > > @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory > > In file included from > > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:56: > > @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory > > mkdep: compile failed > > *** Error code 1 >=20 > This is easily repeatable without involving NanoBSD stuff, > just with 'cd /usr/src; make -j3 MODULES_WITH_WORLD=3Dyes buildworld'. >=20 > I think this patch should be applied, at least it works for me: >=20 > --- sys/modules/nfslockd/Makefile.orig 2008-08-09 16:07:45.000000000 +0800 > +++ sys/modules/nfslockd/Makefile 2008-09-24 02:02:23.000000000 +0800 > @@ -10,7 +10,7 @@ > nlm_prot_svc.c \ > nlm_prot_xdr.c \ > sm_inter_xdr.c > -SRCS+=3D opt_inet6.h > +SRCS+=3D opt_inet6.h opt_nfs.h > =20 > .if !defined(KERNBUILDDIR) > NFS_INET6?=3D 1 # 0/1 - requires INET6 to be configured in kernel > @@ -19,6 +19,9 @@ > opt_inet6.h: > echo "#define INET6 1" > ${.TARGET} > .endif > + > +opt_nfs.h: > + echo -n > ${.TARGET} > .endif > =20 > .include First chunk of your patch was already committed by Paul Saab as r181040. You may ask him to do MFC and merge second chunk, if needed. --kUoBhQsr7LsiFken Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjZPtIACgkQC3+MBN1Mb4jWzgCglgNY39Fu7AA/INe6NS5t6zfV EIEAoK0J0SQYcF55C46B0rH3HLmioewP =JNeg -----END PGP SIGNATURE----- --kUoBhQsr7LsiFken-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 19:56:46 2008 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 C1CC2106566B for ; Tue, 23 Sep 2008 19:56:46 +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 9B4678FC13 for ; Tue, 23 Sep 2008 19:56:46 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 32100 invoked from network); 23 Sep 2008 19:56:45 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 Sep 2008 19:56:45 -0000 Message-ID: <48D949F0.10109@aldan.algebra.com> Date: Tue, 23 Sep 2008 15:56:32 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: josh.carroll@gmail.com References: <48D92589.8000200@aldan.algebra.com> <3a142e750809231125o579445baufb5f2676e4d9a2ca@mail.gmail.com> <48D93914.3020502@aldan.algebra.com> <8cb6106e0809231243q3f874ccap50520dde1e0e63b2@mail.gmail.com> In-Reply-To: <8cb6106e0809231243q3f874ccap50520dde1e0e63b2@mail.gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org, "Paul B. Mahol" Subject: Re: 7.0-stable: a hung process - scheduler 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: Tue, 23 Sep 2008 19:56:46 -0000 Josh Carroll ÎÁÐÉÓÁ×(ÌÁ): >> However, what I'm seeing on my system today is evidence of the scheduler >> having a bug, rather than merely being suboptimal. If the old scheduler is >> still maintained and supposed to work (however sub-optimally) in 4-CPU >> configurations, I'd expect either inquiries for more debug-information or >> assurances, that the bug is known and worked on. >> > > I'm no expert, but I don't think you can necessarily conclude that it > is the scheduler yet. It very well may be, but I agree that someone > with more expertise hopefully will ask for more detailed debug/trace > information to pin down where the problem lies. > Although the machine seemed fine, it would not launch new processes ever since I tried to start `systat 1 -vm' -- something systat does at start-up must've wedged the system... A process, that was running (cvs over ssh) is currently stuck (according to Ctrl-T) in: load: 0.00 cmd: ssh 59098 [proctree] 0.41u 0.17s 0% 0k I'll reboot it, when I get back home... -mi From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 20:08:15 2008 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 0B3FA1065670 for ; Tue, 23 Sep 2008 20:08:15 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id B6ADD8FC1F for ; Tue, 23 Sep 2008 20:08:14 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk10 with SMTP id 10so4776803gxk.19 for ; Tue, 23 Sep 2008 13:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lY50ol9UraMZbN6IXBnJ8Ge0m3LlVF352lUeEFVy6q8=; b=t3Aa2m9bNv2vJStVjWDzgbvDdF8AEh2YP3etIoILspTSNnrEOWdSUHUG7oWyNIWtBB 3lxE6fTu/yf3wau7KpfcATGSJD8tN/1fysP/iU+er0b8fym09lZQKA5RkoQElZUorhDQ s+m1JGJg5h6awLZ3LuGXzM4+RlKlLN/XMc9x8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=f99MFpdJ/4JOfooRSrCA1GJ0uxsuFYDBnBLAGPkbSfn2BoFkideq9qRZoN8vDTnJPe 9T/ODkGddlSqJuL6oDFPaodxpExTmKN4bLMrkfwoKOwSJ9iAeGD20Hp7AIqCLca6hRkT 5zi9rUac5PScKL4xzq6ZCj/6MvhAbqi2tGFrE= Received: by 10.150.156.9 with SMTP id d9mr9743925ybe.90.1222199033256; Tue, 23 Sep 2008 12:43:53 -0700 (PDT) Received: by 10.151.11.21 with HTTP; Tue, 23 Sep 2008 12:43:53 -0700 (PDT) Message-ID: <8cb6106e0809231243q3f874ccap50520dde1e0e63b2@mail.gmail.com> Date: Tue, 23 Sep 2008 15:43:53 -0400 From: "Josh Carroll" To: "Mikhail Teterin" In-Reply-To: <48D93914.3020502@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48D92589.8000200@aldan.algebra.com> <3a142e750809231125o579445baufb5f2676e4d9a2ca@mail.gmail.com> <48D93914.3020502@aldan.algebra.com> Cc: stable@freebsd.org, "Paul B. Mahol" Subject: Re: 7.0-stable: a hung process - scheduler bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2008 20:08:15 -0000 > However, what I'm seeing on my system today is evidence of the scheduler > having a bug, rather than merely being suboptimal. If the old scheduler is > still maintained and supposed to work (however sub-optimally) in 4-CPU > configurations, I'd expect either inquiries for more debug-information or > assurances, that the bug is known and worked on. I'm no expert, but I don't think you can necessarily conclude that it is the scheduler yet. It very well may be, but I agree that someone with more expertise hopefully will ask for more detailed debug/trace information to pin down where the problem lies. > In the July 26th sys/conf/NOTES file the SCHED_BSD4 is still on the default > option.... GENERIC for i386 and amd64 has ULE as the default in RELENG_7. Regards, Josh From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 20:19:33 2008 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 15B83106572D; Tue, 23 Sep 2008 20:19:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 893348FC1B; Tue, 23 Sep 2008 20:19:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8NKJOvk075249; Tue, 23 Sep 2008 16:19:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 23 Sep 2008 16:10:17 -0400 User-Agent: KMail/1.9.7 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809231610.17625.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 23 Sep 2008 16:19:25 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8317/Tue Sep 23 15:48:36 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Jo Rhett , Robert Watson , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 23 Sep 2008 20:19:33 -0000 Jo, so it seems to me that you could just start by maintaining your own set of extended support patches for the FreeBSD releases you care about. I don't think you have to be a committer or secteam@ member to do this. It does mean that you might not be able to fix a bug in, say, 6.2 at the same exact time the advisory goes out at first, but you could take the patch from the advisory and apply it to your local 6.2 tree and then update your "cumulative patch" (would probably want to use some sort of source code control for this where you basically branch from FreeBSD X.Y where X.Y is a vendor branch of sorts). That would let you build the "street cred", as it were, to be able to get the patches directly into FreeBSD more easily. To start with it is probably going to be a bit slow as far as getting things committed directly to FreeBSD proper as it means finding a committer who has the time to test and review your patch and then commit it. However, the "Unofficial FreeBSD 6.2 Patchset" can be updated more quickly since it is something that would be under your control. Also, doing this will give you insight into exactly what is required to support a release after it is EOL'd in a much more direct fashion than an e-mail thread. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 20:19:37 2008 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 BF53010656AD; Tue, 23 Sep 2008 20:19:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6E18FC2B; Tue, 23 Sep 2008 20:19:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8NKJOvl075249; Tue, 23 Sep 2008 16:19:31 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 23 Sep 2008 16:12:00 -0400 User-Agent: KMail/1.9.7 References: <20080918180543.pt7s2zmaio48ww8g@webmail.opentransfer.com> <20080920125803.d81jiet544cgc8g4@webmail.opentransfer.com> In-Reply-To: <20080920125803.d81jiet544cgc8g4@webmail.opentransfer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809231612.00996.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 23 Sep 2008 16:19:31 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8317/Tue Sep 23 15:48:36 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Robert Watson Subject: Re: RELENG_7: something is very wrong with UDP? 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, 23 Sep 2008 20:19:37 -0000 On Saturday 20 September 2008 05:58:03 am Oleg V. Nauman wrote: > Quoting Robert Watson : > >>> This is approximately the date of my last UDP MFC. Could you try > >>> backing out just src/sys/netinet6/udp6_usrreq.c revision 1.81.2.7 > >>> and see if that helps? (specifically, restore the use of > >>> sosend_generic instead of sosend_dgram) > > > > If you can show that it's definitely a problem with the change to > > sosend_dgram for UDPv6 socket send, then it might suggest it's the same > > problem that it is related to the UDPv46 code there. In which case I > > will propose we back out that portion of the change in the 7-stable > > branch until it's known to be resolved -- I don't want other people > > tripping over this. > > Sorry for false alarm regarding UDP issues.. Have noticed that my > clock is stop incrementing ( it explaining the zeroes in traceroute > output also ). It gave me idea what is related to this issue so > performed backout revision 1.243.2.4 of src/sys/dev/acpica/acpi.c and > it fixes my issues.. Looks like it stops incrementing the timecounters > on my laptop.. > Ironically speaking I was this ACPI behavior change initiator ( I was > reporting "ACPI HPET stops working on my RELENG_7" at July 19 to > stable@freebsd.org) so jhb@ implemented a patch and it was working for > me those days. Something was changed during the next 2 months so this > patch causing issues instead the success on my hardware. I will play a > bit with kern.timecounter.choice at Monday and report it back to jhb@ > then. The HPET is only used for "time of day". It does not drive the internal timers used by the kernel. If you find that the latest acpi.c makes a difference, you will need to start with before and after verbose dmesgs. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 20:19:49 2008 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 A80E610656C9; Tue, 23 Sep 2008 20:19:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 468B58FC12; Tue, 23 Sep 2008 20:19:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8NKJOvm075249; Tue, 23 Sep 2008 16:19:37 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 23 Sep 2008 16:16:13 -0400 User-Agent: KMail/1.9.7 References: <48D92589.8000200@aldan.algebra.com> <3a142e750809231125o579445baufb5f2676e4d9a2ca@mail.gmail.com> In-Reply-To: <3a142e750809231125o579445baufb5f2676e4d9a2ca@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809231616.14039.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 23 Sep 2008 16:19:37 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8317/Tue Sep 23 15:48:36 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Mikhail Teterin , stable@freebsd.org, "Paul B. Mahol" Subject: Re: 7.0-stable: a hung process - scheduler 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: Tue, 23 Sep 2008 20:19:49 -0000 On Tuesday 23 September 2008 02:25:05 pm Paul B. Mahol wrote: > > The OS is: FreeBSD 7.0-STABLE/amd64 from Sat Jul 26, 2008 and the box is > > otherwise perfectly functional. The scheduling-related options are set > > as such: > > > > options SCHED_4BSD # 4BSD scheduler > > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B > > real-time extensions > > > > Let me know, what else I can do to help fix this bug -- I'm going to > > reboot the machine tonight... Should I switch to SCHED_ULE as a > > work-around? > > SCHED_BSD4 is suboptimal for 4 CPUs, and it is replaced with SCHED_ULE > on 7 STABLE. SCHED_4BSD should still work fine. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 20:19:49 2008 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 A80E610656C9; Tue, 23 Sep 2008 20:19:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 468B58FC12; Tue, 23 Sep 2008 20:19:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8NKJOvm075249; Tue, 23 Sep 2008 16:19:37 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 23 Sep 2008 16:16:13 -0400 User-Agent: KMail/1.9.7 References: <48D92589.8000200@aldan.algebra.com> <3a142e750809231125o579445baufb5f2676e4d9a2ca@mail.gmail.com> In-Reply-To: <3a142e750809231125o579445baufb5f2676e4d9a2ca@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809231616.14039.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 23 Sep 2008 16:19:37 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8317/Tue Sep 23 15:48:36 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Mikhail Teterin , stable@freebsd.org, "Paul B. Mahol" Subject: Re: 7.0-stable: a hung process - scheduler 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: Tue, 23 Sep 2008 20:19:49 -0000 On Tuesday 23 September 2008 02:25:05 pm Paul B. Mahol wrote: > > The OS is: FreeBSD 7.0-STABLE/amd64 from Sat Jul 26, 2008 and the box is > > otherwise perfectly functional. The scheduling-related options are set > > as such: > > > > options SCHED_4BSD # 4BSD scheduler > > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B > > real-time extensions > > > > Let me know, what else I can do to help fix this bug -- I'm going to > > reboot the machine tonight... Should I switch to SCHED_ULE as a > > work-around? > > SCHED_BSD4 is suboptimal for 4 CPUs, and it is replaced with SCHED_ULE > on 7 STABLE. SCHED_4BSD should still work fine. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 20:37:07 2008 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 97DA61065685; Tue, 23 Sep 2008 20:37:07 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7C6D48FC12; Tue, 23 Sep 2008 20:37:07 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [172.16.12.8] (covad-jrhett.meer.net [209.157.140.144]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8NKb3Gw065931; Tue, 23 Sep 2008 13:37:04 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=-0.957] Message-Id: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> From: Jo Rhett To: cperciva@FreeBSD.org, Robert Watson , "Simon L. Nielsen" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 23 Sep 2008 13:37:03 -0700 X-Mailer: Apple Mail (2.928.1) Cc: freebsd-stable Stable Subject: proposed change to support policy for FreeBSD Releases 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, 23 Sep 2008 20:37:07 -0000 Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems "better". Old text: > Each branch is supported by the Security Officer for a limited time > only, and is designated as one of `Early adopter', `Normal', or > `Extended'. The designation is used as a guideline for determining > the lifetime of the branch as follows. > > Early adopter > Releases which are published from the -CURRENT branch will be > supported by the Security Officer for a minimum of 6 months after > the release. > Normal > Releases which are published from a -STABLE branch will be > supported by the Security Officer for a minimum of 12 months after > the release. > Extended > Selected releases will be supported by the Security Officer for > a minimum of 24 months after the release. Proposed (starting point for discussion for) new text: Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or 'Final'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. A release which is not the final minor release of a branch will be additionally supported by a minimum of 6 months past the release date of the succeeding version. For example X.1 will be supported for 12 months or until 6 months past the release date of X.2, whichever comes later. Final The final minor release on a given branch will be supported by the Security Officer for a minimum of 24 months after the release. OBSERVATIONS: 1. This avoids the need for the well-documented chicken-and-egg problem of trying to guess which release is the final release. 2. This is a consistent policy in line with many other vendor policies. 3. This rewards forward movement in the branch. And finally, as I've done the match carefully, 4. It would appear to *reduce* rather than enlarge the support requirements for the security team. Unless a minor release comes out less than 6 months after a previous release, only two versions would ever be supported at the same time. In recent history 3 minor releases in the same branch have been supported more often than not. Example under current policy: 6.5 comes out in July of 2009. For July -> October the security team will need to support 3 releases: 6.3, 6.4 and 6.5. From November 2009 through January 2010 the security team will need to support 6.3 and 6.5, but not 6.4. Revised under the existing policy: Support for 6.3 expires in April of 2009. (more than 12 months past release and 6 months after the release of 6.4). Support for 6.4 expires in January of 2010. Support for 6.5 would expire in July of 2011 or 6 months after the release of 6.6. ^NOTE: this example is probably unfeasible since 6.3 already has a published support period ended in January 2010, but this will prevent a similar occurrence happening in future releases. Note2: This new policy would not change the support period for 6.4 if it is the final release, but it does completely resolve the need to "guess" whether or not it will be the final release. The notable change that I believe will encourage business participation in the testing/evaluation process is that 6.4 is guaranteed to be supported either 24 months, or at least 6 months past the release date of 6.5. (recent history suggests this would be 15-19 months). This encourages businesses to test and evaluate 6.4 NOW, rather than waiting until a decision about the support policy is made. Repeat from the top: nobody is demanding anything. I think this policy would make a lot more sense, and would promote forward movement. Feel free to correct me if we overlooked anything. Thanks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 20:38:20 2008 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 6DF93106567A for ; Tue, 23 Sep 2008 20:38:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 472588FC22 for ; Tue, 23 Sep 2008 20:38:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id BF20B46B2C; Tue, 23 Sep 2008 16:38:19 -0400 (EDT) Date: Tue, 23 Sep 2008 21:38:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mikhail Teterin In-Reply-To: <48D92589.8000200@aldan.algebra.com> Message-ID: References: <48D92589.8000200@aldan.algebra.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@FreeBSD.org Subject: Re: 7.0-stable: a hung process - scheduler 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: Tue, 23 Sep 2008 20:38:20 -0000 On Tue, 23 Sep 2008, Mikhail Teterin wrote: > 37126 33012 8371 2425 2425 1 mi - FreeBSD ELF64 dmake > > PID TID COMM TDNAME CPU PRI STATE WCHAN > 37126 100724 dmake - 1 193 sleep - > > There are no problems ktrace-ing 33012, but nothing comes from there, as > that process simply waits for its child. I guess, the child -- 37126 was > (v)forked to launch a compiler or some such and remains stuck in between > (v)fork and exec somewhere... (lots of details elided) Yes, there's a period during exec where attaching debuggers isn't allowed, so if something gets wedged or otherwise lost there, ktrace isn't much use. On the other hand, if it's stuck there, then there are no syscalls going on anyway. Could you try procstat -kk on the process, does that shed any light? Another alternative, if you have DDB compiled in, is to break to the debugger and do a stack trace, or to use gdb on /dev/mem if you have a kernel.symbols. This may help us understand more about what is going on. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 20:42:20 2008 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 751DC106567F; Tue, 23 Sep 2008 20:42:20 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 57F178FC08; Tue, 23 Sep 2008 20:42:20 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [172.16.12.8] (covad-jrhett.meer.net [209.157.140.144]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8NKgDw9066122; Tue, 23 Sep 2008 13:42:13 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=-0.956] Message-Id: <5307532F-194E-482D-8617-2FB6E13E3F83@netconsonance.com> From: Jo Rhett To: John Baldwin In-Reply-To: <200809231610.17625.jhb@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 23 Sep 2008 13:42:13 -0700 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <200809231610.17625.jhb@freebsd.org> X-Mailer: Apple Mail (2.928.1) Cc: Robert Watson , freebsd-stable@freebsd.org, Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 23 Sep 2008 20:42:20 -0000 John, we're already committed to upgrade to 6.3 (since it will currently be supported longer than 6.4). 6.2 support isn't part of this conversation, it has entirely revolved around support periods for upcoming releases. On Sep 23, 2008, at 1:10 PM, John Baldwin wrote: > Jo, so it seems to me that you could just start by maintaining your > own set of > extended support patches for the FreeBSD releases you care about. I > don't > think you have to be a committer or secteam@ member to do this. It > does mean > that you might not be able to fix a bug in, say, 6.2 at the same > exact time > the advisory goes out at first, but you could take the patch from the > advisory and apply it to your local 6.2 tree and then update your > "cumulative > patch" (would probably want to use some sort of source code control > for this > where you basically branch from FreeBSD X.Y where X.Y is a vendor > branch of > sorts). That would let you build the "street cred", as it were, to > be able > to get the patches directly into FreeBSD more easily. > > To start with it is probably going to be a bit slow as far as > getting things > committed directly to FreeBSD proper as it means finding a committer > who has > the time to test and review your patch and then commit it. However, > the "Unofficial FreeBSD 6.2 Patchset" can be updated more quickly > since it is > something that would be under your control. Also, doing this will > give you > insight into exactly what is required to support a release after it > is EOL'd > in a much more direct fashion than an e-mail thread. > > -- > John Baldwin -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 20:47:55 2008 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 168D41065677 for ; Tue, 23 Sep 2008 20:47:55 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mx1.freebsd.org (Postfix) with ESMTP id E6DAB8FC21 for ; Tue, 23 Sep 2008 20:47:54 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 25268 invoked from network); 23 Sep 2008 20:47:54 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 Sep 2008 20:47:54 -0000 Message-ID: <48D955EE.3090108@aldan.algebra.com> Date: Tue, 23 Sep 2008 16:47:42 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Robert Watson References: <48D92589.8000200@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@FreeBSD.org Subject: Re: 7.0-stable: a hung process - scheduler 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: Tue, 23 Sep 2008 20:47:55 -0000 Robert Watson ÎÁÐÉÓÁ×(ÌÁ): > Could you try procstat -kk on the process, does that shed any light? When I was trying `procstat -k', I was getting the message: PID TID COMM TDNAME KSTACK procstat: sysctl: kern.proc.kstack unavailable procstat: options DDB or options STACK required in kernel That was with a single `-k'. I can't do anything now, because -- after an attempt to start `systat 1 -vm' -- the system hosed and would not start new processes. The existing ones, such as the cvs-over ssh are stuck in: load: 0.00 cmd: ssh 59098 [proctree] 0.41u 0.17s 0% 0k Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 21:18:19 2008 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 D49CD1065674 for ; Tue, 23 Sep 2008 21:18:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AAEF58FC17 for ; Tue, 23 Sep 2008 21:18:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 4439146B46; Tue, 23 Sep 2008 17:18:19 -0400 (EDT) Date: Tue, 23 Sep 2008 22:18:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mikhail Teterin In-Reply-To: <48D955EE.3090108@aldan.algebra.com> Message-ID: References: <48D92589.8000200@aldan.algebra.com> <48D955EE.3090108@aldan.algebra.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1052563692-1222204699=:68287" Cc: stable@FreeBSD.org Subject: Re: 7.0-stable: a hung process - scheduler 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: Tue, 23 Sep 2008 21:18:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1052563692-1222204699=:68287 Content-Type: TEXT/PLAIN; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 23 Sep 2008, Mikhail Teterin wrote: > Robert Watson ÎÁÐÉÓÁ×(ÌÁ): >> Could you try procstat -kk on the process, does that shed any light? > When I was trying `procstat -k', I was getting the message: > > PID TID COMM TDNAME KSTACK > procstat: sysctl: kern.proc.kstack unavailable > procstat: options DDB or options STACK required in kernel > > That was with a single `-k'. I can't do anything now, because -- after an > attempt to start `systat 1 -vm' -- the system hosed and would not start new > processes. The existing ones, such as the cvs-over ssh are stuck in: > > load: 0.00 cmd: ssh 59098 [proctree] 0.41u 0.17s 0% 0k Sounds a lot like a lock leak/deadlock. Other than DDB output or a crashdump, which would allow us to explore some more, there's probably not much to be done with the box at this point other than reset. Sorry about that. Robert N M Watson Computer Laboratory University of Cambridge --621616949-1052563692-1222204699=:68287-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 21:37:22 2008 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 3E73C1065677 for ; Tue, 23 Sep 2008 21:37:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 15FF08FC0A for ; Tue, 23 Sep 2008 21:37:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id A274846B0D; Tue, 23 Sep 2008 17:37:21 -0400 (EDT) Date: Tue, 23 Sep 2008 22:37:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mario Sergio Fujikawa Ferreira In-Reply-To: <48D8BF69.6060206@uol.com.br> Message-ID: References: (sfid-20080922_05543_31152F2E) <48D8BF69.6060206@uol.com.br> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Norbert Papke , stable@FreeBSD.org Subject: Re: Possible UDP deadlock/panic fix 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, 23 Sep 2008 21:37:22 -0000 On Tue, 23 Sep 2008, Mario Sergio Fujikawa Ferreira wrote: > That seems to be working. I've been up and running for 7 hours now with > your patch. > > The machine is a bit slow but I have both WITNESS and INVARIANTS enabled > so as to make sure everything is fine. I've now merged the fix to stable/7, thanks to both of you for reporting the problem. Robert N M Watson Computer Laboratory University of Cambridge > > Rergads, > Mario > > Robert Watson wrote: >> >> Attached is an MFC candidate for a patch I just merged to 8.x, which >> corrects the UDP lock recursion issue both of you were running into. If it >> settles well for a couple of days in HEAD then I'll go ahead and request an >> MFC from re@, but your confirmation as to whether or not this corrects the >> specific symptoms you are seeing would be very helpful. I was able to >> confirm that it eliminated what appeared to be the same problem here when I >> attempted to reproduce it based on the information you provided, so I'm >> hopeful.\ >> >> Thanks, >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >> >> Property changes on: . >> ___________________________________________________________________ >> Modified: svn:mergeinfo >> Merged /head/sys:r183265 >> >> Index: netinet6/udp6_usrreq.c >> =================================================================== >> --- netinet6/udp6_usrreq.c (revision 183265) >> +++ netinet6/udp6_usrreq.c (working copy) >> @@ -975,13 +975,23 @@ >> error = EINVAL; >> goto out; >> } >> + >> + /* >> + * XXXRW: We release UDP-layer locks before calling >> + * udp_send() in order to avoid recursion. However, >> + * this does mean there is a short window where inp's >> + * fields are unstable. Could this lead to a >> + * potential race in which the factors causing us to >> + * select the UDPv4 output routine are invalidated? >> + */ >> + INP_WUNLOCK(inp); >> + INP_INFO_WUNLOCK(&udbinfo); >> if (sin6) >> in6_sin6_2_sin_in_sock(addr); >> pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs; >> - error = ((*pru->pru_send)(so, flags, m, addr, control, >> + /* addr will just be freed in sendit(). */ >> + return ((*pru->pru_send)(so, flags, m, addr, control, >> td)); >> - /* addr will just be freed in sendit(). */ >> - goto out; >> } >> } >> #endif >> _______________________________________________ >> 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" >> > > _______________________________________________ > 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 Tue Sep 23 21:51:39 2008 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 A51DE1065674 for ; Tue, 23 Sep 2008 21:51:39 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id 8056D8FC17 for ; Tue, 23 Sep 2008 21:51:39 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 22682 invoked from network); 23 Sep 2008 21:51:39 -0000 Received: from aldan.algebra.com (HELO [127.0.0.1]) (mi@[216.254.65.224]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 Sep 2008 21:51:38 -0000 Message-ID: <48D964DF.4080207@aldan.algebra.com> Date: Tue, 23 Sep 2008 17:51:27 -0400 From: Mikhail Teterin User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Robert Watson References: <48D92589.8000200@aldan.algebra.com> <48D955EE.3090108@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@FreeBSD.org Subject: Re: 7.0-stable: a hung process - scheduler 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: Tue, 23 Sep 2008 21:51:39 -0000 Robert Watson ÎÁÐÉÓÁ×(ÌÁ): > Sounds a lot like a lock leak/deadlock. Other than DDB output or a > crashdump, which would allow us to explore some more, there's probably > not much to be done with the box at this point other than reset. > Sorry about that. Well, to reproduce you can try to build OpenOffice.org from any of the editors/openoffice.org-3-* ports. Set the environment variables MAXPROCESSES and MAXPROCS to the number of CPUs in your SMP-computer. Even if it does not hang like it did here, you may be able to observe the leak... Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 23:33:05 2008 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 C065C106564A; Tue, 23 Sep 2008 23:33:05 +0000 (UTC) (envelope-from jon@seaholm.caamora.com.au) Received: from seaholm.caamora.com.au (seaholm.caamora.com.au [203.7.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id 50F588FC1D; Tue, 23 Sep 2008 23:33:02 +0000 (UTC) (envelope-from jon@seaholm.caamora.com.au) Received: (from jon@localhost) by seaholm.caamora.com.au (8.11.1/8.11.1) id m8NNWqd28124; Wed, 24 Sep 2008 09:32:52 +1000 (EST) Message-ID: <20080924093252.02048@caamora.com.au> Date: Wed, 24 Sep 2008 09:32:52 +1000 From: jonathan michaels To: Jo Rhett References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com>; from Jo Rhett on Tue, Sep 23, 2008 at 01:37:03PM -0700 Organisation: Caamora, PO Box 144, Rosebery NSW 1445 Australia Cc: freebsd-stable Stable , Robert Watson , "Simon L. Nielsen" , cperciva@freebsd.org Subject: Re: proposed change to support policy for FreeBSD Releases 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, 23 Sep 2008 23:33:05 -0000 freebsd-stable et al ... On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote: > Some quite lively offline discussion has come to conclusion with the > following suggestions to change the support policy. Obviously, this > is what we feel would be a good idea, but it's obviously open to > discussion and there's nobody demanding anything here. It just seems > "better". > > Old text: > > Each branch is supported by the Security Officer for a limited time o/ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ O\ whole heap of content sniped for brevity. > > a minimum of 24 months after the release. > > Proposed (starting point for discussion for) new text: > > Each branch is supported by the Security Officer for a limited time > only, and is designated as one of `Early adopter', `Normal', or > 'Final'. The designation is used as a guideline for determining the > lifetime of the branch as follows. > > Early adopter > Releases which are published from the -CURRENT branch will be for support of my hardware and any 'new' machines that might wander by .. i like these two definitions, the clarity of teh time line i mean, Early Adopter / Normal > Normal > Releases which are published from a -STABLE branch will be but, in particular i like this (Final) as a place to find some certainty and a place to plan the next step as regards freebsd upgrade path and future hardware acquisitions .. a safe place to plan and look froward from ... > Final > The final minor release on a given branch will be supported by > the Security Officer for a minimum of 24 months after the release. o/ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ O\ whole heap of contents sniped for brevity. thank you gentle peoples for working out this solution. it has given me some much needed clarity as regards forward moving planning. as well as looking to very clearly simplify the desicion making process as regards, not just, 'which freebsd to use' but when to move and what release to move to. as well as helping with the going forward hardware acquisions processes. not all gifts make good freebsd platforms. it helps to know with some kind of certainty wht hardware is being supported/worked on and still in pre-development stage so to speak. at any rate a good place to start with as regards this whole 'support' business .. makes sence to me .. thanks, gang. keep up teh good work .. very much appreciated most kind regards / appreciations. jonathan -- ================================================================ powered by .. QNX, OS9 and freeBSD -- http://caamora com au/operating system ==== === appropriate solution in an inappropriate world === ==== From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 23:56:00 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A1E411065676 for ; Tue, 23 Sep 2008 23:56:00 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 350EF152D28 for ; Tue, 23 Sep 2008 23:55:59 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: (qmail 16666 invoked from network); 23 Sep 2008 23:45:32 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 23 Sep 2008 23:45:32 -0000 Message-ID: <48D97F9C.3050309@freebsd.org> Date: Tue, 23 Sep 2008 16:45:32 -0700 From: Colin Percival User-Agent: Thunderbird 2.0.0.16 (X11/20080730) MIME-Version: 1.0 To: jonathan michaels References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> <20080924093252.02048@caamora.com.au> In-Reply-To: <20080924093252.02048@caamora.com.au> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jo Rhett , freebsd-stable Stable , Robert Watson , "Simon L. Nielsen" Subject: Re: proposed change to support policy for FreeBSD Releases 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, 23 Sep 2008 23:56:00 -0000 jonathan michaels wrote: > On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote: >> Some quite lively offline discussion has come to conclusion with the >> following suggestions to change the support policy. Obviously, this >> is what we feel would be a good idea, but it's obviously open to >> discussion and there's nobody demanding anything here. It just seems >> "better". Thanks for the suggestions, but it might have helped to avoid confusion if you had contacted the FreeBSD security team privately before announcing your ideas here... >> Final >> The final minor release on a given branch will be supported by >> the Security Officer for a minimum of 24 months after the release. > > thank you gentle peoples for working out this solution. it has given me > some much needed clarity as regards forward moving planning. No it hasn't. The FreeBSD Security team hasn't agreed to anything yet. Colin Percival From owner-freebsd-stable@FreeBSD.ORG Wed Sep 24 00:01:48 2008 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 E5B13106567C; Wed, 24 Sep 2008 00:01:48 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id BACA08FC13; Wed, 24 Sep 2008 00:01:48 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [172.16.12.8] (covad-jrhett.meer.net [209.157.140.144]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8O01aud072565; Tue, 23 Sep 2008 17:01:36 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=-0.953] Message-Id: From: Jo Rhett To: Colin Percival In-Reply-To: <48D97F9C.3050309@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 23 Sep 2008 17:01:36 -0700 References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> <20080924093252.02048@caamora.com.au> <48D97F9C.3050309@freebsd.org> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-stable Stable , jonathan michaels , Robert Watson , "Simon L. Nielsen" Subject: Re: proposed change to support policy for FreeBSD Releases 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, 24 Sep 2008 00:01:49 -0000 On Sep 23, 2008, at 4:45 PM, Colin Percival wrote: > jonathan michaels wrote: >> On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote: >>> Some quite lively offline discussion has come to conclusion with >>> the following suggestions to change the support policy. >>> Obviously, this is what we feel would be a good idea, but it's >>> obviously open to discussion and there's nobody demanding >>> anything here. It just seems "better". > > Thanks for the suggestions, but it might have helped to avoid > confusion > if you had contacted the FreeBSD security team privately before > announcing > your ideas here... I'm sorry, I'm confused. This spawned from an ongoing conversation on this list. Rather than have the dialog spin around, I figured it would be better to post a specific example of what I thought. > No it hasn't. The FreeBSD Security team hasn't agreed to anything > yet. Yes, absolutely to that. As posted this is my own idea, adjusted some based on input from various others, none of whom are on the freebsd security team. I'd love to hear what the freebsd security team thinks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Wed Sep 24 03:36:02 2008 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 47D511065670 for ; Wed, 24 Sep 2008 03:36:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 2974F8FC12 for ; Wed, 24 Sep 2008 03:36:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id JQHS1a00M0b6N64A4Tc1Kx; Wed, 24 Sep 2008 03:36:01 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id JTc01a00F4v8bD78PTc0rh; Wed, 24 Sep 2008 03:36:01 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=pIq-z2nl7QMYvnACejEA:9 a=ZtzU1knWu6uHAt-1Xj9WS6hqJ1MA:4 a=EoioJ0NPDVgA:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 8493C17B81A; Tue, 23 Sep 2008 20:36:00 -0700 (PDT) Date: Tue, 23 Sep 2008 20:36:00 -0700 From: Jeremy Chadwick To: Jack Vogel Message-ID: <20080924033600.GA71488@icarus.home.lan> References: <48D8BAF1.1020602@incunabulum.net> <20080923100601.GA52531@icarus.home.lan> <2a41acea0809231136o51201085g3ba38dfb625ef217@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0809231136o51201085g3ba38dfb625ef217@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Bruce M Simpson , FreeBSD stable Subject: Re: fxp multicast forwarding 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: Wed, 24 Sep 2008 03:36:02 -0000 On Tue, Sep 23, 2008 at 11:36:38AM -0700, Jack Vogel wrote: > LOL, sorry to disappoint you but I'm not responsible for fxp, Intel didn't write > it, and i've never touched it :) Now that wouldnt mean that I can't look at it, > but I am very busy right now, so unless there's no alternative I'd rather not. > > On Tue, Sep 23, 2008 at 3:06 AM, Jeremy Chadwick wrote: > > On Tue, Sep 23, 2008 at 10:46:25AM +0100, Bruce M Simpson wrote: > >> Hi, > >> > >> Whilst doing some QA work on XORP on my desktop, which has fxp0 and > >> msk0, fxp0 got totally hosed. > >> I was running PIM-SM and IGMPv2 router-mode on the box at the time. > >> > >> I wonder if this is related to the problems with fxp multicast > >> transmission I saw back in April. > >> I'm a bit concerned about this as fxp is still a very widespread and > >> useful network chip. > >> > >> I am running 7.0-RELEASE-p4/amd64. > >> sysctls for dev.fxp.0 are set to their default values. > >> > >> I'm not expert on the fxp driver internals, but perhaps someone else has > >> seen this kind of problem before. Multicast-promiscuous mode (aka > >> ALLMULTI) was enabled on the interface. I know some NICs have problems > >> with this, or don't even support it. > >> > >> The errors look like this: > >> fxp0: SCB timeout: 0x10 0x0 0x80 0x0 > >> fxp0: SCB timeout: 0x10 0x0 0x80 0x0 > >> fxp0: DMA timeout > >> ... repeated ... > >> > >> Attempted workarounds which don't work to un-wedge the chip: > >> Reload the fxp0 microcode with "ifconfig fxp0 link0" > >> Forcibly unloading the kernel module and reloading it > >> Unpatching and repatching at the switch (a cheap 10/100 one) > >> Enabling and disabling promiscuous mode > >> Twiddling dev.fxp.0.noflow > >> > >> The link status looks fine, but the card will not send or receive traffic. > >> A warm reboot was enough to get things back up again. > >> > >> regards, > >> BMS > > > > Adding Jack Vogel, who's responsible for fxp(4). Ha, wow! I totally made the assumption you maintained fxp(4) based upon of em(4). Seemed logical, but once again, I failed the team. Regardless, thanks for looking into this when time permits. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Sep 24 03:57:19 2008 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 A5849106566B for ; Wed, 24 Sep 2008 03:57:19 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 011348FC1E for ; Wed, 24 Sep 2008 03:57:18 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m8O3vHic029035; Wed, 24 Sep 2008 11:57:17 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m8O3vHBU029034; Wed, 24 Sep 2008 11:57:17 +0800 (KRAST) (envelope-from eugen) Date: Wed, 24 Sep 2008 11:57:17 +0800 From: Eugene Grosbein To: stable@freebsd.org Message-ID: <20080924035717.GA28651@svzserv.kemerovo.su> References: <20080923172718.GA86225@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080923172718.GA86225@grosbein.pp.ru> User-Agent: Mutt/1.4.2.3i Cc: ps@freebsd.org Subject: Re: RELENG_7: buildworld failed with MODULES_WITH_WORLD= 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, 24 Sep 2008 03:57:19 -0000 On Wed, Sep 24, 2008 at 01:27:18AM +0800, Eugene Grosbein wrote: > I've just tried to build NanoBSD from 7.0-STABLE sources > with MODULES_WITH_WORLD knob enabled and it failed. > Note that NanoBSD uses make -j3 by default and I have dualcore system. > > ===> sys/modules/nfslockd (depend) > @ -> /usr/local/src/sys > machine -> /usr/local/src/sys/i386/include > echo "#define INET6 1" > opt_inet6.h > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h > rm -f .depend > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I. -I@ > -I@/contrib/altq /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_clnt.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_server.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_svc.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_xdr.c > /usr/local/src/sys/modules/nfslockd/../../nlm/sm_inter_xdr.c > In file included from > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c:48: > @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory > In file included from > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:56: > @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory > mkdep: compile failed > *** Error code 1 I see this problem was fixed in HEAD nearly month ago, but not in RELENG_7. Please perform MFC. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Wed Sep 24 04:22:25 2008 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 25F35106564A; Wed, 24 Sep 2008 04:22:25 +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 EAD6C8FC2A; Wed, 24 Sep 2008 04:22:24 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 8CF618C072; Tue, 23 Sep 2008 23:22:24 -0500 (CDT) Date: Tue, 23 Sep 2008 23:22:24 -0500 To: jonathan michaels Message-ID: <20080924042224.GA11837@soaustin.net> References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> <20080924093252.02048@caamora.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080924093252.02048@caamora.com.au> User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) Cc: Jo Rhett , Robert Watson , freebsd-stable Stable , cperciva@freebsd.org, "Simon L. Nielsen" 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, 24 Sep 2008 04:22:25 -0000 On Wed, Sep 24, 2008 at 09:32:52AM +1000, jonathan michaels wrote: > thank you gentle peoples for working out this solution. Unfortunately it has not been 'worked out' with the decision-makers. It has been suggested. Doing s/suggested/agreed to/ is not an automatic process. mcl From owner-freebsd-stable@FreeBSD.ORG Wed Sep 24 10:58:43 2008 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 A94FE1065681; Wed, 24 Sep 2008 10:58:43 +0000 (UTC) (envelope-from jon@seaholm.caamora.com.au) Received: from seaholm.caamora.com.au (seaholm.caamora.com.au [203.7.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6998FC14; Wed, 24 Sep 2008 10:58:34 +0000 (UTC) (envelope-from jon@seaholm.caamora.com.au) Received: (from jon@localhost) by seaholm.caamora.com.au (8.11.1/8.11.1) id m8OAwJT00488; Wed, 24 Sep 2008 20:58:19 +1000 (EST) Message-ID: <20080924205819.57666@caamora.com.au> Date: Wed, 24 Sep 2008 20:58:19 +1000 From: jonathan michaels To: Mark Linimon References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> <20080924093252.02048@caamora.com.au> <20080924042224.GA11837@soaustin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <20080924042224.GA11837@soaustin.net>; from Mark Linimon on Tue, Sep 23, 2008 at 11:22:24PM -0500 Organisation: Caamora, PO Box 144, Rosebery NSW 1445 Australia Cc: Jo Rhett , freebsd-stable Stable , Robert Watson , "Simon L. Nielsen" , cperciva@freebsd.org Subject: Re: (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, 24 Sep 2008 10:58:43 -0000 On Tue, Sep 23, 2008 at 11:22:24PM -0500, Mark Linimon wrote: > On Wed, Sep 24, 2008 at 09:32:52AM +1000, jonathan michaels wrote: > > thank you gentle peoples for working out this solution. > > Unfortunately it has not been 'worked out' with the decision-makers. > It has been suggested. Doing s/suggested/agreed to/ is not an > automatic process. i am not really good with this whole english/words usage thing, i am sorry that i have caused this grieft, it was not my intention but that seems to be somewhat mute as i managed to fall foul again .. perhaps one day sorry for taking my ... whats teh point.. again, sincere apologies to all concerened, for teh inconvience that i have caused. much kind regards and appreciations jonathan -- ================================================================ powered by .. QNX, OS9 and freeBSD -- http://caamora com au/operating system ==== === appropriate solution in an inappropriate world === ==== From owner-freebsd-stable@FreeBSD.ORG Wed Sep 24 16:41:43 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1060) id 52E821065689; Wed, 24 Sep 2008 16:41:43 +0000 (UTC) Date: Wed, 24 Sep 2008 16:41:43 +0000 From: Craig Rodrigues To: freebsd-stable@freebsd.org Message-ID: <20080924164143.GA9675@crodrigues.org> References: <20080915200838.GA51668@crodrigues.org> <20080915221704.GA4580@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080915221704.GA4580@crodrigues.org> User-Agent: Mutt/1.4.2.1i Cc: Alfred Perlstein , re@FreeBSD.org, Dag-Erling Smorgrav Subject: Re: ssh to FreeBSD 4 systems: xmalloc: zero size 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, 24 Sep 2008 16:41:43 -0000 Hi, I have received no feedback about this problem. Can someone apply the patch to SSH to fix the regression which I mentioned earlier? -- Craig Rodrigues rodrigc@crodrigues.org On Mon, Sep 15, 2008 at 10:17:04PM +0000, Craig Rodrigues wrote: > Hi, > > I can confirm that this patch solves my problem: > > https://bugzilla.mindrot.org/attachment.cgi?id=1554 > > That patch is part of this ssh bug: > > https://bugzilla.mindrot.org/show_bug.cgi?id=1496 > > Can we get this fix into FreeBSD before the 7.1 RELEASE? > > Thanks. > -- > Craig Rodrigues > rodrigc@crodrigues.org From owner-freebsd-stable@FreeBSD.ORG Wed Sep 24 16:55:12 2008 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 A4837106568E; Wed, 24 Sep 2008 16:55:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 209A88FC16; Wed, 24 Sep 2008 16:55:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8OGshJh084657; Wed, 24 Sep 2008 12:55:02 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 24 Sep 2008 12:36:35 -0400 User-Agent: KMail/1.9.7 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <200809231610.17625.jhb@freebsd.org> <5307532F-194E-482D-8617-2FB6E13E3F83@netconsonance.com> In-Reply-To: <5307532F-194E-482D-8617-2FB6E13E3F83@netconsonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809241236.36319.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 24 Sep 2008 12:55:02 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8324/Wed Sep 24 06:55:43 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Jo Rhett , Robert Watson , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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, 24 Sep 2008 16:55:12 -0000 On Tuesday 23 September 2008 04:42:13 pm Jo Rhett wrote: > John, we're already committed to upgrade to 6.3 (since it will > currently be supported longer than 6.4). 6.2 support isn't part of > this conversation, it has entirely revolved around support periods for > upcoming releases. Then replace 6.2 with 6.3 in my comments. Granted, there's nothing to do with 6.3 until it is EOL'd, but you should still get the general idea. I picked 6.2 just to have a specific example to work with. > On Sep 23, 2008, at 1:10 PM, John Baldwin wrote: > > Jo, so it seems to me that you could just start by maintaining your > > own set of > > extended support patches for the FreeBSD releases you care about. I > > don't > > think you have to be a committer or secteam@ member to do this. It > > does mean > > that you might not be able to fix a bug in, say, 6.2 at the same > > exact time > > the advisory goes out at first, but you could take the patch from the > > advisory and apply it to your local 6.2 tree and then update your > > "cumulative > > patch" (would probably want to use some sort of source code control > > for this > > where you basically branch from FreeBSD X.Y where X.Y is a vendor > > branch of > > sorts). That would let you build the "street cred", as it were, to > > be able > > to get the patches directly into FreeBSD more easily. > > > > To start with it is probably going to be a bit slow as far as > > getting things > > committed directly to FreeBSD proper as it means finding a committer > > who has > > the time to test and review your patch and then commit it. However, > > the "Unofficial FreeBSD 6.2 Patchset" can be updated more quickly > > since it is > > something that would be under your control. Also, doing this will > > give you > > insight into exactly what is required to support a release after it > > is EOL'd > > in a much more direct fashion than an e-mail thread. > > > > -- > > John Baldwin > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > > _______________________________________________ > 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" > -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 00:42:14 2008 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 C856E1065686; Thu, 25 Sep 2008 00:42:14 +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 B29328FC0A; Thu, 25 Sep 2008 00:42:14 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 999B31A3C39; Wed, 24 Sep 2008 17:24:24 -0700 (PDT) Date: Wed, 24 Sep 2008 17:24:24 -0700 From: Alfred Perlstein To: Craig Rodrigues Message-ID: <20080925002424.GH36572@elvis.mu.org> References: <20080915200838.GA51668@crodrigues.org> <20080915221704.GA4580@crodrigues.org> <20080924164143.GA9675@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080924164143.GA9675@crodrigues.org> User-Agent: Mutt/1.4.2.3i Cc: re@FreeBSD.org, freebsd-stable@freebsd.org, Dag-Erling Smorgrav Subject: Re: ssh to FreeBSD 4 systems: xmalloc: zero size 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, 25 Sep 2008 00:42:14 -0000 * Craig Rodrigues [080924 09:42] wrote: > Hi, > > I have received no feedback about this problem. > Can someone apply the patch to SSH to fix the regression > which I mentioned earlier? Hey Craig, if no one replies by next week, please just apply the patch, it's pretty critical that FreeBSD be able to talk ssh to other machines out there. -Alfred > -- > Craig Rodrigues > rodrigc@crodrigues.org > > > On Mon, Sep 15, 2008 at 10:17:04PM +0000, Craig Rodrigues wrote: > > Hi, > > > > I can confirm that this patch solves my problem: > > > > https://bugzilla.mindrot.org/attachment.cgi?id=1554 > > > > That patch is part of this ssh bug: > > > > https://bugzilla.mindrot.org/show_bug.cgi?id=1496 > > > > Can we get this fix into FreeBSD before the 7.1 RELEASE? > > > > Thanks. > > -- > > Craig Rodrigues > > rodrigc@crodrigues.org > _______________________________________________ > 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" -- - Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 01:17:01 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1060) id ED6EF1065687; Thu, 25 Sep 2008 01:17:01 +0000 (UTC) Date: Thu, 25 Sep 2008 01:17:01 +0000 From: Craig Rodrigues To: Alfred Perlstein Message-ID: <20080925011701.GB35391@crodrigues.org> References: <20080915200838.GA51668@crodrigues.org> <20080915221704.GA4580@crodrigues.org> <20080924164143.GA9675@crodrigues.org> <20080925002424.GH36572@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080925002424.GH36572@elvis.mu.org> User-Agent: Mutt/1.4.2.1i Cc: re@FreeBSD.org, freebsd-stable@freebsd.org, Dag-Erling Smorgrav Subject: Re: ssh to FreeBSD 4 systems: xmalloc: zero size 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, 25 Sep 2008 01:17:02 -0000 On Wed, Sep 24, 2008 at 05:24:24PM -0700, Alfred Perlstein wrote: > Hey Craig, if no one replies by next week, please just apply > the patch, it's pretty critical that FreeBSD be able to talk > ssh to other machines out there. Des applied the necessary fix: http://lists.freebsd.org/pipermail/cvs-src/2008-September/095939.html so all is well. Thanks! -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 01:58:21 2008 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 551A21065689 for ; Thu, 25 Sep 2008 01:58:21 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (s4.stradamotorsports.com [64.81.163.122]) by mx1.freebsd.org (Postfix) with ESMTP id 423578FC12 for ; Thu, 25 Sep 2008 01:58:20 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from w16.stradamotorsports.com (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.8/8.13.8) with ESMTP id m8P1wFe6025479 for ; Wed, 24 Sep 2008 18:58:15 -0700 (PDT) (envelope-from jcw@highperformance.net) Message-ID: <48DAF037.2000102@highperformance.net> Date: Wed, 24 Sep 2008 18:58:15 -0700 From: "Jason C. Wells" User-Agent: Thunderbird 2.0.0.4pre (X11/20080205) MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on s4.stradamotorsports.com Subject: CPUTYPE Now Required? 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, 25 Sep 2008 01:58:21 -0000 While trying to build RELENG_6 I receive this error: make: fatal errors encountered -- cannot continue "/usr/src/Makefile.inc1", line 142: warning: "MAKEFLAGS= CPUTYPE=pentium /usr/obj/usr/src/make.i386/make -f /dev/null -m /usr/src/share/mk -V CPUTYPE" returned non-zero status "/usr/src/Makefile.inc1", line 144: CPUTYPE global should be set with ?=. I've never set CPUTYPE in the past. I don't want specific CPU optimizations as I am building for multiple generations of processor. What is a person to do? Later, Jason From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 02:03:18 2008 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 34E101065687 for ; Thu, 25 Sep 2008 02:03:18 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (dsl081-163-120.sea1.dsl.speakeasy.net [64.81.163.120]) by mx1.freebsd.org (Postfix) with ESMTP id 0952F8FC12 for ; Thu, 25 Sep 2008 02:03:17 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from w16.stradamotorsports.com (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.8/8.13.8) with ESMTP id m8P23FX4025567 for ; Wed, 24 Sep 2008 19:03:15 -0700 (PDT) (envelope-from jcw@highperformance.net) Message-ID: <48DAF163.8060502@highperformance.net> Date: Wed, 24 Sep 2008 19:03:15 -0700 From: "Jason C. Wells" User-Agent: Thunderbird 2.0.0.4pre (X11/20080205) MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on s4.stradamotorsports.com Subject: buildworld fails immediately 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, 25 Sep 2008 02:03:18 -0000 I am trying to build RELENG_6. I receive the following errors. [root@s4cr /usr/src]# make buildworld "/dev/null", line 4: Need an operator "/dev/null", line 6: Need an operator "/dev/null", line 8: Need an operator "/dev/null", line 9: Need an operator "/dev/null", line 11: Need an operator "/dev/null", line 12: Need an operator "/dev/null", line 13: Need an operator "/dev/null", line 15: Need an operator "/dev/null", line 16: Need an operator "/dev/null", line 18: Need an operator I figured I got a partial update or something. Re-supping didn't help. I am building on 6.2-RELEASE inside a jail. Jails are new for me so maybe I missed something there. Any ideas? Thanks, Jason From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 02:03:50 2008 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 C4DF91065690 for ; Thu, 25 Sep 2008 02:03:50 +0000 (UTC) (envelope-from joji@eskimo.com) Received: from ultra5.eskimo.com (ultra5.eskimo.com [204.122.16.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB5E8FC20 for ; Thu, 25 Sep 2008 02:03:50 +0000 (UTC) (envelope-from joji@eskimo.com) Received: from eskimo.com (eskimo.com [204.122.16.13]) by ultra5.eskimo.com (8.14.3/8.14.0) with ESMTP id m8P23nEC010708; Wed, 24 Sep 2008 19:03:49 -0700 Received: (from joji@localhost) by eskimo.com (8.9.1a/8.9.1) id TAA12687; Wed, 24 Sep 2008 19:03:49 -0700 (PDT) Date: Wed, 24 Sep 2008 19:03:49 -0700 From: Joseph Olatt To: "Andrey V. Elsukov" Message-ID: <20080924190349.A12174@eskimo.com> References: <20080915192515.A13327@eskimo.com> <48D7260C.9020503@yandex.ru> <20080922082957.A20123@eskimo.com> <48D87A9D.60108@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <48D87A9D.60108@yandex.ru>; from bu7cher@yandex.ru on Tue, Sep 23, 2008 at 09:11:57AM +0400 Cc: FreeBSD Mailing List , S?ren Schmidt Subject: Re: unsupported NVIDIA SATA controller 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, 25 Sep 2008 02:03:50 -0000 On Tue, Sep 23, 2008 at 09:11:57AM +0400, Andrey V. Elsukov wrote: > Joseph Olatt wrote: > >>> none13@pci0:0:14:0: class=0x010485 card=0x01371025 chip=0x07f810de rev=0xa2 hdr=0x00 > >>> vendor = 'Nvidia Corp' > >>> class = mass storage > >>> subclass = RAID > >> Do you still have this problem? > >> It seems that your controller is AHCI-capable. > >> I can make a patch if is it needed. > > > > Yes, I'm still have the above problem. And, yes, the controller appears > > to be ACHI-capable (at least according to Ubuntu. see [1]) > > > > I would greatly appreciate a patch if you can provide one. > > > > regards, > > joseph > > > > > > [1]: http://www.eskimo.com/~joji/nvidia_sata/ > > Hi, Joseph. > > Try attached patch. Hello Audrey, Sorry I did not get a chance to try your patch earlier. Had to take of the job that feeds the kids... priorities... ;-) I just tried the patch and seems like it works wonderfully. /*** Begin "pciconf -lv" output ***/ atapci1@pci0:0:14:0: class=0x010485 card=0x01371025 chip=0x07f810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' class = mass storage subclass = RAID /*** End "pciconf -lv" output ***/ /*** Begin "dmesg" relevant portions ***/ atapci1: port 0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f mem 0xfea7c000-0xfea7dfff irq 21 at device 14.0 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ad4: 238475MB at ata2-master SATA300 acd0: DVDR at ata4-master SATA150 /*** End "dmesg" relevant portions ***/ I hope your will be included into the STABLE code soon. Thank you very much for the patch. regards, joseph P.S. This controller is on an NVIDIA MCP73 motherboard. See http://www.eskimo.com/~joji/nvidia_sata/dmidecode.log From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 03:43:23 2008 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 609BE106568A for ; Thu, 25 Sep 2008 03:43:23 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4418FC17 for ; Thu, 25 Sep 2008 03:43:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA06.westchester.pa.mail.comcast.net with comcast id JpB11a00A0vyq2s56rjNzp; Thu, 25 Sep 2008 03:43:22 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA05.westchester.pa.mail.comcast.net with comcast id JrjM1a0044v8bD73RrjMDW; Thu, 25 Sep 2008 03:43:22 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=UuqiOcqwKZ4RCBMs7Q8A:9 a=lKYIZOyDlKsO8xL4vXocm50rWxQA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id A0234C9419; Wed, 24 Sep 2008 20:43:20 -0700 (PDT) Date: Wed, 24 Sep 2008 20:43:20 -0700 From: Jeremy Chadwick To: "Jason C. Wells" Message-ID: <20080925034320.GA2985@icarus.home.lan> References: <48DAF163.8060502@highperformance.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DAF163.8060502@highperformance.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable Subject: Re: buildworld fails immediately 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, 25 Sep 2008 03:43:23 -0000 On Wed, Sep 24, 2008 at 07:03:15PM -0700, Jason C. Wells wrote: > I am trying to build RELENG_6. I receive the following errors. > > [root@s4cr /usr/src]# make buildworld > "/dev/null", line 4: Need an operator > "/dev/null", line 6: Need an operator > "/dev/null", line 8: Need an operator > "/dev/null", line 9: Need an operator > "/dev/null", line 11: Need an operator > "/dev/null", line 12: Need an operator > "/dev/null", line 13: Need an operator > "/dev/null", line 15: Need an operator > "/dev/null", line 16: Need an operator > "/dev/null", line 18: Need an operator > > > I figured I got a partial update or something. Re-supping didn't help. > I am building on 6.2-RELEASE inside a jail. Jails are new for me so > maybe I missed something there. Your previous mail (Subject: CPUTYPE Now Required?) answers what's happening quite clearly. Look closely at the -f argument being passed to make. I cannot help you with jails, as I know nothing about them. But it appears to me you have a very broken make.conf or build environment. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 03:46:32 2008 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 982641065687 for ; Thu, 25 Sep 2008 03:46:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 45FBA8FC27 for ; Thu, 25 Sep 2008 03:46:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA03.westchester.pa.mail.comcast.net with comcast id JoHc1a01d1GhbT853rmWAL; Thu, 25 Sep 2008 03:46:30 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA07.westchester.pa.mail.comcast.net with comcast id JrmV1a00E4v8bD73TrmWJw; Thu, 25 Sep 2008 03:46:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=wrtYlOEWYFxWdPE1n3sA:9 a=EsATV0Fx-NH0dL4e6b0A:7 a=sFIhL_a6EH692XrLMmXCAj7qYvAA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id B374BC9419; Wed, 24 Sep 2008 20:46:29 -0700 (PDT) Date: Wed, 24 Sep 2008 20:46:29 -0700 From: Jeremy Chadwick To: "Jason C. Wells" Message-ID: <20080925034629.GB2985@icarus.home.lan> References: <48DAF037.2000102@highperformance.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DAF037.2000102@highperformance.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable Subject: Re: CPUTYPE Now Required? 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, 25 Sep 2008 03:46:32 -0000 On Wed, Sep 24, 2008 at 06:58:15PM -0700, Jason C. Wells wrote: > While trying to build RELENG_6 I receive this error: > > make: fatal errors encountered -- cannot continue > "/usr/src/Makefile.inc1", line 142: warning: "MAKEFLAGS= CPUTYPE=pentium > /usr/obj/usr/src/make.i386/make -f /dev/null -m /usr/src/share/mk -V > CPUTYPE" returned non-zero status > "/usr/src/Makefile.inc1", line 144: CPUTYPE global should be set with ?=. You *most definitely* have CPUTYPE defined somewhere. There is no default make.conf, and the example make.conf in /usr/share/examples/etc does not define CPUTYPE=pentium anywhere. The error is telling you that you should use CPUTYPE?=processor, not CPUTYPE=processor. > I've never set CPUTYPE in the past. I don't want specific CPU > optimizations as I am building for multiple generations of processor. > > What is a person to do? If you've tinkered with make.conf at all, you may have some quotation madness going on there which is running amok. Regardless, this very much looks like an issue specific to your system. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 03:56:02 2008 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 BA269106568F for ; Thu, 25 Sep 2008 03:56:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id A3D028FC1F for ; Thu, 25 Sep 2008 03:56:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id JoHf1a0040S2fkCA4rw2fu; Thu, 25 Sep 2008 03:56:02 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id Jrw11a0054v8bD78Vrw1mi; Thu, 25 Sep 2008 03:56:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=SuVO7oZqrLYA:10 a=JI2IwJMDiNMA:10 a=QycZ5dHgAAAA:8 a=Q0vwuABzeySfMhf3K_8A:9 a=o0wkJkrVPv7SCkLuD44A:7 a=iMP8xQ19JYwvHNPRvcKs1JrU-roA:4 a=EoioJ0NPDVgA:10 a=8b0TY1xhFYQA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 40A30C9419; Wed, 24 Sep 2008 20:56:01 -0700 (PDT) Date: Wed, 24 Sep 2008 20:56:01 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20080925035601.GA3158@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: make-delete-old-libs not removing some libraries 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, 25 Sep 2008 03:56:02 -0000 Came across this one tonight. I see this on two separate RELENG_7 boxes, built at different times (one in August (which shows files left over from April and May), the other today). Both use identical src.conf files. The date used in the grep -v is today, immediately after a full system rebuild (world). None of these are being deleted during "make delete-old-libs" (the aout/ and compat/ directories should probably remain). $ ls -l /usr/lib | grep -v '24 Sep' total 30270 drwxr-xr-x 2 root wheel 512 7 Sep 04:33 aout/ drwxr-xr-x 3 root wheel 512 7 Sep 05:40 compat/ -r--r--r-- 1 root wheel 175488 7 Sep 04:34 libasn1.so.9 -r--r--r-- 1 root wheel 11248 7 Sep 04:33 libbluetooth.so.3 -r--r--r-- 1 root wheel 88762 7 Sep 04:33 libgssapi.a -r--r--r-- 1 root wheel 35184 7 Sep 04:33 libgssapi.so.9 -r--r--r-- 1 root wheel 62600 7 Sep 04:34 libgssapi_krb5.so.9 -r--r--r-- 1 root wheel 59368 7 Sep 04:34 libhdb.so.9 -r--r--r-- 1 root wheel 34872 7 Sep 04:34 libkadm5clnt.so.9 -r--r--r-- 1 root wheel 55376 7 Sep 04:34 libkadm5srv.so.9 -r--r--r-- 1 root wheel 20472 7 Sep 04:34 libkafs5.so.9 -r--r--r-- 1 root wheel 283304 7 Sep 04:34 libkrb5.so.9 -r--r--r-- 1 root wheel 87278 7 Sep 04:33 libmilter.a -r--r--r-- 1 root wheel 51248 7 Sep 04:33 libmilter.so.4 -r--r--r-- 1 root wheel 656420 7 Sep 04:33 libngatm.a -r--r--r-- 1 root wheel 430512 7 Sep 04:33 libngatm.so.3 -r--r--r-- 1 root wheel 60320 7 Sep 04:34 libroken.so.9 -r--r--r-- 1 root wheel 21544 7 Sep 04:34 libsdp.so.3 -r--r--r-- 1 root wheel 20504 7 Sep 04:34 pam_krb5.so.4 -r--r--r-- 1 root wheel 9984 7 Sep 04:34 pam_ksu.so.4 -r--r--r-- 1 root wheel 30032 7 Sep 04:35 snmp_atm.so.5 # make delete-old-libs >>> Removing old libraries Please be sure no application still uses those libraries, else you can not start such an application. Consult UPDATING for more information regarding how to cope with the removal/revision bump of a specific library. >>> Old libraries removed # src.conf used: WITHOUT_ATM=true WITHOUT_BLUETOOTH=true WITHOUT_HTML=true WITHOUT_I4B=true WITHOUT_INET6=true WITHOUT_IPFILTER=true WITHOUT_IPX=true WITHOUT_KERBEROS=true WITHOUT_LIB32=true WITHOUT_NCP=true WITHOUT_PROFILE=true WITHOUT_SENDMAIL=true -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 03:58:35 2008 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 0CF1E1065686; Thu, 25 Sep 2008 03:58:35 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id D9A758FC0A; Thu, 25 Sep 2008 03:58:34 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1Kihzu-00097K-8F; Wed, 24 Sep 2008 23:58:34 -0400 Date: Wed, 24 Sep 2008 23:58:34 -0400 From: Gary Palmer To: Jeremy Chadwick Message-ID: <20080925035834.GD60230@in-addr.com> References: <48DAF163.8060502@highperformance.net> <20080925034320.GA2985@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080925034320.GA2985@icarus.home.lan> Cc: "Jason C. Wells" , freebsd-stable Subject: Re: buildworld fails immediately 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, 25 Sep 2008 03:58:35 -0000 On Wed, Sep 24, 2008 at 08:43:20PM -0700, Jeremy Chadwick wrote: > On Wed, Sep 24, 2008 at 07:03:15PM -0700, Jason C. Wells wrote: > > I am trying to build RELENG_6. I receive the following errors. > > > > [root@s4cr /usr/src]# make buildworld > > "/dev/null", line 4: Need an operator > > "/dev/null", line 6: Need an operator > > "/dev/null", line 8: Need an operator > > "/dev/null", line 9: Need an operator > > "/dev/null", line 11: Need an operator > > "/dev/null", line 12: Need an operator > > "/dev/null", line 13: Need an operator > > "/dev/null", line 15: Need an operator > > "/dev/null", line 16: Need an operator > > "/dev/null", line 18: Need an operator > > > > > > I figured I got a partial update or something. Re-supping didn't help. > > I am building on 6.2-RELEASE inside a jail. Jails are new for me so > > maybe I missed something there. > > Your previous mail (Subject: CPUTYPE Now Required?) answers what's > happening quite clearly. Look closely at the -f argument being > passed to make. > > I cannot help you with jails, as I know nothing about them. But it > appears to me you have a very broken make.conf or build environment. Actually, this is in Makefile.inc1 _CPUTYPE!= MAKEFLAGS= CPUTYPE=${_TARGET_CPUTYPE} ${MAKE} \ -f /dev/null -m ${.CURDIR}/share/mk -V CPUTYPE (line 141 in my 6.3 era source tree) Which I think you'll find ends up with the make command the user posted in the other e-mail. Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 05:02:02 2008 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 23BED106568C for ; Thu, 25 Sep 2008 05:02:02 +0000 (UTC) (envelope-from ru@FreeBSD.org) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id D28638FC16 for ; Thu, 25 Sep 2008 05:02:01 +0000 (UTC) (envelope-from ru@FreeBSD.org) Received: from [87.242.97.68] (port=1301 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Kiika-0003s8-KW; Thu, 25 Sep 2008 04:46:48 +0000 Date: Thu, 25 Sep 2008 08:46:40 +0400 From: Ruslan Ermilov To: "Jason C. Wells" Message-ID: <20080925044640.GA76968@edoofus.dev.vega.ru> References: <48DAF163.8060502@highperformance.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DAF163.8060502@highperformance.net> Cc: freebsd-stable Subject: Re: buildworld fails immediately 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, 25 Sep 2008 05:02:02 -0000 On Wed, Sep 24, 2008 at 07:03:15PM -0700, Jason C. Wells wrote: > I am trying to build RELENG_6. I receive the following errors. > > [root@s4cr /usr/src]# make buildworld > "/dev/null", line 4: Need an operator > "/dev/null", line 6: Need an operator > "/dev/null", line 8: Need an operator > "/dev/null", line 9: Need an operator > "/dev/null", line 11: Need an operator > "/dev/null", line 12: Need an operator > "/dev/null", line 13: Need an operator > "/dev/null", line 15: Need an operator > "/dev/null", line 16: Need an operator > "/dev/null", line 18: Need an operator > > > I figured I got a partial update or something. Re-supping didn't help. > I am building on 6.2-RELEASE inside a jail. Jails are new for me so > maybe I missed something there. > > Any ideas? > Make sure /dev/null inside a jail is a device and not a plain file. If the latter, you probably forgot to mount devfs onto a jail's /dev. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 05:13:25 2008 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 923491065689; Thu, 25 Sep 2008 05:13:25 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by mx1.freebsd.org (Postfix) with ESMTP id 41A828FC1A; Thu, 25 Sep 2008 05:13:25 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (localhost [127.0.0.1]) by mail.ismobile.com (Postfix) with ESMTP id 92DC433C02; Thu, 25 Sep 2008 07:03:22 +0200 (CEST) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=ismobile.com; h=received:date:from:to:cc:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding:content-disposition; q=dns/txt; s=selector1; bh=Xgst4yW8uK4vQRlLiwOuUkVBJAs=; b=f0PTZwUoiF20ejwdQKHupwUBjMeAEzDBvJ4Rbnx6rPPtrQETZI6zcptBD/doV/4KOpqtGJPYl0XtOHN3cvxTRrVsk4AEPbsNlEtl0u17q657RGVweAaJodfV9TAwa3fthxSHJX9Wdsw6ABKsJA0PWKrtbtf+fYkanknzkMc25Sk= Received: from [10.255.253.2] (modgunn.iii-norr.com [213.242.135.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 6D55533C01; Thu, 25 Sep 2008 07:03:22 +0200 (CEST) Date: Thu, 25 Sep 2008 07:03:21 +0200 From: Goran Lowkrantz To: "Andrey V. Elsukov" Message-ID: <47774185B9D9E55501044276@[10.255.253.2]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; FORMAT=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: FreeBSD Mailing List , Joseph Olatt , =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: unsupported NVIDIA SATA controller 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, 25 Sep 2008 05:13:25 -0000 Hi, FYI, I have added your patch on an MCP67 of an ASUS M2N-VM DVI motherboard=20 and it's been up for about a day, dmesg looks OK and it survived the backup = of its managed disks. So, unless you hear more from me, it worked. FreeBSD midgard.glz.hidden-powers.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE = #1: Tue Sep 23 19:57:47 CEST 2008=20 root@midgard.glz.hidden-powers.com:/usr/obj/usr/src/sys/MIDGARD amd64 00:09.0 IDE interface [0101]: nVidia Corporation MCP67 AHCI Controller=20 [10de:0550] (rev a2) (prog-if 85 [Master SecO PriO]) Subsystem: ASUSTeK Computer Inc. Unknown device [1043:82b3] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- = Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=3Dfast >TAbort-=20 SERR- Cheers, Goran --On Tuesday, September 23, 2008 09:11 +0400 "Andrey V. Elsukov"=20 wrote: > Joseph Olatt wrote: >>>> none13@pci0:0:14:0: class=3D0x010485 card=3D0x01371025 = chip=3D0x07f810de >>>> rev=3D0xa2 hdr=3D0x00 vendor =3D 'Nvidia Corp' >>>> class =3D mass storage >>>> subclass =3D RAID >>> Do you still have this problem? >>> It seems that your controller is AHCI-capable. >>> I can make a patch if is it needed. >> >> Yes, I'm still have the above problem. And, yes, the controller appears >> to be ACHI-capable (at least according to Ubuntu. see [1]) >> >> I would greatly appreciate a patch if you can provide one. >> >> regards, >> joseph >> >> >> [1]: http://www.eskimo.com/~joji/nvidia_sata/ > > Hi, Joseph. > > Try attached patch. > > -- > WBR, Andrey V. Elsukov ................................................... the future isMobile Goran Lowkrantz System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule=E5, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ............................................... From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 05:21:58 2008 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 BDE741065687 for ; Thu, 25 Sep 2008 05:21:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id A238F8FC1C for ; Thu, 25 Sep 2008 05:21:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id JsNj1a02e0b6N64A7tMygA; Thu, 25 Sep 2008 05:21:58 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id JtMx1a0024v8bD78PtMxu4; Thu, 25 Sep 2008 05:21:58 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=RQpFD2A55ol5_APhxuQA:9 a=rGYeyDBia5m_UGW7bOkA:7 a=c5mC-wUzQSYkrLluuCBiYSVT4TkA:4 a=Olb2kf4d3MgA:10 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 41841C9419; Wed, 24 Sep 2008 22:21:57 -0700 (PDT) Date: Wed, 24 Sep 2008 22:21:57 -0700 From: Jeremy Chadwick To: Gary Palmer Message-ID: <20080925052157.GA4866@icarus.home.lan> References: <48DAF163.8060502@highperformance.net> <20080925034320.GA2985@icarus.home.lan> <20080925035834.GD60230@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080925035834.GD60230@in-addr.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "Jason C. Wells" , freebsd-stable Subject: Re: buildworld fails immediately 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, 25 Sep 2008 05:21:58 -0000 On Wed, Sep 24, 2008 at 11:58:34PM -0400, Gary Palmer wrote: > On Wed, Sep 24, 2008 at 08:43:20PM -0700, Jeremy Chadwick wrote: > > On Wed, Sep 24, 2008 at 07:03:15PM -0700, Jason C. Wells wrote: > > > I am trying to build RELENG_6. I receive the following errors. > > > > > > [root@s4cr /usr/src]# make buildworld > > > "/dev/null", line 4: Need an operator > > > "/dev/null", line 6: Need an operator > > > "/dev/null", line 8: Need an operator > > > "/dev/null", line 9: Need an operator > > > "/dev/null", line 11: Need an operator > > > "/dev/null", line 12: Need an operator > > > "/dev/null", line 13: Need an operator > > > "/dev/null", line 15: Need an operator > > > "/dev/null", line 16: Need an operator > > > "/dev/null", line 18: Need an operator > > > > > > > > > I figured I got a partial update or something. Re-supping didn't help. > > > I am building on 6.2-RELEASE inside a jail. Jails are new for me so > > > maybe I missed something there. > > > > Your previous mail (Subject: CPUTYPE Now Required?) answers what's > > happening quite clearly. Look closely at the -f argument being > > passed to make. > > > > I cannot help you with jails, as I know nothing about them. But it > > appears to me you have a very broken make.conf or build environment. > > Actually, this is in Makefile.inc1 > > _CPUTYPE!= MAKEFLAGS= CPUTYPE=${_TARGET_CPUTYPE} ${MAKE} \ > -f /dev/null -m ${.CURDIR}/share/mk -V CPUTYPE > > (line 141 in my 6.3 era source tree) > > Which I think you'll find ends up with the make command the user > posted in the other e-mail. Consider me educated. I'm sure one can understand why at first glance, seeing make -f /dev/null will make one's eyeballs grow. Sorry for the noise. The CPUTYPE problem still stands however, not sure where/how it's getting "pentium". Could be some horrible fall-out as a result of what Ruslan pointed out. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 08:56:02 2008 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 325371065687 for ; Thu, 25 Sep 2008 08:56:02 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [212.103.70.36]) by mx1.freebsd.org (Postfix) with ESMTP id DA7D88FC16 for ; Thu, 25 Sep 2008 08:56:01 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from hg-public-dock-8-dhcp.ethz.ch ([82.130.80.8] helo=default.fsck.ch) by secure.socket.ch with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KimN2-000F8I-80 for stable@freebsd.org; Thu, 25 Sep 2008 10:39:35 +0200 Message-ID: <48DB4E11.2060604@fsck.ch> Date: Thu, 25 Sep 2008 10:38:41 +0200 From: Tobias Roth User-Agent: Thunderbird 2.0.0.16 (X11/20080919) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.5 (-----) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hi My i386 buildworld with a default make.conf on RELENG_1 as of yesterday (2008/09/24) fails with the error below. Thanks for hints, Tobias [...] Content analysis details: (-5.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.1 AWL AWL: From: address is in the auto white-list X-SA-Exim-Connect-IP: 82.130.80.8 X-SA-Exim-Mail-From: freebsd.lists@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false Cc: Subject: buildworld fails in csh 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, 25 Sep 2008 08:56:02 -0000 Hi My i386 buildworld with a default make.conf on RELENG_1 as of yesterday (2008/09/24) fails with the error below. Thanks for hints, Tobias cc -O2 -fno-strict-aliasing -pipe -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DHAVE_ICONV -Wno-pointer-sign -c /usr/src/bin/csh/../../contrib/tcsh/sh.func.c /usr/src/bin/csh/../../contrib/tcsh/sh.func.c: In function 'iconv_catgets': /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:2371: error: 'ICONV_CONST' undeclared (first use in this function) /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:2371: error: (Each undeclared identifier is reported only once /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:2371: error: for each function it appears in.) /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:2371: error: expected ';' before 'char' /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:2377: error: 'src' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/bin/csh. *** Error code 1 -- Tobias Roth || http://fsck.ch || PGP: 0xCE599B4D | Perfection is achieved not when there is nothing left to add, but | when there is nothing left to remove. | - Antoine de Saint-Exupery From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 10:11:50 2008 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 235C710656A4 for ; Thu, 25 Sep 2008 10:11:50 +0000 (UTC) (envelope-from "cyb."@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 635C08FC2C for ; Thu, 25 Sep 2008 10:11:49 +0000 (UTC) (envelope-from "cyb."@gmx.net) Received: (qmail invoked by alias); 25 Sep 2008 09:45:08 -0000 Received: from pD952E0A8.dip0.t-ipconnect.de (EHLO core2duo.local) [217.82.224.168] by mail.gmx.net (mp014) with SMTP; 25 Sep 2008 11:45:08 +0200 X-Authenticated: #4870692 X-Provags-ID: V01U2FsdGVkX1/1y3dM08z1+wGv51pGvco8UiyHUdvsTSYB6G07zO i0mmKEx4fB2wB4 Date: Thu, 25 Sep 2008 11:45:05 +0200 From: Andreas Rudisch To: Tobias Roth Message-Id: <20080925114505.af589ce3.cyb.@gmx.net> In-Reply-To: <48DB4E11.2060604@fsck.ch> References: <48DB4E11.2060604@fsck.ch> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd6.3) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__25_Sep_2008_11_45_05_+0200_lZS7gxSnDo+CZoko" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Cc: stable@freebsd.org Subject: Re: buildworld fails in csh 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, 25 Sep 2008 10:11:50 -0000 --Signature=_Thu__25_Sep_2008_11_45_05_+0200_lZS7gxSnDo+CZoko Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 25 Sep 2008 10:38:41 +0200 Tobias Roth wrote: > My i386 buildworld with a default make.conf on RELENG_1 RELENG_1? Andreas -- GnuPG key : 0x2A573565 | http://www.gnupg.org/howtos/de/ Fingerprint: 925D 2089 0BF9 8DE5 9166 33BB F0FD CD37 2A57 3565 --Signature=_Thu__25_Sep_2008_11_45_05_+0200_lZS7gxSnDo+CZoko Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjbXaMACgkQ8P3NNypXNWXTCACguMT816G/BsdmwYFnQnvN6VsL EPcAn35gUDRHJLcEJ8BDyXiVtxYB1a2R =CDJB -----END PGP SIGNATURE----- --Signature=_Thu__25_Sep_2008_11_45_05_+0200_lZS7gxSnDo+CZoko-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 10:27:01 2008 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 1F5841065688 for ; Thu, 25 Sep 2008 10:27:01 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id C270D8FC1B for ; Thu, 25 Sep 2008 10:27:00 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from [192.168.0.10] by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kio3l-0002t5-6Z for freebsd-stable@freebsd.org; Thu, 25 Sep 2008 12:26:59 +0200 Message-ID: <48DB6772.1060400@kkip.pl> Date: Thu, 25 Sep 2008 12:26:58 +0200 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.9 X-Spam-Score-Int: -88 X-Exim-Version: 4.69 (build at 26-Jun-2008 18:19:28) X-Date: 2008-09-25 12:26:59 X-Connected-IP: 192.168.0.10:2503 X-Message-Linecount: 37 X-Body-Linecount: 26 X-Message-Size: 941 X-Body-Size: 523 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Subject: vm.kmem_size settings doesn't affect loader? 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, 25 Sep 2008 10:27:01 -0000 Today I've experienced zfs-related kernel panic. Log says: savecore: reboot after panic: kmem_malloc(131072): kmem_map too small: 327684096 total allocated Reported amount of memory (327684096) is wrong, because i made suggested tuning in my loader.conf: vm.kmem_size="512M" vm.kmem_size_max="512M" Just to be sure: # sysctl vm | grep kmem vm.kmem_size: 536870912 vm.kmem_size_min: 0 vm.kmem_size_max: 536870912 vm.kmem_size_scale: 3 Am I missing something? -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 10:49:50 2008 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 119A61065692 for ; Thu, 25 Sep 2008 10:49:50 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [212.103.70.36]) by mx1.freebsd.org (Postfix) with ESMTP id B682C8FC1B for ; Thu, 25 Sep 2008 10:49:49 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from 80-219-162-83.dclient.hispeed.ch ([80.219.162.83] helo=default.fsck.ch) by secure.socket.ch with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KioPp-000FXP-O3; Thu, 25 Sep 2008 12:49:48 +0200 Message-ID: <48DB6CC6.90402@fsck.ch> Date: Thu, 25 Sep 2008 12:49:42 +0200 From: Tobias Roth User-Agent: Thunderbird 2.0.0.16 (X11/20080919) MIME-Version: 1.0 To: Andreas Rudisch <"cyb."@gmx.net> References: <48DB4E11.2060604@fsck.ch> <20080925114505.af589ce3.cyb.@gmx.net> In-Reply-To: <20080925114505.af589ce3.cyb.@gmx.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.4 (---) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 09/25/08 11:45, Andreas Rudisch wrote: > On Thu, 25 Sep 2008 10:38:41 +0200 > Tobias Roth wrote: > >> My i386 buildworld with a default make.conf on RELENG_1 > > RELENG_1? > > Andreas [...] Content analysis details: (-3.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.9 TVD_RCVD_IP TVD_RCVD_IP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.9 AWL AWL: From: address is in the auto white-list X-SA-Exim-Connect-IP: 80.219.162.83 X-SA-Exim-Mail-From: freebsd.lists@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false Cc: stable@freebsd.org Subject: Re: buildworld fails in csh 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, 25 Sep 2008 10:49:50 -0000 On 09/25/08 11:45, Andreas Rudisch wrote: > On Thu, 25 Sep 2008 10:38:41 +0200 > Tobias Roth wrote: > >> My i386 buildworld with a default make.conf on RELENG_1 > > RELENG_1? > > Andreas heh, that should be RELENG_7. -- Tobias Roth || http://fsck.ch || PGP: 0xCE599B4D | A little bit more towards world domination. Can my day get any better? From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 12:49:52 2008 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 7C0AB1065699 for ; Thu, 25 Sep 2008 12:49:52 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 505478FC12 for ; Thu, 25 Sep 2008 12:49:52 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by wa-out-1112.google.com with SMTP id n4so219685wag.27 for ; Thu, 25 Sep 2008 05:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=n4vXtO3d1e9vVH666M2oST1ZUWdEbljFLG8JbocrGxk=; b=t/H7+ZwaWgKx/CA9BfydfVDpTTBk+MhviC/xTMotgI0rIu0i25c04JcpLmdCsQm7up pIncHdBybyzCMlrW/ibcYrIx458uJPlFBXcoe/+DPIJHPenMjJOSM6rhuQ6+cjKOcAjf WIQc8cpv6qBrhzLTe5wbzDmRNjdHUeQ4d8T2Q= 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=VqW0Obsng21Zsg8GyPxyKa4Zx6FFcc3WxqurXz+dX+yrrT+p9BNZKPA+86/4JEqBLC 1oESEA87lMyHIQmr50vxBSa3VqXu+oyeNukojvKqGKqiJYx/zBq+mKh658w5dH86HzX+ MdQ20G7Z4AL8yobXKyKxFPe0ndOgJgnlvvyrg= Received: by 10.114.169.2 with SMTP id r2mr9317220wae.132.1222345654381; Thu, 25 Sep 2008 05:27:34 -0700 (PDT) Received: by 10.114.103.7 with HTTP; Thu, 25 Sep 2008 05:27:34 -0700 (PDT) Message-ID: <790a9fff0809250527r185be90es7d5949e1f61df018@mail.gmail.com> Date: Thu, 25 Sep 2008 07:27:34 -0500 From: "Scot Hetzel" To: "Jeremy Chadwick" In-Reply-To: <20080925035601.GA3158@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080925035601.GA3158@icarus.home.lan> Cc: freebsd-stable@freebsd.org Subject: Re: make-delete-old-libs not removing some libraries 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, 25 Sep 2008 12:49:52 -0000 On 9/24/08, Jeremy Chadwick wrote: > Came across this one tonight. I see this on two separate RELENG_7 > boxes, built at different times (one in August (which shows files > left over from April and May), the other today). > > Both use identical src.conf files. > > The date used in the grep -v is today, immediately after a full system > rebuild (world). > > None of these are being deleted during "make delete-old-libs" (the > aout/ and compat/ directories should probably remain). > > $ ls -l /usr/lib | grep -v '24 Sep' > total 30270 > drwxr-xr-x 2 root wheel 512 7 Sep 04:33 aout/ > drwxr-xr-x 3 root wheel 512 7 Sep 05:40 compat/ > -r--r--r-- 1 root wheel 175488 7 Sep 04:34 libasn1.so.9 > -r--r--r-- 1 root wheel 11248 7 Sep 04:33 libbluetooth.so.3 > -r--r--r-- 1 root wheel 88762 7 Sep 04:33 libgssapi.a > -r--r--r-- 1 root wheel 35184 7 Sep 04:33 libgssapi.so.9 > -r--r--r-- 1 root wheel 62600 7 Sep 04:34 libgssapi_krb5.so.9 > -r--r--r-- 1 root wheel 59368 7 Sep 04:34 libhdb.so.9 > -r--r--r-- 1 root wheel 34872 7 Sep 04:34 libkadm5clnt.so.9 > -r--r--r-- 1 root wheel 55376 7 Sep 04:34 libkadm5srv.so.9 > -r--r--r-- 1 root wheel 20472 7 Sep 04:34 libkafs5.so.9 > -r--r--r-- 1 root wheel 283304 7 Sep 04:34 libkrb5.so.9 > -r--r--r-- 1 root wheel 87278 7 Sep 04:33 libmilter.a > -r--r--r-- 1 root wheel 51248 7 Sep 04:33 libmilter.so.4 > -r--r--r-- 1 root wheel 656420 7 Sep 04:33 libngatm.a > -r--r--r-- 1 root wheel 430512 7 Sep 04:33 libngatm.so.3 > -r--r--r-- 1 root wheel 60320 7 Sep 04:34 libroken.so.9 > -r--r--r-- 1 root wheel 21544 7 Sep 04:34 libsdp.so.3 > -r--r--r-- 1 root wheel 20504 7 Sep 04:34 pam_krb5.so.4 > -r--r--r-- 1 root wheel 9984 7 Sep 04:34 pam_ksu.so.4 > -r--r--r-- 1 root wheel 30032 7 Sep 04:35 snmp_atm.so.5 > > # make delete-old-libs > >>> Removing old libraries > Please be sure no application still uses those libraries, else you > can not start such an application. Consult UPDATING for more > information regarding how to cope with the removal/revision bump > of a specific library. > >>> Old libraries removed > # > > src.conf used: These options need to be filled in with the appropriate files to be removed: > > WITHOUT_ATM=true > WITHOUT_HTML=true > WITHOUT_I4B=true > WITHOUT_LIB32=true > WITHOUT_SENDMAIL=true > See src/tools/build/mk/OptionalObsoleteFiles.inc I had submitted a patch to fill in WITHOUT_LIB32 for 8.0-CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/117191 > WITHOUT_KERBEROS=true > WITHOUT_BLUETOOTH=true On -CURRENT these 2 options haven't been updated to remove the current versions of these libraries. -CURRENT will remove the old KERBEROS version .9 libraries from src/ObsoleteFiles.inc, but it doesn't remove the current KERBEROS libraries from src/tools/build/mk/OptionalObsoleteFiles.inc, as the libraries are still listed as version 8 instead of 10. Check src/tools/build/mk/OptionalObsoleteFiles.inc to make sure it is removing the current libraries for RELENG_7. Check src/ObsoleteFiles.inc to make sure it is removing the old libraries for RELENG_7. Scot From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 13:02:29 2008 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 D90091065687 for ; Thu, 25 Sep 2008 13:02:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 85D008FC14 for ; Thu, 25 Sep 2008 13:02:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA08.westchester.pa.mail.comcast.net with comcast id JzKN1a0050cZkys5812UKT; Thu, 25 Sep 2008 13:02:28 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA10.westchester.pa.mail.comcast.net with comcast id K12T1a00H4v8bD73W12Uow; Thu, 25 Sep 2008 13:02:28 +0000 X-Authority-Analysis: v=1.0 c=1 a=pl5uMaLHwrUA:10 a=20ZdTaP2r60A:10 a=QycZ5dHgAAAA:8 a=2K62Y4ObiraUMsvz2mgA:9 a=ZNjc19_zAArgglB7i6uqxxf7ajsA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 3C13DC9419; Thu, 25 Sep 2008 06:02:27 -0700 (PDT) Date: Thu, 25 Sep 2008 06:02:27 -0700 From: Jeremy Chadwick To: Bartosz Stec Message-ID: <20080925130227.GA13497@icarus.home.lan> References: <48DB6772.1060400@kkip.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DB6772.1060400@kkip.pl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 25 Sep 2008 13:02:29 -0000 On Thu, Sep 25, 2008 at 12:26:58PM +0200, Bartosz Stec wrote: > > > Today I've experienced zfs-related kernel panic. Log says: > > savecore: reboot after panic: kmem_malloc(131072): kmem_map too > small: 327684096 total allocated > > Reported amount of memory (327684096) is wrong, because i made suggested > tuning in my loader.conf: > > vm.kmem_size="512M" > vm.kmem_size_max="512M" > > Just to be sure: > > # sysctl vm | grep kmem > vm.kmem_size: 536870912 > vm.kmem_size_min: 0 > vm.kmem_size_max: 536870912 > vm.kmem_size_scale: 3 > > Am I missing something? I believe this is normal. The amount shown in "total allocated" will not match what you have vm.kmem_size or vm.kmem_size_max set to. Someone more familiar with the VM can explain why this is, but as I understand it, it's 100% normal. Your options are: 1) Consider increasing it from 512M to something like 1.5GB; do not increase it past that on RELENG_7, as there isn't support for more than 2GB total. For example, on a 1GB memory machine, I often recommend 768M. On 2GB machines, 1536M. You will need to run -CURRENT if you want more. 2) Tune ZFS aggressively. Start by setting vfs.zfs.arc_min="16M" and vfs.zfs.arc_max="64M". If your machine has some small amount of memory (768MB, 1GB, etc.), then you probably shouldn't be using ZFS. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 13:14:18 2008 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 47603106569F for ; Thu, 25 Sep 2008 13:14:18 +0000 (UTC) (envelope-from "cyb."@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 8761E8FC17 for ; Thu, 25 Sep 2008 13:14:17 +0000 (UTC) (envelope-from "cyb."@gmx.net) Received: (qmail invoked by alias); 25 Sep 2008 13:14:15 -0000 Received: from pD952E0A8.dip0.t-ipconnect.de (EHLO core2duo.local) [217.82.224.168] by mail.gmx.net (mp017) with SMTP; 25 Sep 2008 15:14:15 +0200 X-Authenticated: #4870692 X-Provags-ID: V01U2FsdGVkX1+NosVx8qeNjli2MmkfL9VBEb/qmcEbgkxBtMcL2W vpUpKy7AqFBJZK Date: Thu, 25 Sep 2008 15:14:11 +0200 From: Andreas Rudisch To: Tobias Roth Message-Id: <20080925151411.5c0c4d0a.cyb.@gmx.net> In-Reply-To: <48DB6CC6.90402@fsck.ch> References: <48DB4E11.2060604@fsck.ch> <20080925114505.af589ce3.cyb.@gmx.net> <48DB6CC6.90402@fsck.ch> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd6.3) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__25_Sep_2008_15_14_11_+0200_COWwtnEsOQHgW_Dw" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: stable@freebsd.org Subject: Re: buildworld fails in csh 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, 25 Sep 2008 13:14:18 -0000 --Signature=_Thu__25_Sep_2008_15_14_11_+0200_COWwtnEsOQHgW_Dw Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 25 Sep 2008 12:49:42 +0200 Tobias Roth wrote: > heh, that should be RELENG_7. Update your source tree again and clean up the build dirs. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#Q2= 3.4.14.6. Could be caused by some left overs from a previous build. Andreas -- GnuPG key : 0x2A573565 | http://www.gnupg.org/howtos/de/ Fingerprint: 925D 2089 0BF9 8DE5 9166 33BB F0FD CD37 2A57 3565 --Signature=_Thu__25_Sep_2008_15_14_11_+0200_COWwtnEsOQHgW_Dw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjbjqUACgkQ8P3NNypXNWUzhQCdFoslRU+mQN5D7k33OWckHrAc a2sAnAr210Nci2Blbe/9NePcEoKKmiwW =cJCh -----END PGP SIGNATURE----- --Signature=_Thu__25_Sep_2008_15_14_11_+0200_COWwtnEsOQHgW_Dw-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 13:29:44 2008 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 62BA71065687 for ; Thu, 25 Sep 2008 13:29:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0803A8FC1F for ; Thu, 25 Sep 2008 13:29:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8PDTWLV095309; Thu, 25 Sep 2008 09:29:38 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 25 Sep 2008 08:25:19 -0400 User-Agent: KMail/1.9.7 References: <48DB6772.1060400@kkip.pl> In-Reply-To: <48DB6772.1060400@kkip.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809250825.19757.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Thu, 25 Sep 2008 09:29:38 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8329/Thu Sep 25 04:47:46 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Bartosz Stec Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 25 Sep 2008 13:29:44 -0000 On Thursday 25 September 2008 06:26:58 am Bartosz Stec wrote: > > Today I've experienced zfs-related kernel panic. Log says: > > savecore: reboot after panic: kmem_malloc(131072): kmem_map too > small: 327684096 total allocated > > Reported amount of memory (327684096) is wrong, because i made suggested > tuning in my loader.conf: > > vm.kmem_size="512M" > vm.kmem_size_max="512M" > > Just to be sure: > > # sysctl vm | grep kmem > vm.kmem_size: 536870912 > vm.kmem_size_min: 0 > vm.kmem_size_max: 536870912 > vm.kmem_size_scale: 3 > > Am I missing something? If kvm is fragmented you could have a malloc fail even if there are enough total free bytes for the allocatoin. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 14:14:10 2008 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 1D5711065696 for ; Thu, 25 Sep 2008 14:14:10 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id B541B8FC1D for ; Thu, 25 Sep 2008 14:14:09 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from [192.168.0.10] by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KirbW-00047i-Ex for freebsd-stable@freebsd.org; Thu, 25 Sep 2008 16:14:07 +0200 Message-ID: <48DB9CAA.9060807@kkip.pl> Date: Thu, 25 Sep 2008 16:14:02 +0200 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <48DB6772.1060400@kkip.pl> <20080925130227.GA13497@icarus.home.lan> In-Reply-To: <20080925130227.GA13497@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.9 X-Spam-Score-Int: -88 X-Exim-Version: 4.69 (build at 26-Jun-2008 18:19:28) X-Date: 2008-09-25 16:14:07 X-Connected-IP: 192.168.0.10:4011 X-Message-Linecount: 84 X-Body-Linecount: 71 X-Message-Size: 3328 X-Body-Size: 2772 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 25 Sep 2008 14:14:10 -0000 Jeremy Chadwick pisze: > On Thu, Sep 25, 2008 at 12:26:58PM +0200, Bartosz Stec wrote: > >> Today I've experienced zfs-related kernel panic. Log says: >> >> savecore: reboot after panic: kmem_malloc(131072): kmem_map too >> small: 327684096 total allocated >> >> Reported amount of memory (327684096) is wrong, because i made suggested >> tuning in my loader.conf: >> >> vm.kmem_size="512M" >> vm.kmem_size_max="512M" >> >> Just to be sure: >> >> # sysctl vm | grep kmem >> vm.kmem_size: 536870912 >> vm.kmem_size_min: 0 >> vm.kmem_size_max: 536870912 >> vm.kmem_size_scale: 3 >> >> Am I missing something? >> > > I believe this is normal. The amount shown in "total allocated" will > not match what you have vm.kmem_size or vm.kmem_size_max set to. > Someone more familiar with the VM can explain why this is, but as I > understand it, it's 100% normal. > Thanks for explaining. This part of tuning guide confused me: "I was able to generate the following kernel panic in less than a minute by copying files from a linux server connected via gigabit crossover: Apr 8 06:46:08 nas savecore: reboot after panic: kmem_malloc(131072): kmem_map too small: 528273408 total allocated As you can see, this is *with* vm.kmem_size="512M"!" I've just expected similiar numbers in my case. > Your options are: > > 1) Consider increasing it from 512M to something like 1.5GB; do not > increase it past that on RELENG_7, as there isn't support for more than > 2GB total. For example, on a 1GB memory machine, I often recommend > 768M. On 2GB machines, 1536M. You will need to run -CURRENT if you > want more. > > 2) Tune ZFS aggressively. Start by setting vfs.zfs.arc_min="16M" > and vfs.zfs.arc_max="64M". > > If your machine has some small amount of memory (768MB, 1GB, etc.), > then you probably shouldn't be using ZFS. > > Problem occured on i386 machine with 1GB of memory and 7.1-pre (3HDD, 40GB, RAIDZ1). I know that i386 is highly unrecommended for ZFS, but it's just a home box for testing and learning purposes - I just want to know what I'm doing and what should I expect when I decide to put ZFS on server machines :) Currently, from posts on freebsd-fs, I conclude that even with a gigs of kmem and using AMD64, we still can experience panic from kmem_malloc. Manual tuning is hard for me because I'm not familiar with BSD kernel code nor kernel memory management. I'm just an end-user who love concepts of ZFS and wait for it to be (more) stable. Of course I've followed tuning guide carefully. So, for now, I will add another 512MB of memory and increse vm.kmem_size and do more tests. Thanks once again for explaining and suggestions. Good luck with ZFS everyone! :) -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 14:22:50 2008 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 5B3B5106569B for ; Thu, 25 Sep 2008 14:22:50 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 11FB18FC1C for ; Thu, 25 Sep 2008 14:22:50 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id EA63D19E02D; Thu, 25 Sep 2008 16:22:48 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id C4B9019E027; Thu, 25 Sep 2008 16:22:43 +0200 (CEST) Message-ID: <48DB9ED4.408@quip.cz> Date: Thu, 25 Sep 2008 16:23:16 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Jo Rhett References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> In-Reply-To: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Stable Subject: Re: proposed change to support policy for FreeBSD Releases 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, 25 Sep 2008 14:22:50 -0000 Jo Rhett wrote: > Some quite lively offline discussion has come to conclusion with the > following suggestions to change the support policy. Obviously, this is > what we feel would be a good idea, but it's obviously open to > discussion and there's nobody demanding anything here. It just seems > "better". [...snip...] > > Note2: This new policy would not change the support period for 6.4 if > it is the final release, but it does completely resolve the need to > "guess" whether or not it will be the final release. > > The notable change that I believe will encourage business participation > in the testing/evaluation process is that 6.4 is guaranteed to be > supported either 24 months, or at least 6 months past the release date > of 6.5. (recent history suggests this would be 15-19 months). This > encourages businesses to test and evaluate 6.4 NOW, rather than waiting > until a decision about the support policy is made. > > Repeat from the top: nobody is demanding anything. I think this policy > would make a lot more sense, and would promote forward movement. Feel > free to correct me if we overlooked anything. Thanks. I read the whole thread about releases schedule and I second your proposed changes. It makes things clear to me and I'll be happy if this concept will be accepted by FreeBSD team. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 14:51:56 2008 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 4143A1065692 for ; Thu, 25 Sep 2008 14:51:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 25DCF8FC1F for ; Thu, 25 Sep 2008 14:51:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id JzRW1a00J17UAYkA12rdgk; Thu, 25 Sep 2008 14:51:37 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id K2ru1a0084v8bD78Z2ruVK; Thu, 25 Sep 2008 14:51:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=pl5uMaLHwrUA:10 a=20ZdTaP2r60A:10 a=QycZ5dHgAAAA:8 a=E0mws_dX3nLwywMrpwMA:9 a=Nb8y8zYARSa-ScBy8pEoeovNRCEA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 226E9C9419; Thu, 25 Sep 2008 07:51:54 -0700 (PDT) Date: Thu, 25 Sep 2008 07:51:54 -0700 From: Jeremy Chadwick To: Bartosz Stec Message-ID: <20080925145154.GA15486@icarus.home.lan> References: <48DB6772.1060400@kkip.pl> <20080925130227.GA13497@icarus.home.lan> <48DB9CAA.9060807@kkip.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DB9CAA.9060807@kkip.pl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 25 Sep 2008 14:51:56 -0000 On Thu, Sep 25, 2008 at 04:14:02PM +0200, Bartosz Stec wrote: >> Your options are: >> >> 1) Consider increasing it from 512M to something like 1.5GB; do not >> increase it past that on RELENG_7, as there isn't support for more than >> 2GB total. For example, on a 1GB memory machine, I often recommend >> 768M. On 2GB machines, 1536M. You will need to run -CURRENT if you >> want more. >> >> 2) Tune ZFS aggressively. Start by setting vfs.zfs.arc_min="16M" >> and vfs.zfs.arc_max="64M". >> >> If your machine has some small amount of memory (768MB, 1GB, etc.), >> then you probably shouldn't be using ZFS. >> >> > Problem occured on i386 machine with 1GB of memory and 7.1-pre (3HDD, > 40GB, RAIDZ1). I know that i386 is highly unrecommended for ZFS, but > it's just a home box for testing and learning purposes - I just want to > know what I'm doing and what should I expect when I decide to put ZFS on > server machines :) Currently, from posts on freebsd-fs, I conclude that > even with a gigs of kmem and using AMD64, we still can experience panic > from kmem_malloc. The i386 vs. amd64 argument is bogus, if you ask me. ZFS works on both. amd64 is recommended because ZFS contains code that makes heavy use of 64-bit values, and because amd64 offers large amounts of addressed memory without disgusting hacks like PAE. That said -- yes, even with "gigs of kmem and using AMD64", you can still panic due to kmem exhaustion. I have fairly decent experience with this problem, because it haunted me for quite some time. A large portion of the problem is that kmem_max, on i386 and amd64 (yes, you read that right) has a 2GB limit on RELENG_7. I repeat: a 2GB limit, regardless of i386 or amd64. This limit has been increased to 512GB on CURRENT, but there are no plans to MFC those changes, as they are too major. Let me tell you something I did this weekend. I had to copy literally 200GB of data from a ZFS raidz1 pool (spread across 3 disks) to two different places: 1) a UFS2 filesystem on a different disk, and 2) across a gigE network to a Windows machine. I had to do this because I was adding a disk to the vdev, which cannot be done without re-creating the pool (this is a known problem with ZFS, and has nothing to do with FreeBSD). The machine hosting the data runs RELENG_7 with amd64, and contains 4GB of memory. However, I've accomplished the same task with only 2GB of memory as well. These are the tuning settings I use: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="64M" The entire copying process took almost 2 hours. Not once did I experience kmem exhaustion. I can *guarantee* that I would have crashed the box numerous times had I not tuned the machine with the values above. > Manual tuning is hard for me because I'm not familiar > with BSD kernel code nor kernel memory management. I'm just an end-user > who love concepts of ZFS and wait for it to be (more) stable. Of course > I've followed tuning guide carefully. I'm an "experienced" end-user who has very little experience with BSD kernel code and absolutely no experience with kernel memory management. Proper tuning is all that's needed, regardless of your knowledge set. Please try installing 2GB of memory in your i386 box, and then use the exact loader.conf values I specified above. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 14:53:26 2008 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 C25F11065686 for ; Thu, 25 Sep 2008 14:53:26 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 430C48FC19 for ; Thu, 25 Sep 2008 14:53:26 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by ey-out-2122.google.com with SMTP id 6so132363eyi.7 for ; Thu, 25 Sep 2008 07:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer; bh=kaRCARJYoWSbnKhTAAG36YHJoojCPzEbLxrX0iinQto=; b=dhe97UB0wh4AQgt5zhXB+IgIkQm5tW3eizodiAgcpgGlSYAW6MJC1Gghdv7V43wclx +ldP1TzRM4z+UkSlq2lIbJsW3WQQ9+bevcWVMjgYoqShRTzijNKvlpX/bkzzEmqC2T9H cPS1+mzYz8qiaaB/dZRjVrzHBcfK4X8AHa61k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; b=CL0B2wrPR0dtleKum5+lf0K5aQy2HkY0I14vdW6CqSwz8QHhKlRTuXJkhks+GXqzrB Fg36RgBWdcaX/vbpsop6h70ujPJov1bmHcaIPUr/T8gG5SsXMx7di58lkQEt7rDlV1X1 qqkbcD2KZkHKsI4XuaybB3cOp4yJHpCeeSwVA= Received: by 10.210.90.8 with SMTP id n8mr10290837ebb.128.1222354404728; Thu, 25 Sep 2008 07:53:24 -0700 (PDT) Received: from ?127.0.0.1? ( [217.206.187.80]) by mx.google.com with ESMTPS id f13sm604434gvd.10.2008.09.25.07.53.22 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Sep 2008 07:53:23 -0700 (PDT) From: Tom Evans To: Jo Rhett In-Reply-To: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-T0n7tSOCXynZtSpUAABe" Date: Thu, 25 Sep 2008 15:53:21 +0100 Message-Id: <1222354401.2443.46.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Cc: freebsd-stable Stable Subject: Re: proposed change to support policy for FreeBSD Releases 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, 25 Sep 2008 14:53:26 -0000 --=-T0n7tSOCXynZtSpUAABe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-09-23 at 13:37 -0700, Jo Rhett wrote: > Some quite lively offline discussion has come to conclusion with the =20 > following suggestions to change the support policy. Obviously, this =20 > is what we feel would be a good idea, but it's obviously open to =20 > discussion and there's nobody demanding anything here. It just seems =20 > "better". >=20 > Old text: > > Each branch is supported by the Security Officer for a limited time =20 > > only, and is designated as one of `Early adopter', `Normal', or =20 > > `Extended'. The designation is used as a guideline for determining =20 > > the lifetime of the branch as follows. > > > > Early adopter > > Releases which are published from the -CURRENT branch will be =20 > > supported by the Security Officer for a minimum of 6 months after =20 > > the release. > > Normal > > Releases which are published from a -STABLE branch will be =20 > > supported by the Security Officer for a minimum of 12 months after =20 > > the release. > > Extended > > Selected releases will be supported by the Security Officer for =20 > > a minimum of 24 months after the release. >=20 > Proposed (starting point for discussion for) new text: >=20 > Each branch is supported by the Security Officer for a limited time =20 > only, and is designated as one of `Early adopter', `Normal', or =20 > 'Final'. The designation is used as a guideline for determining the =20 > lifetime of the branch as follows. >=20 > Early adopter > Releases which are published from the -CURRENT branch will be =20 > supported by the Security Officer for a minimum of 6 months after the =20 > release. >=20 >=20 > Normal > Releases which are published from a -STABLE branch will be =20 > supported by the Security Officer for a minimum of 12 months after the =20 > release. > A release which is not the final minor release of a branch will =20 > be additionally supported by a minimum of 6 months past the release =20 > date of the succeeding version. For example X.1 will be supported for =20 > 12 months or until 6 months past the release date of X.2, whichever =20 > comes later. >=20 > Final > The final minor release on a given branch will be supported by =20 > the Security Officer for a minimum of 24 months after the release. >=20 >=20 > OBSERVATIONS: >=20 > 1. This avoids the need for the well-documented chicken-and-egg =20 > problem of trying to guess which release is the final release. >=20 > 2. This is a consistent policy in line with many other vendor policies. >=20 > 3. This rewards forward movement in the branch. >=20 > And finally, as I've done the match carefully, >=20 > 4. It would appear to *reduce* rather than enlarge the support =20 > requirements for the security team. Unless a minor release comes out =20 > less than 6 months after a previous release, only two versions would =20 > ever be supported at the same time. In recent history 3 minor =20 > releases in the same branch have been supported more often than not. >=20 > Example under current policy: >=20 > 6.5 comes out in July of 2009. For July -> October the security team =20 > will need to support 3 releases: 6.3, 6.4 and 6.5. From November =20 > 2009 through January 2010 the security team will need to support 6.3 =20 > and 6.5, but not 6.4. >=20 > Revised under the existing policy: >=20 > Support for 6.3 expires in April of 2009. (more than 12 months past =20 > release and 6 months after the release of 6.4). Support for 6.4 =20 > expires in January of 2010. Support for 6.5 would expire in July of =20 > 2011 or 6 months after the release of 6.6. >=20 > ^NOTE: this example is probably unfeasible since 6.3 already has a =20 > published support period ended in January 2010, but this will prevent =20 > a similar occurrence happening in future releases. >=20 > Note2: This new policy would not change the support period for 6.4 if =20 > it is the final release, but it does completely resolve the need to =20 > "guess" whether or not it will be the final release. >=20 > The notable change that I believe will encourage business =20 > participation in the testing/evaluation process is that 6.4 is =20 > guaranteed to be supported either 24 months, or at least 6 months past =20 > the release date of 6.5. (recent history suggests this would be =20 > 15-19 months). This encourages businesses to test and evaluate 6.4 =20 > NOW, rather than waiting until a decision about the support policy is =20 > made. >=20 > Repeat from the top: nobody is demanding anything. I think this =20 > policy would make a lot more sense, and would promote forward =20 > movement. Feel free to correct me if we overlooked anything. Thanks. >=20 Isn't this a non-pragmatic way of looking at this? Currently, as long as there are no serious issues with 6.4, 6.4 will be supported for 24 months from release. This is abundantly clear from both prior history and what secteam say.=20 If there are serious issues, then 6.5 will be cut to address these issues, and it would be a release to address these issues. In this case, the 'only 12 month support' is irrelevant; one would want to migrate these machines to 6.5. One might argue that this isn't something that can be planned for by a user; I would argue that planning for unexpected, serious problems is something that has to be done for every deployed machine. Extended support is great for point-1 releases, so we can acclimatise to a new major branch with the benefit that no major functional changes will jump in. To my mind, this entire discussion is bikeshed painting that ends up with semantic arguing about what a 'final' release is. Cheers Tom --=-T0n7tSOCXynZtSpUAABe Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkjbpd4ACgkQlcRvFfyds/czVwCfX5sR3x/AU3igHDCC/HxymfCB QioAoIhs1isUlL4w/x8M7rcua41jkn5G =Cgwx -----END PGP SIGNATURE----- --=-T0n7tSOCXynZtSpUAABe-- From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 15:10:14 2008 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 4C19A106568F; Thu, 25 Sep 2008 15:10:14 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 1187F8FC36; Thu, 25 Sep 2008 15:10:14 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KisTn-000GCW-Cz; Thu, 25 Sep 2008 16:10:07 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KisTn-0000xy-AG; Thu, 25 Sep 2008 16:10:07 +0100 To: admin@kkip.pl, koitsu@FreeBSD.org In-Reply-To: <20080925145154.GA15486@icarus.home.lan> Message-Id: From: Pete French Date: Thu, 25 Sep 2008 16:10:07 +0100 Cc: freebsd-stable@freebsd.org Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 25 Sep 2008 15:10:14 -0000 > These are the tuning settings I use: > > vm.kmem_size="1536M" > vm.kmem_size_max="1536M" > vfs.zfs.arc_min="16M" > vfs.zfs.arc_max="64M" > > The entire copying process took almost 2 hours. Not once did I > experience kmem exhaustion. I can *guarantee* that I would have crashed > the box numerous times had I not tuned the machine with the values > above. I am interested in the last two values you have there - I also use ZFS and tune to prevent memory exhaustion. I tune kmem_size, but I have not bothered toi set the arc_min - and the default appears to be 16M anyway. The arc_max value I do set, but I got dreadful performance when I had it at 6M, so I upped it to 128M. This has not resulted in any panics, and gives much better performance. As I understand it there is only one ARC, and it comes from kernel space too, so setting it to an extra 64 meg should not use that much more memory, yes ? My setup is: vm.kmem_size="1024M" vm.kmem_size_max="1024M" vfs.zfs.arc_max="128M" vfs.zfs.prefetch_disable=1 This is on a 2gb amd64 machine, and works beautifully, with no out of memory errors and panics. I have been trying to panic this for a few days. I will probably chnage the kmem size to 1536 which is what I use on other machines though. -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 15:14:09 2008 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 58A001065693 for ; Thu, 25 Sep 2008 15:14:09 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id E78AD8FC12 for ; Thu, 25 Sep 2008 15:14:08 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: by gxk10 with SMTP id 10so7079937gxk.19 for ; Thu, 25 Sep 2008 08:14:08 -0700 (PDT) Received: by 10.64.251.17 with SMTP id y17mr15371733qbh.10.1222355647640; Thu, 25 Sep 2008 08:14:07 -0700 (PDT) Received: from kevin ( [76.10.166.187]) by mx.google.com with ESMTPS id p30sm957115qbp.14.2008.09.25.08.14.05 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Sep 2008 08:14:06 -0700 (PDT) From: "Kevin" To: Date: Thu, 25 Sep 2008 11:13:52 -0400 Message-ID: <002901c91f21$52a90440$f7fb0cc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckfIVD7HO2vmCbHROSgfJ8s2KQ5Qg== Content-Language: en-us x-cr-hashedpuzzle: caM= ByDc B0hV C5x4 EHZm Ev9J FMIJ Flk2 GPqV GrDH HN60 IIli IJfH IKsk ILP7 I5zV; 1; ZgByAGUAZQBiAHMAZAAtAHMAdABhAGIAbABlAEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnAA==; Sosha1_v1; 7; {2C82063A-60D8-4A07-8939-F1EF762D7ABC}; awBAAGsAZQB2AGkAbgBrAGUAdgBpAG4ALgBjAG8AbQA=; Thu, 25 Sep 2008 15:13:51 GMT; TQBhAGsAZQAgAGIAdQBpAGwAZABrAGUAcgBuAGUAbAAgAGYAYQBpAGwAcwA= x-cr-puzzleid: {2C82063A-60D8-4A07-8939-F1EF762D7ABC} Subject: Make buildkernel fails 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, 25 Sep 2008 15:14:09 -0000 # uname -a FreeBSD ck.com 7.0-STABLE FreeBSD 7.0-STABLE #1: Tue Jul 15 11:38:41 EDT 2008 ck@friendlybearonskates.com:/usr/obj/usr/src/sys/CK i386 # Make buildkernel kernconf=CK fails here : linking kernel.debug sbp.o(.text+0xd9d): In function `sbp_free_ocb': /usr/src/sys/dev/firewire/sbp.c:2905: undefined reference to `xpt_release_devq' sbp.o(.text+0x123e): In function `sbp_abort_all_ocbs': /usr/src/sys/dev/firewire/sbp.c:2939: undefined reference to `xpt_done' sbp.o(.text+0x1377): In function `sbp_cam_detach_sdev': /usr/src/sys/dev/firewire/sbp.c:2204: undefined reference to `xpt_release_devq' sbp.o(.text+0x1398):/usr/src/sys/dev/firewire/sbp.c:2207: undefined reference to `xpt_async' sbp.o(.text+0x13a3):/usr/src/sys/dev/firewire/sbp.c:2208: undefined reference to `xpt_free_path' sbp.o(.text+0x15b3): In function `sbp_cam_scan_lun': /usr/src/sys/dev/firewire/sbp.c:1027: undefined reference to `xpt_setup_ccb' sbp.o(.text+0x15be):/usr/src/sys/dev/firewire/sbp.c:1029: undefined reference to `xpt_action' sbp.o(.text+0x15d9):/usr/src/sys/dev/firewire/sbp.c:1030: undefined reference to `xpt_release_devq' sbp.o(.text+0x2000): In function `sbp_post_explore': /usr/src/sys/dev/firewire/sbp.c:744: undefined reference to `xpt_freeze_devq' sbp.o(.text+0x2266):/usr/src/sys/dev/firewire/sbp.c:779: undefined reference to `xpt_freeze_devq' sbp.o(.text+0x2365):/usr/src/sys/dev/firewire/sbp.c:888: undefined reference to `xpt_release_simq' sbp.o(.text+0x2460): In function `sbp_post_busreset': /usr/src/sys/dev/firewire/sbp.c:810: undefined reference to `xpt_freeze_simq' sbp.o(.text+0x265a): In function `sbp_cam_scan_target': /usr/src/sys/dev/firewire/sbp.c:1056: undefined reference to `xpt_setup_ccb' sbp.o(.text+0x26cb):/usr/src/sys/dev/firewire/sbp.c:1065: undefined reference to `xpt_action' sbp.o(.text+0x26e6):/usr/src/sys/dev/firewire/sbp.c:1066: undefined reference to `xpt_release_devq' sbp.o(.text+0x2820): In function `sbp_timeout': /usr/src/sys/dev/firewire/sbp.c:2303: undefined reference to `xpt_freeze_devq' sbp.o(.text+0x2943):/usr/src/sys/dev/firewire/sbp.c:2245: undefined reference to `xpt_freeze_devq' sbp.o(.text+0x2ba7): In function `sbp_agent_reset_callback': /usr/src/sys/dev/firewire/sbp.c:1132: undefined reference to `xpt_release_devq' sbp.o(.text+0x2cb7): In function `sbp_detach': /usr/src/sys/dev/firewire/sbp.c:2169: undefined reference to `xpt_async' sbp.o(.text+0x2cc2):/usr/src/sys/dev/firewire/sbp.c:2170: undefined reference to `xpt_free_path' sbp.o(.text+0x2cd0):/usr/src/sys/dev/firewire/sbp.c:2171: undefined reference to `xpt_bus_deregister' sbp.o(.text+0x2ce3):/usr/src/sys/dev/firewire/sbp.c:2172: undefined reference to `cam_sim_free' sbp.o(.text+0x2f38): In function `sbp_attach': /usr/src/sys/dev/firewire/sbp.c:2014: undefined reference to `cam_simq_alloc' sbp.o(.text+0x2fb4):/usr/src/sys/dev/firewire/sbp.c:2023: undefined reference to `cam_sim_alloc' sbp.o(.text+0x2fc3):/usr/src/sys/dev/firewire/sbp.c:2031: undefined reference to `cam_simq_free' sbp.o(.text+0x302c):/usr/src/sys/dev/firewire/sbp.c:2036: undefined reference to `xpt_bus_register' sbp.o(.text+0x3056):/usr/src/sys/dev/firewire/sbp.c:2039: undefined reference to `xpt_periph' sbp.o(.text+0x3062):/usr/src/sys/dev/firewire/sbp.c:2039: undefined reference to `xpt_create_path' sbp.o(.text+0x3075):/usr/src/sys/dev/firewire/sbp.c:2041: undefined reference to `xpt_bus_deregister' sbp.o(.text+0x31cf):/usr/src/sys/dev/firewire/sbp.c:2067: undefined reference to `xpt_async' sbp.o(.text+0x327a):/usr/src/sys/dev/firewire/sbp.c:2073: undefined reference to `cam_sim_free' sbp.o(.text+0x359e): In function `sbp_do_attach': /usr/src/sys/dev/firewire/sbp.c:1096: undefined reference to `xpt_periph' sbp.o(.text+0x35aa):/usr/src/sys/dev/firewire/sbp.c:1096: undefined reference to `xpt_create_path' sbp.o(.text+0x38e7): In function `sbp_orb_pointer': /usr/src/sys/dev/firewire/sbp.c:1261: undefined reference to `xpt_done' sbp.o(.text+0x407b): In function `sbp_recv': /usr/src/sys/dev/firewire/sbp.c:1791: undefined reference to `xpt_freeze_devq' sbp.o(.text+0x4722):/usr/src/sys/dev/firewire/sbp.c:1902: undefined reference to `xpt_done' sbp.o(.text+0x4c4b): In function `sbp_action': /usr/src/sys/dev/firewire/sbp.c:2371: undefined reference to `xpt_done' sbp.o(.text+0x4cb1):/usr/src/sys/dev/firewire/sbp.c:2391: undefined reference to `xpt_done' sbp.o(.text+0x4e52):/usr/src/sys/dev/firewire/sbp.c:2434: undefined reference to `xpt_done' sbp.o(.text+0x4ee2):/usr/src/sys/dev/firewire/sbp.c:2454: undefined reference to `xpt_freeze_devq' sbp.o(.text+0x4f3d):/usr/src/sys/dev/firewire/sbp.c:2458: undefined reference to `xpt_done' sbp.o(.text+0x50da):/usr/src/sys/dev/firewire/sbp.c:2522: undefined reference to `xpt_done' sbp.o(.text+0x515f):/usr/src/sys/dev/firewire/sbp.c:2556: undefined reference to `cam_calc_geometry' sbp.o(.text+0x5167):/usr/src/sys/dev/firewire/sbp.c:2558: undefined reference to `xpt_done' sbp.o(.text+0x51ab):/usr/src/sys/dev/firewire/sbp.c:2570: undefined reference to `xpt_done' sbp.o(.text+0x52d5):/usr/src/sys/dev/firewire/sbp.c:2602: undefined reference to `xpt_done' sbp.o(.text+0x536c):/usr/src/sys/dev/firewire/sbp.c:2627: undefined reference to `xpt_done' sbp.o(.text+0x537d):/usr/src/sys/dev/firewire/sbp.c:2632: undefined reference to `xpt_done' sbp.o(.text+0x538e):/usr/src/sys/dev/firewire/sbp.c:2638: more undefined references to `xpt_done' follow if_ural.o(.text+0x743): In function `ural_free_tx_list': /usr/src/sys/dev/usb/if_ural.c:627: undefined reference to `ieee80211_free_node' if_ural.o(.text+0x93a): In function `ural_detach': /usr/src/sys/dev/usb/if_ural.c:567: undefined reference to `ieee80211_ifdetach' if_ural.o(.text+0xe1c): In function `ural_attach': /usr/src/sys/dev/usb/if_ural.c:499: undefined reference to `ieee80211_init_channels' if_ural.o(.text+0xe24):/usr/src/sys/dev/usb/if_ural.c:501: undefined reference to `ieee80211_ifattach' if_ural.o(.text+0xe7e):/usr/src/sys/dev/usb/if_ural.c:513: undefined reference to `ieee80211_media_status' if_ural.o(.text+0xe8e):/usr/src/sys/dev/usb/if_ural.c:513: undefined reference to `ieee80211_media_init' if_ural.o(.text+0xeb0):/usr/src/sys/dev/usb/if_ural.c:515: undefined reference to `ieee80211_amrr_init' if_ural.o(.text+0xf22):/usr/src/sys/dev/usb/if_ural.c:531: undefined reference to `ieee80211_announce' if_ural.o(.text+0x1152): In function `ural_raw_xmit': /usr/src/sys/dev/usb/if_ural.c:2402: undefined reference to `ieee80211_free_node' if_ural.o(.text+0x1181):/usr/src/sys/dev/usb/if_ural.c:2408: undefined reference to `ieee80211_free_node' if_ural.o(.text+0x13b5):/usr/src/sys/dev/usb/if_ural.c:2438: undefined reference to `ieee80211_free_node' if_ural.o(.text+0x15b9): In function `ural_set_chan': /usr/src/sys/dev/usb/if_ural.c:1823: undefined reference to `ieee80211_chan2ieee' if_ural.o(.text+0x1c5d): In function `ural_start': /usr/src/sys/dev/usb/if_ural.c:1461: undefined reference to `ieee80211_free_node' if_ural.o(.text+0x1f13):/usr/src/sys/dev/usb/if_ural.c:1479: undefined reference to `ieee80211_cancel_scan' if_ural.o(.text+0x1f42):/usr/src/sys/dev/usb/if_ural.c:1486: undefined reference to `ieee80211_find_txnode' if_ural.o(.text+0x1f87):/usr/src/sys/dev/usb/if_ural.c:1493: undefined reference to `ieee80211_encap' if_ural.o(.text+0x1f98):/usr/src/sys/dev/usb/if_ural.c:1495: undefined reference to `ieee80211_free_node' if_ural.o(.text+0x1ff5):/usr/src/sys/dev/usb/if_ural.c:1366: undefined reference to `ieee80211_crypto_encap' if_ural.o(.text+0x21e5):/usr/src/sys/dev/usb/if_ural.c:1503: undefined reference to `ieee80211_free_node' if_ural.o(.text+0x227a): In function `ural_txeof': /usr/src/sys/dev/usb/if_ural.c:882: undefined reference to `ieee80211_process_callback' if_ural.o(.text+0x2309):/usr/src/sys/dev/usb/if_ural.c:901: undefined reference to `ieee80211_free_node' if_ural.o(.text+0x2b89): In function `ural_amrr_update': /usr/src/sys/dev/usb/if_ural.c:2508: undefined reference to `ieee80211_amrr_choose' if_ural.o(.text+0x2c7b): In function `ural_media_change': /usr/src/sys/dev/usb/if_ural.c:705: undefined reference to `ieee80211_media_change' if_ural.o(.text+0x2e26): In function `ural_ioctl': /usr/src/sys/dev/usb/if_ural.c:1578: undefined reference to `ieee80211_ioctl' if_ural.o(.text+0x309a): In function `ural_task': /usr/src/sys/dev/usb/if_ural.c:755: undefined reference to `ieee80211_beacon_alloc' if_ural.o(.text+0x32bc):/usr/src/sys/dev/usb/if_ural.c:2450: undefined reference to `ieee80211_amrr_node_init' if_ural.o(.text+0x38a4): In function `ural_rxeof': /usr/src/sys/dev/usb/if_ural.c:990: undefined reference to `ieee80211_find_rxnode' if_ural.o(.text+0x38e6):/usr/src/sys/dev/usb/if_ural.c:993: undefined reference to `ieee80211_input' if_ural.o(.text+0x38ee):/usr/src/sys/dev/usb/if_ural.c:996: undefined reference to `ieee80211_free_node' if_rum.o(.text+0x823): In function `rum_free_tx_list': /usr/src/sys/dev/usb/if_rum.c:666: undefined reference to `ieee80211_free_node' if_rum.o(.text+0xa42): In function `rum_detach': /usr/src/sys/dev/usb/if_rum.c:605: undefined reference to `ieee80211_ifdetach' if_rum.o(.text+0x12c6): In function `rum_attach': /usr/src/sys/dev/usb/if_rum.c:506: undefined reference to `ieee80211_init_channels' if_rum.o(.text+0x12fd):/usr/src/sys/dev/usb/if_rum.c:514: undefined reference to `ieee80211_ieee2mhz' if_rum.o(.text+0x1347):/usr/src/sys/dev/usb/if_rum.c:520: undefined reference to `ieee80211_ieee2mhz' if_rum.o(.text+0x1391):/usr/src/sys/dev/usb/if_rum.c:526: undefined reference to `ieee80211_ieee2mhz' if_rum.o(.text+0x13de):/usr/src/sys/dev/usb/if_rum.c:532: undefined reference to `ieee80211_ieee2mhz' if_rum.o(.text+0x1413):/usr/src/sys/dev/usb/if_rum.c:538: undefined reference to `ieee80211_ifattach' if_rum.o(.text+0x1463):/usr/src/sys/dev/usb/if_rum.c:550: undefined reference to `ieee80211_media_status' if_rum.o(.text+0x1476):/usr/src/sys/dev/usb/if_rum.c:550: undefined reference to `ieee80211_media_init' if_rum.o(.text+0x149b):/usr/src/sys/dev/usb/if_rum.c:552: undefined reference to `ieee80211_amrr_init' if_rum.o(.text+0x1513):/usr/src/sys/dev/usb/if_rum.c:569: undefined reference to `ieee80211_announce' if_rum.o(.text+0x1a2d): In function `rum_start': /usr/src/sys/dev/usb/if_rum.c:1396: undefined reference to `ieee80211_free_node' if_rum.o(.text+0x1cd3):/usr/src/sys/dev/usb/if_rum.c:1414: undefined reference to `ieee80211_cancel_scan' if_rum.o(.text+0x1d02):/usr/src/sys/dev/usb/if_rum.c:1421: undefined reference to `ieee80211_find_txnode' if_rum.o(.text+0x1d47):/usr/src/sys/dev/usb/if_rum.c:1428: undefined reference to `ieee80211_encap' if_rum.o(.text+0x1d59):/usr/src/sys/dev/usb/if_rum.c:1430: undefined reference to `ieee80211_free_node' if_rum.o(.text+0x1dbf):/usr/src/sys/dev/usb/if_rum.c:1302: undefined reference to `ieee80211_crypto_encap' if_rum.o(.text+0x1f93):/usr/src/sys/dev/usb/if_rum.c:1438: undefined reference to `ieee80211_free_node' if_rum.o(.text+0x203a): In function `rum_txeof': /usr/src/sys/dev/usb/if_rum.c:844: undefined reference to `ieee80211_process_callback' if_rum.o(.text+0x20c9):/usr/src/sys/dev/usb/if_rum.c:863: undefined reference to `ieee80211_free_node' if_rum.o(.text+0x2129): In function `rum_set_chan': /usr/src/sys/dev/usb/if_rum.c:1792: undefined reference to `ieee80211_chan2ieee' if_rum.o(.text+0x2b26): In function `rum_rxeof': /usr/src/sys/dev/usb/if_rum.c:937: undefined reference to `ieee80211_find_rxnode' if_rum.o(.text+0x2c61):/usr/src/sys/dev/usb/if_rum.c:957: undefined reference to `ieee80211_input' if_rum.o(.text+0x2c6c):/usr/src/sys/dev/usb/if_rum.c:960: undefined reference to `ieee80211_free_node' if_rum.o(.text+0x2cce):/usr/src/sys/dev/usb/if_rum.c:937: undefined reference to `ieee80211_find_rxnode' if_rum.o(.text+0x2e07): In function `rum_amrr_update': /usr/src/sys/dev/usb/if_rum.c:2421: undefined reference to `ieee80211_amrr_choose' if_rum.o(.text+0x308d): In function `rum_task': /usr/src/sys/dev/usb/if_rum.c:2282: undefined reference to `ieee80211_beacon_alloc' if_rum.o(.text+0x315f):/usr/src/sys/dev/usb/if_rum.c:2364: undefined reference to `ieee80211_amrr_node_init' if_rum.o(.text+0x34d4): In function `rum_ioctl': /usr/src/sys/dev/usb/if_rum.c:1493: undefined reference to `ieee80211_ioctl' if_rum.o(.text+0x35bb): In function `rum_media_change': /usr/src/sys/dev/usb/if_rum.c:742: undefined reference to `ieee80211_media_change' if_rum.o(.text+0x3802): In function `rum_raw_xmit': /usr/src/sys/dev/usb/if_rum.c:2316: undefined reference to `ieee80211_free_node' if_rum.o(.text+0x3831):/usr/src/sys/dev/usb/if_rum.c:2322: undefined reference to `ieee80211_free_node' if_rum.o(.text+0x3a48):/usr/src/sys/dev/usb/if_rum.c:2352: undefined reference to `ieee80211_free_node' umass.o(.text+0x1c): In function `umass_cam_detach_sim': /usr/src/sys/dev/usb/umass.c:2708: undefined reference to `xpt_bus_deregister' umass.o(.text+0x38):/usr/src/sys/dev/usb/umass.c:2709: undefined reference to `cam_sim_free' umass.o(.text+0x44d): In function `umass_cam_quirk_cb': /usr/src/sys/dev/usb/umass.c:3259: undefined reference to `xpt_done' umass.o(.text+0x465):/usr/src/sys/dev/usb/umass.c:3268: undefined reference to `xpt_done' umass.o(.text+0x493): In function `umass_cam_sense_cb': /usr/src/sys/dev/usb/umass.c:3159: undefined reference to `xpt_done' umass.o(.text+0x5c2):/usr/src/sys/dev/usb/umass.c:3233: undefined reference to `xpt_done' umass.o(.text+0x5d3):/usr/src/sys/dev/usb/umass.c:3240: undefined reference to `xpt_done' umass.o(.text+0x619):/usr/src/sys/dev/usb/umass.c:3066: more undefined references to `xpt_done' follow umass.o(.text+0xdae): In function `umass_cam_action': /usr/src/sys/dev/usb/umass.c:3010: undefined reference to `cam_calc_geometry' umass.o(.text+0xdb6):/usr/src/sys/dev/usb/umass.c:3011: undefined reference to `xpt_done' umass.o(.text+0xdc7):/usr/src/sys/dev/usb/umass.c:3022: undefined reference to `xpt_done' umass.o(.text+0xddb):/usr/src/sys/dev/usb/umass.c:3034: undefined reference to `xpt_done' umass.o(.text+0x1221): In function `umass_attach': /usr/src/sys/dev/usb/umass.c:2601: undefined reference to `cam_simq_alloc' umass.o(.text+0x1275):/usr/src/sys/dev/usb/umass.c:2605: undefined reference to `cam_sim_alloc' umass.o(.text+0x1284):/usr/src/sys/dev/usb/umass.c:2614: undefined reference to `cam_simq_free' umass.o(.text+0x12a7):/usr/src/sys/dev/usb/umass.c:2618: undefined reference to `xpt_bus_register' umass.o(.text+0x13b1): In function `umass_cam_rescan_callback': /usr/src/sys/dev/usb/umass.c:2639: undefined reference to `xpt_free_path' umass.o(.text+0x2632): In function `umass_cam_rescan': /usr/src/sys/dev/usb/umass.c:2658: undefined reference to `xpt_periph' umass.o(.text+0x2641):/usr/src/sys/dev/usb/umass.c:2658: undefined reference to `xpt_create_path' umass.o(.text+0x2673):/usr/src/sys/dev/usb/umass.c:2665: undefined reference to `xpt_setup_ccb' umass.o(.text+0x2690):/usr/src/sys/dev/usb/umass.c:2669: undefined reference to `xpt_action' *** Error code 1 Stop in /usr/obj/usr/src/sys/CK. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # It worked previously, the only change in my kernel configuration was "option MROUTING", which doesn't seem related to this failure. I could comment out all the usb/firewire options I suppose ,but I thought I'd get some insight hopefully from stable first. Thanks. ~k From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 15:44:02 2008 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 08A851065686 for ; Thu, 25 Sep 2008 15:44:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 5E50C8FC15 for ; Thu, 25 Sep 2008 15:44:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA03.westchester.pa.mail.comcast.net with comcast id K1GN1a02b0mv7h0533k0Mt; Thu, 25 Sep 2008 15:44:00 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA11.westchester.pa.mail.comcast.net with comcast id K3jo1a0014v8bD73X3jo9v; Thu, 25 Sep 2008 15:43:50 +0000 X-Authority-Analysis: v=1.0 c=1 a=pl5uMaLHwrUA:10 a=20ZdTaP2r60A:10 a=9vhWPJjcAAAA:8 a=8pif782wAAAA:8 a=QycZ5dHgAAAA:8 a=3p7DU7kqWAIqiGVLyccA:9 a=m-iPL0gShXMee4Fz2E41rVsUrYUA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id E1FB3C9419; Thu, 25 Sep 2008 08:43:57 -0700 (PDT) Date: Thu, 25 Sep 2008 08:43:57 -0700 From: Jeremy Chadwick To: Pete French Message-ID: <20080925154357.GA16220@icarus.home.lan> References: <20080925145154.GA15486@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, admin@kkip.pl Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 25 Sep 2008 15:44:02 -0000 On Thu, Sep 25, 2008 at 04:10:07PM +0100, Pete French wrote: > > These are the tuning settings I use: > > > > vm.kmem_size="1536M" > > vm.kmem_size_max="1536M" > > vfs.zfs.arc_min="16M" > > vfs.zfs.arc_max="64M" > > > > The entire copying process took almost 2 hours. Not once did I > > experience kmem exhaustion. I can *guarantee* that I would have crashed > > the box numerous times had I not tuned the machine with the values > > above. > > I am interested in the last two values you have there - I also use ZFS and > tune to prevent memory exhaustion. I tune kmem_size, but I have not bothered > toi set the arc_min - and the default appears to be 16M anyway. The arc_max > value I do set, but I got dreadful performance when I had it at 6M, so > I upped it to 128M. ARC tuning is what's necessary to induce ZFS memory constraints. If you only set kmem_size/max, you will likely run into cases where the ARC grows to such a size that kmem exhaustion happens. Even the Solaris ZFS "do not tune ZFS" article outlines this fact (read it all, including the RFEs): http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Limiting_the_ARC_Cache Just keep in mind this is specific to Solaris, but the problems conceptually are identical to FreeBSD. > This has not resulted in any panics, and gives much better > performance. As I understand it there is only one ARC, and it comes from > kernel space too, so setting it to an extra 64 meg should not use that much > more memory, yes ? The ARC uses kmem. "Should not use that much more memory" is a matter of opinion; if an additional 64MB given to ARC causes kmem exhaustion (there's no global standard for this; keep reading, I explain it near the bottom of my mail), then decreasing the ARC max is necesary. On the bright side, it's very easy to determine how much memory is being dedicated to the ARC. sysctl kstat.zfs.misc will disclose this data and I believe the following statistics are the ones you have to examine for this issue: kstat.zfs.misc.arcstats.p kstat.zfs.misc.arcstats.c kstat.zfs.misc.arcstats.c_min kstat.zfs.misc.arcstats.c_max kstat.zfs.misc.arcstats.size On my system (the one using the tuning parameters you're questioning): kstat.zfs.misc.arcstats.p: 60487680 kstat.zfs.misc.arcstats.c: 67108864 kstat.zfs.misc.arcstats.c_min: 16777216 kstat.zfs.misc.arcstats.c_max: 67108864 kstat.zfs.misc.arcstats.size: 67092480 For those wanting to read about the ARC and what it's for: http://en.wikipedia.org/wiki/Adaptive_Replacement_Cache > My setup is: > > vm.kmem_size="1024M" > vm.kmem_size_max="1024M" > vfs.zfs.arc_max="128M" > vfs.zfs.prefetch_disable=1 > > This is on a 2gb amd64 machine, and works beautifully, with no out of > memory errors and panics. I have been trying to panic this for a few > days. I will probably chnage the kmem size to 1536 which is what I use on > other machines though. Disabling prefetch shouldn't have any effect on stability -- many of us (including FreeBSD core members) have found that disabling prefetch increases system responsiveness during heavy I/O, and results in a less "bursty" system. I disable prefetch, but it should have no bearing on the issue we're discussing. I'm sure the memory tuning values work fine for you, but they do not for me; I can absolutely panic the machine with a kmem size of 1GB. How? Because it's entirely dependent upon the type of ZFS pools/setup a person has, how much actual load they put on ZFS, and probably a hundred other things. Let's adhere to the K.I.S.S. concept, and not turn this thread into a "tuning micro-management" thread. What end-users want is ZFS that "just works", which on Solaris 10 it does. But I have no qualms with tuning ZFS on FreeBSD, though others seem to. A "tuning guide" cannot easily be written because there are too many factors to take into consideration. Besides, such a guide (documenting "how it all interconnects, memory-wise") would end up being tailored to the technical, which won't help end-users. The existing "ZFS tuning guide" for FreeBSD keeps things vague for a good reason -- I'm absolutely 100% positive an extensive document would just confuse the living daylights out of people. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 15:47:10 2008 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 0D9A91065689 for ; Thu, 25 Sep 2008 15:47:10 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id B2DAF8FC1E for ; Thu, 25 Sep 2008 15:47:09 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so64150qwb.7 for ; Thu, 25 Sep 2008 08:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=gHtOcq7JySq9YLwLKn54g9+r4yAcgleTHmrX/9xtCDg=; b=dCFcB1YPul6DfJFiUtKGpdaHgrLuai7+1z/+qcuLO8W9Tb17ijxsykbF0u0olURT3m B55yqsa1UMCWO08bJLeTgmVQJcBSKYVO23hc32SMZzLYdly8rf7nTQKqzJjcD4kBbuOI /QOEo0cgP/IqzqW0g5wIa9LcIgUfIR+YCJJxs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=f6oaI4wMUoz2qN2XFHiYZ92WSy1Fny+XkM70DMp+qvHBpezC4FSBQ0/rT3fExzLWNj I7ytaDbVd5ZlhGGeO8Vx9uU0bIcFG0SLmnYX73nS4Uz56lmpRRaWrMeWSKIC/Eu/mVay fN1i8u5LvzEl88yAAcbA3AzpdhBraeXRoOnjc= Received: by 10.214.149.6 with SMTP id w6mr7038866qad.40.1222357628638; Thu, 25 Sep 2008 08:47:08 -0700 (PDT) Received: from ?10.0.3.231? ( [70.111.10.128]) by mx.google.com with ESMTPS id 4sm884426yxq.9.2008.09.25.08.47.07 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Sep 2008 08:47:08 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Pete French In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Thu, 25 Sep 2008 11:46:41 -0400 Message-Id: <1222357601.978.11.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: koitsu@FreeBSD.org, freebsd-stable@freebsd.org, admin@kkip.pl Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 25 Sep 2008 15:47:10 -0000 On Thu, 2008-09-25 at 16:10 +0100, Pete French wrote: > > These are the tuning settings I use: > > > > vm.kmem_size="1536M" > > vm.kmem_size_max="1536M" > > vfs.zfs.arc_min="16M" > > vfs.zfs.arc_max="64M" > > > > > The entire copying process took almost 2 hours. Not once did I > > experience kmem exhaustion. I can *guarantee* that I would have crashed > > the box numerous times had I not tuned the machine with the values > > above. > > I am interested in the last two values you have there - I also use ZFS and > tune to prevent memory exhaustion. I tune kmem_size, but I have not bothered > toi set the arc_min - and the default appears to be 16M anyway. The arc_max > value I do set, but I got dreadful performance when I had it at 6M, so > I upped it to 128M. This has not resulted in any panics, and gives much better > performance. As I understand it there is only one ARC, and it comes from > kernel space too, so setting it to an extra 64 meg should not use that much > more memory, yes ? On my RELENG_7 (circa August 14th) vfs.zfs.arc_min: 16777216 vfs.zfs.arc_max: 402653184 seem to be set by default. Yes, that is "384M". I have vm.kmem_size_max="512M" vm.kmem_size="512M" set in my /boot/loader.conf, and vfs.ufs.dirhash_maxmem=16777216 kern.maxvnodes=100000 set in /etc/sysctl.conf This is amd64 with 3GB of real memory. ZFS pool is used to serve music, digital pictures and video to the rest of household, as well as provide target for the weekly backups from couple of Windows desktops, so use is not that heavy. Machine has been up for 22 days and has shown no ill effects that I can notice. -- Alexandre "Sunny" Kovalenko (ОлекÑандр Коваленко) From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 15:53:52 2008 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 EDBEC1065689 for ; Thu, 25 Sep 2008 15:53:52 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 989E78FC20 for ; Thu, 25 Sep 2008 15:53:52 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Jzei1a00A0Fqzac573trRf; Thu, 25 Sep 2008 15:53:51 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA08.westchester.pa.mail.comcast.net with comcast id K3to1a00C4v8bD73U3toUQ; Thu, 25 Sep 2008 15:53:49 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=8Hum7sOo72M-xL_Q0X8A:9 a=smrLyij4JyWH2OL2KWwA:7 a=63QoOFSqjNorEMngBMP4_ffUgmYA:4 a=o8a9Tf765uoA:10 a=EoioJ0NPDVgA:10 a=vdZ_FD5UzDkA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 15970C9419; Thu, 25 Sep 2008 08:53:48 -0700 (PDT) Date: Thu, 25 Sep 2008 08:53:48 -0700 From: Jeremy Chadwick To: Kevin Message-ID: <20080925155348.GB16220@icarus.home.lan> References: <002901c91f21$52a90440$f7fb0cc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002901c91f21$52a90440$f7fb0cc0$@com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Make buildkernel fails 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, 25 Sep 2008 15:53:53 -0000 On Thu, Sep 25, 2008 at 11:13:52AM -0400, Kevin wrote: > # uname -a > FreeBSD ck.com 7.0-STABLE FreeBSD 7.0-STABLE #1: Tue Jul 15 11:38:41 EDT > 2008 ck@friendlybearonskates.com:/usr/obj/usr/src/sys/CK i386 > # > > Make buildkernel kernconf=CK fails here : > > linking kernel.debug > sbp.o(.text+0xd9d): In function `sbp_free_ocb': > /usr/src/sys/dev/firewire/sbp.c:2905: undefined reference to > `xpt_release_devq' > snip and skip... > umass.o(.text+0x1c): In function `umass_cam_detach_sim': > /usr/src/sys/dev/usb/umass.c:2708: undefined reference to > `xpt_bus_deregister' xpt_* missing symbols are due to CAM being removed from your kernel configuration. You'll need "device scbus" and "device da". > /usr/src/sys/dev/usb/if_ural.c:627: undefined reference to > `ieee80211_free_node' ieee80211_* missing symbols are due to you attempting to include some wireless USB drivers; you'll need "device wlan". > It worked previously, the only change in my kernel configuration was "option > MROUTING", which doesn't seem related to this failure. I could comment out > all the usb/firewire options I suppose ,but I thought I'd get some insight > hopefully from stable first. A few things: 1) Your kernel configuration may be "out of date" compared to GENERIC. GENERIC is updated often; sometimes device names change, or things are removed/replaced or added for needed features. I assume your CK config is outdated since the box was last built in July. I recommend doing cp GENERIC CK and then editing CK to your needs. 2) Did you rm -fr /usr/obj/* before starting this build? If not, try it. There may be old cruft in there from July. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 15:59:53 2008 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 2A9271065695; Thu, 25 Sep 2008 15:59:53 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id E4E088FC29; Thu, 25 Sep 2008 15:59:52 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KitFw-000HI1-4h; Thu, 25 Sep 2008 16:59:52 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KitFw-0000XA-3B; Thu, 25 Sep 2008 16:59:52 +0100 To: koitsu@FreeBSD.org In-Reply-To: <20080925154357.GA16220@icarus.home.lan> Message-Id: From: Pete French Date: Thu, 25 Sep 2008 16:59:52 +0100 Cc: freebsd-stable@freebsd.org, admin@kkip.pl Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 25 Sep 2008 15:59:53 -0000 > The ARC uses kmem. "Should not use that much more memory" is a matter > of opinion; if an additional 64MB given to ARC causes kmem exhaustion Well, yes :-) Though I would think if I was runnign a system with 1.5 gig of kernel memory where an extra 64 meg was the differebce between life and death then I would be sailing too close to the wind for my liking anyway... > On the bright side, it's very easy to determine how much memory is being > dedicated to the ARC. sysctl kstat.zfs.misc will disclose this data > and I believe the following statistics are the ones you have to examine > for this issue: Now this is very useful stuff! I have compared mine to yours, and I am using more or less an extra 64 meg. which is kind what I expected. I also tried the script from the wiki page to estimate how much kernel memory I am using, and that hovers around the 300 meg mark. > Let's adhere to the K.I.S.S. concept, and not turn this thread into > a "tuning micro-management" thread. fair enough - I was just curious about the difference between 64 and 128 on the ARC cache, and now I have an answer, and more than enough info to do my own invetsigations as to what works for me. Thanks ;) -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 16:08:24 2008 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 050F5106568D for ; Thu, 25 Sep 2008 16:08:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id DC0468FC13 for ; Thu, 25 Sep 2008 16:08:23 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id K06N1a00d1GXsucA448P1X; Thu, 25 Sep 2008 16:08:23 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id K48M1a00N4v8bD78T48Nql; Thu, 25 Sep 2008 16:08:23 +0000 X-Authority-Analysis: v=1.0 c=1 a=pl5uMaLHwrUA:10 a=20ZdTaP2r60A:10 a=QycZ5dHgAAAA:8 a=Sy3vyHCys7K8U2cHiLsA:9 a=zrkFD7_zZH1qNqOpONgA:7 a=jBntfdy1STXsoBrwz3du4-rSBtsA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id D7CC6C9419; Thu, 25 Sep 2008 09:08:21 -0700 (PDT) Date: Thu, 25 Sep 2008 09:08:21 -0700 From: Jeremy Chadwick To: Alexandre Sunny Kovalenko Message-ID: <20080925160821.GC16220@icarus.home.lan> References: <1222357601.978.11.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1222357601.978.11.camel@RabbitsDen> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, admin@kkip.pl, Pete French Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 25 Sep 2008 16:08:24 -0000 On Thu, Sep 25, 2008 at 11:46:41AM -0400, Alexandre Sunny Kovalenko wrote: > On Thu, 2008-09-25 at 16:10 +0100, Pete French wrote: > > > These are the tuning settings I use: > > > > > > vm.kmem_size="1536M" > > > vm.kmem_size_max="1536M" > > > vfs.zfs.arc_min="16M" > > > vfs.zfs.arc_max="64M" > > > > > > > > The entire copying process took almost 2 hours. Not once did I > > > experience kmem exhaustion. I can *guarantee* that I would have crashed > > > the box numerous times had I not tuned the machine with the values > > > above. > > > > I am interested in the last two values you have there - I also use ZFS and > > tune to prevent memory exhaustion. I tune kmem_size, but I have not bothered > > toi set the arc_min - and the default appears to be 16M anyway. The arc_max > > value I do set, but I got dreadful performance when I had it at 6M, so > > I upped it to 128M. This has not resulted in any panics, and gives much better > > performance. As I understand it there is only one ARC, and it comes from > > kernel space too, so setting it to an extra 64 meg should not use that much > > more memory, yes ? > On my RELENG_7 (circa August 14th) > > vfs.zfs.arc_min: 16777216 > vfs.zfs.arc_max: 402653184 > > seem to be set by default. Yes, that is "384M". The default arc_max value is calculated based on numerous things which are system-specific. The code is in arc_init() here, and the variable is called arc_c_max: src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > I have > > vm.kmem_size_max="512M" > vm.kmem_size="512M" > > set in my /boot/loader.conf, and Your kmem is set to 512MB, yet your maximum ARC size is 384MB. That leaves 128MB for the entire rest of the kmap, including other pieces of ZFS. I can assure you that with a heavier ZFS load, your machine will easily panic. > vfs.ufs.dirhash_maxmem=16777216 > kern.maxvnodes=100000 > > set in /etc/sysctl.conf vfs.ufs.dirhash_maxmem is for UFS/UFS2. Speculative: kern.maxvnodes is vfs-related, and ZFS does use vfs (duh). Increasing kern.maxvnodes means using more kernel memory (no idea if that's kmem or not), which could mean you're decreasing the amount of memory available for ZFS/ARC as well (e.g. panic more likely). > This is amd64 with 3GB of real memory. ZFS pool is used to serve music, > digital pictures and video to the rest of household, as well as provide > target for the weekly backups from couple of Windows desktops, so use is > not that heavy. Machine has been up for 22 days and has shown no ill > effects that I can notice. The lesser load on ZFS, and possibly the system in general, is probably what's keeping you afloat. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 16:16:58 2008 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 0E3A31065686 for ; Thu, 25 Sep 2008 16:16:58 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 86D028FC15 for ; Thu, 25 Sep 2008 16:16:57 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A53E3.dip.t-dialin.net [84.154.83.227]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id m8PFb1s5002228 for ; Thu, 25 Sep 2008 17:37:03 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m8PFanhk098047 for ; Thu, 25 Sep 2008 17:36:50 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m8PFaido092110 for ; Thu, 25 Sep 2008 17:36:49 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200809251536.m8PFaido092110@fire.js.berklix.net> To: stable@freebsd.org From: "Julian Stacey" Organization: http://berklix.com BSD Linux Unix Consultancy, Munich Germany. User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com/~jhs/cv/ Date: Thu, 25 Sep 2008 17:36:44 +0200 Sender: jhs@berklix.org Cc: Subject: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso 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, 25 Sep 2008 16:16:58 -0000 Hi stable@, I just imported an old tower from a friend. Used to run Linux OK. Reset BIOS to defaults, turned off power saving etc, installed 7.1-BETA-i386-disc1.iso I now sees rl0: watchdog timeout + 40,000 ms ping outgoing. ping incoming fails, it's not my net switch, I've moved to different segments etc & all else fine I'm remaking binaries, & will look around for netstat r whatever commands later, meanwhile here's dmesg (via a floppy) Of course it could be somehow a hardaware bad config, its a new box to me. Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-BETA #0: Sun Sep 7 13:49:18 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (651.48-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 134152192 (127 MB) avail memory = 117157888 (111 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] ACPI Error (psargs-0459): [INX_] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0._PRW] (Node 0xc1bd6700), AE_NOT_FOUND acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ef0000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 256M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xe0000000-0xe7ffffff,0xed000000-0xed00ffff irq 11 at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xd400-0xd41f irq 10 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) rl0: port 0xd800-0xd8ff mem 0xee000000-0xee0000ff irq 12 at device 10.0 on pci0 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:08:a1:6d:65:07 rl0: [ITHREAD] pci0: at device 11.0 (no driver attached) cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 acpi_tz0: on acpi0 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ACPI Error (psargs-0459): [INX_] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0._PRW] (Node 0xc1bd6700), AE_NOT_FOUND ACPI Error (psargs-0459): [INX_] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0._PRW] (Node 0xc1bd6700), AE_NOT_FOUND pmtimer0 on isa0 orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 651482522 Hz quality 800 Timecounters tick every 1.000 msec ad0: 4110MB at ata0-master UDMA33 acd0: CDROM at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s1a rl0: link state changed to UP rl0: watchdog timeout rl0: link state changed to DOWN rl0: link state changed to UP rl0: link state changed to DOWN rl0: link state changed to UP rl0: watchdog timeout rl0: watchdog timeout Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 16:31:16 2008 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 E5A6D1065689 for ; Thu, 25 Sep 2008 16:31:16 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id CCDF68FC0A for ; Thu, 25 Sep 2008 16:31:16 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [172.16.12.8] (covad-jrhett.meer.net [209.157.140.144]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8PGVB1Z063855; Thu, 25 Sep 2008 09:31:11 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=-0.942] Message-Id: From: Jo Rhett To: Tom Evans In-Reply-To: <1222354401.2443.46.camel@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 25 Sep 2008 09:31:10 -0700 References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> <1222354401.2443.46.camel@localhost> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-stable Stable Subject: Re: proposed change to support policy for FreeBSD Releases 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, 25 Sep 2008 16:31:17 -0000 > On Tue, 2008-09-23 at 13:37 -0700, Jo Rhett wrote: >> Normal >> Releases which are published from a -STABLE branch will be >> supported by the Security Officer for a minimum of 12 months after >> the >> release. >> A release which is not the final minor release of a branch will >> be additionally supported by a minimum of 6 months past the release >> date of the succeeding version. For example X.1 will be supported >> for >> 12 months or until 6 months past the release date of X.2, whichever >> comes later. >> >> Final >> The final minor release on a given branch will be supported by >> the Security Officer for a minimum of 24 months after the release. On Sep 25, 2008, at 7:53 AM, Tom Evans wrote: > Isn't this a non-pragmatic way of looking at this? Currently, as > long as > there are no serious issues with 6.4, 6.4 will be supported for 24 > months from release. This is abundantly clear from both prior history > and what secteam say. No, it's not. The secteam has repeatedly said that they don't know yet, and can't know yet, whether or not to support 6.4 for 12 or 24 months. This is the problem I am trying to solve. Guessing at this requires foresight, psychic abilities that nobody has. I believe it's a lot more pragmatic to simply say "we will support it for 24 months *unless* a major problem forces another release" and stop trying to be psychic. > To my mind, this entire discussion is bikeshed painting > that ends up with semantic arguing about what a 'final' release is. It's not semantics. It's a very serious issue with overlapping support periods that cause businesses to stay back on older releases, which means they contribute no resources to testing new releases. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 16:45:11 2008 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 C5A9E1065687 for ; Thu, 25 Sep 2008 16:45:11 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3AF448FC20 for ; Thu, 25 Sep 2008 16:45:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA04.westchester.pa.mail.comcast.net with comcast id Jz8V1a0071GhbT8544lAym; Thu, 25 Sep 2008 16:45:10 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA07.westchester.pa.mail.comcast.net with comcast id K4l91a00C4v8bD73T4l9pq; Thu, 25 Sep 2008 16:45:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=93IlrX9DObQA:10 a=a8CEgAfaXG8A:10 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=D_NXAPevpKdkx756-NkA:9 a=JUS7HFeP0RiYiJhnOQsA:7 a=i41Qd6lBL2EoSN7DkympgOgM8xIA:4 a=_1I0gKQXIP8A:10 a=ElxRAO5CFNMA:10 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id A1918C9432; Thu, 25 Sep 2008 09:45:08 -0700 (PDT) Date: Thu, 25 Sep 2008 09:45:08 -0700 From: Jeremy Chadwick To: Julian Stacey Message-ID: <20080925164508.GA2105@icarus.home.lan> References: <200809251536.m8PFaido092110@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809251536.m8PFaido092110@fire.js.berklix.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: PYUN Yong-Hyeon , stable@freebsd.org Subject: Re: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso 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, 25 Sep 2008 16:45:11 -0000 On Thu, Sep 25, 2008 at 05:36:44PM +0200, Julian Stacey wrote: > Hi stable@, > I just imported an old tower from a friend. Used to run Linux OK. > Reset BIOS to defaults, turned off power saving etc, installed > 7.1-BETA-i386-disc1.iso > I now sees > rl0: watchdog timeout + 40,000 ms ping outgoing. > ping incoming fails, > it's not my net switch, I've moved to different segments etc & all else fine > > I'm remaking binaries, & will look around for netstat r whatever > commands later, meanwhile here's dmesg (via a floppy) > > Of course it could be somehow a hardaware bad config, its a new box to me. It's a "new box" with hardware from the late 90s? :-) > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-BETA #0: Sun Sep 7 13:49:18 UTC 2008 > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel Pentium III (651.48-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x681 Stepping = 1 > Features=0x383f9ff > real memory = 134152192 (127 MB) > avail memory = 117157888 (111 MB) > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: [ITHREAD] > ACPI Error (psargs-0459): [INX_] Namespace lookup failure, AE_NOT_FOUND > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0._PRW] (Node 0xc1bd6700), AE_NOT_FOUND > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7ef0000 (3) failed > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f on acpi0 > pci0: on pcib0 > agp0: on hostb0 > agp0: aperture size is 256M > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xc000-0xc0ff mem 0xe0000000-0xe7ffffff,0xed000000-0xed00ffff irq 11 at device 0.0 on pci1 > isab0: at device 7.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 7.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > uhci0: port 0xd400-0xd41f irq 10 at device 7.2 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > pci0: at device 7.3 (no driver attached) > rl0: port 0xd800-0xd8ff mem 0xee000000-0xee0000ff irq 12 at device 10.0 on pci0 > miibus0: on rl0 > rlphy0: PHY 0 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > rl0: Ethernet address: 00:08:a1:6d:65:07 > rl0: [ITHREAD] > pci0: at device 11.0 (no driver attached) > cpu0: on acpi0 > acpi_throttle0: on cpu0 > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio0: [FILTER] > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > sio1: [FILTER] > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > ACPI Error (psargs-0459): [INX_] Namespace lookup failure, AE_NOT_FOUND > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0._PRW] (Node 0xc1bd6700), AE_NOT_FOUND > ACPI Error (psargs-0459): [INX_] Namespace lookup failure, AE_NOT_FOUND > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0._PRW] (Node 0xc1bd6700), AE_NOT_FOUND > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounter "TSC" frequency 651482522 Hz quality 800 > Timecounters tick every 1.000 msec > ad0: 4110MB at ata0-master UDMA33 > acd0: CDROM at ata1-master UDMA33 > Trying to mount root from ufs:/dev/ad0s1a > rl0: link state changed to UP > rl0: watchdog timeout > rl0: link state changed to DOWN > rl0: link state changed to UP > rl0: link state changed to DOWN > rl0: link state changed to UP > rl0: watchdog timeout > rl0: watchdog timeout I've CC'd PYUN Yong-Hyeon (surname is Pyun), who helps maintain the rl(4) driver. He might have some ideas. For now, please provide the output from "vmstat -i" and "pciconf -lv". And some stuff to ponder, just ideas/comments in passing: * Board does not appear to have an APIC (not a typo), so IRQ sharing is likely. IRQ 12 is often used for PS/2 devices (mice, keyboards), and I see rl0 is sitting on that IRQ. * Read the BUGS section of the rl(4) manpage; these NICs are known to be questionable in many regards. The CVS commit log for this driver also has quite a list of other documented (major) bugs. "User beware": http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c * It's a VIA chipset board. Old Tyan server boards I had using VIA chips (Apollo with 686B southbridge) would, even so often, stop handling/firing IRQs. This would happen with almost any device, even ones which were known to be relible (like fxp(4)). The only solution would be to hard reset it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 16:59:28 2008 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 3C9CB1065688 for ; Thu, 25 Sep 2008 16:59:28 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id 166948FC15 for ; Thu, 25 Sep 2008 16:59:27 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: (qmail 26150 invoked from network); 25 Sep 2008 16:32:47 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 25 Sep 2008 16:32:46 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 1A88E28474; Thu, 25 Sep 2008 12:32:46 -0400 (EDT) To: Jo Rhett References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> From: Lowell Gilbert Date: Thu, 25 Sep 2008 12:32:45 -0400 In-Reply-To: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> (Jo Rhett's message of "Tue\, 23 Sep 2008 13\:37\:03 -0700") Message-ID: <44abdw9oeq.fsf@be-well.ilk.org> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org Subject: Re: proposed change to support policy for FreeBSD Releases X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 16:59:28 -0000 Jo Rhett writes: > Each branch is supported by the Security Officer for a limited time > only, and is designated as one of `Early adopter', `Normal', or > Final'. The designation is used as a guideline for determining the > lifetime of the branch as follows. I'm not clear on how this helps. We don't know if there will be a need to produce a 6.5 release, so there's no way to judge whether 6.4 should be designated "final" or not. The only logical answer is to do so, which leaves a substantial chance that there will end up being more than one "final" release on the 6.x line. That's not a particularly desirable situation. In fact, it's worse, because if 6.5 happens, it will probably be because there were problems with 6.4 serious enough that we'd rather people move to 6.5 anyway (at least for critical systems). Be well. Lowell From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 19:27:04 2008 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 611CB1065720; Thu, 25 Sep 2008 19:27:04 +0000 (UTC) (envelope-from Satendra.Pratap@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by mx1.freebsd.org (Postfix) with ESMTP id 0BC548FC2A; Thu, 25 Sep 2008 19:27:03 +0000 (UTC) (envelope-from Satendra.Pratap@citrix.com) X-IronPort-AV: E=Sophos;i="4.33,309,1220241600"; d="scan'208,217";a="21360148" Received: from ftlpexchmx01.citrite.net ([10.9.154.126]) by FTLPIPO02.CITRIX.COM with ESMTP; 25 Sep 2008 14:58:01 -0400 Received: from banpexch01.citrite.net ([10.103.128.11]) by FTLPEXCHMX01.citrite.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Sep 2008 14:58:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 26 Sep 2008 00:27:57 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: regarding 1 Gig Chelsio SFP support Thread-Index: AckfQJ912V1Jq+F5SBqoNOI+0eg4kw== From: "Satendra Pratap" To: X-OriginalArrivalTime: 25 Sep 2008 18:58:00.0668 (UTC) FILETIME=[A19ED9C0:01C91F40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: kmacy@freebsd.org Subject: regarding 1 Gig Chelsio SFP support 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, 25 Sep 2008 19:27:04 -0000 Reposting on stable mailing list(FreeBSD 6.X): We have chelsio T304 1 Gig card which supports Fiber SFP. I have = already asked from chelsio guys for its Driver support on FreeBSD and still waiting for reply. Just wondering if anybody could let me know about T304's Driver support on FreeBSD 6.x . One more question, because we use third party SFPs (finsar, picolight etc) so do we need to download SFP's drivers also or NIC (Ethernet MAC) = vendor's device driver should already have that support? Thanks, Satendra On Thu, Sep 25, 2008 at 4:13 AM, Satendra Pratap wrote: --8<--- > We have chelsio T304 1 Gig card which supports Fiber SFP. I have = already > asked from chelsio guys for its Driver support on FreeBSD and still > waiting for reply. Just wondering if anybody could let me know about > T304's Driver support on FreeBSD. > > One more question, because we use third party SFPs (finsar, picolight > etc) so do we need to download SFP's drivers also or NIC vendor's > device driver should already have that support? Kip Macy is the maintainer of drivers for some Chelsio hardware. If you are attempting to use the hardware on FreeBSD 6.x of 7.x then ask in the freebsd-stable mailing list, otherwise ask in freebsd-current. -- cd /usr/ports/sysutils/life make clean From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 21:15:13 2008 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 18A9F1065686 for ; Thu, 25 Sep 2008 21:15:13 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id E81BF8FC08 for ; Thu, 25 Sep 2008 21:15:12 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 83271890037; Thu, 25 Sep 2008 14:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmv74U1FgC4q; Thu, 25 Sep 2008 14:10:17 -0700 (PDT) Received: from [10.47.1.10] (vpn.office.miralink.com [10.0.0.5]) by plato.miralink.com (Postfix) with ESMTP id D490A890036; Thu, 25 Sep 2008 14:10:16 -0700 (PDT) Message-ID: <48DBFF5F.7050308@miralink.com> Date: Thu, 25 Sep 2008 14:15:11 -0700 From: Sean Bruno User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Satendra Pratap References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, kmacy@freebsd.org Subject: Re: regarding 1 Gig Chelsio SFP support 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, 25 Sep 2008 21:15:13 -0000 Satendra Pratap wrote: > Reposting on stable mailing list(FreeBSD 6.X): > > We have chelsio T304 1 Gig card which supports Fiber SFP. I have already > asked from chelsio guys for its Driver support on FreeBSD and still > waiting for reply. Just wondering if anybody could let me know about > T304's Driver support on FreeBSD 6.x . > > One more question, because we use third party SFPs (finsar, picolight > etc) so do we need to download SFP's drivers also or NIC (Ethernet MAC) vendor's > device driver should already have that support? > > Thanks, > Satendra > If it's supported, it's been supported by 6.x since 6.3 according to the cxgb(4) man page. I couldn't cross-reference "T304" on the chelsio web site, but perhaps it's based on the T3 chipset and will "just work" :) Follow the instructions in the man page with a BSD 6.3 machine to see if it works. If it doesn't, please repost the output of lspci -v here so we can see if it's a card that should work, but doesn't. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 00:29:43 2008 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 E62EB1065692 for ; Fri, 26 Sep 2008 00:29:43 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (s8.stradamotorsports.com [64.81.163.126]) by mx1.freebsd.org (Postfix) with ESMTP id A16528FC17 for ; Fri, 26 Sep 2008 00:29:43 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from w16.stradamotorsports.com (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.8/8.13.8) with ESMTP id m8Q0Te4A008914; Thu, 25 Sep 2008 17:29:40 -0700 (PDT) (envelope-from jcw@highperformance.net) Message-ID: <48DC2CF4.5010906@highperformance.net> Date: Thu, 25 Sep 2008 17:29:40 -0700 From: "Jason C. Wells" User-Agent: Thunderbird 2.0.0.4pre (X11/20080205) MIME-Version: 1.0 To: Ruslan Ermilov References: <48DAF163.8060502@highperformance.net> <20080925044640.GA76968@edoofus.dev.vega.ru> In-Reply-To: <20080925044640.GA76968@edoofus.dev.vega.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on s4.stradamotorsports.com Cc: freebsd-stable Subject: Re: buildworld fails immediately 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, 26 Sep 2008 00:29:44 -0000 Ruslan Ermilov wrote: > Make sure /dev/null inside a jail is a device and not a plain file. > If the latter, you probably forgot to mount devfs onto a jail's /dev. Groovy! Thanks. Later, Jason From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 02:28:36 2008 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 DB208106568A for ; Fri, 26 Sep 2008 02:28:36 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3DB8FC08 for ; Fri, 26 Sep 2008 02:28:36 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so645785rvf.43 for ; Thu, 25 Sep 2008 19:28:36 -0700 (PDT) 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=z6u3nbXffSQ7Ye8jv6z+QXEniNAGZQ4joIAxDP8485g=; b=v8SQevnmIqIL1ABIBz4Tj71v3e8cLjR+1ReT72pi8eqVxGvX+P3Fx3JKoIion9WdHp 7Nd61k0uvush30nimUQEC/BLFAF++6Xwnitsazoqqqoc+UAWDGKTlE45YthzPsZsrvqt FmXv7j3Pn5+k7XFYAB/aXKYB+SJerwTGgZLE4= 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=Ffbh/H1pilxQH/Zq+LkSo9YHRvlxtWCOYtanCmKX6lQS6tBnep6ZJfAE9563vwdQul RSQ8WKiwK+HMNSJV5uzHJOBpXVtmvkVG59yFToaWj9saRzbo1raQsB0RghMoHKLpK+Hf uqpJ03eR4BqNAnrjdovCe21Phzx3AKqJqHVmU= Received: by 10.140.162.21 with SMTP id k21mr284808rve.110.1222392951595; Thu, 25 Sep 2008 18:35:51 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id g31sm1942645rvb.7.2008.09.25.18.35.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 25 Sep 2008 18:35:50 -0700 (PDT) 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 m8Q1XnOe043377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 10:33:49 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m8Q1XkXd043376; Fri, 26 Sep 2008 10:33:46 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 26 Sep 2008 10:33:46 +0900 From: Pyun YongHyeon To: Julian Stacey Message-ID: <20080926013346.GA43015@cdnetworks.co.kr> References: <200809251536.m8PFaido092110@fire.js.berklix.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <200809251536.m8PFaido092110@fire.js.berklix.net> User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org Subject: Re: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso 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, 26 Sep 2008 02:28:36 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 25, 2008 at 05:36:44PM +0200, Julian Stacey wrote: > Hi stable@, > I just imported an old tower from a friend. Used to run Linux OK. > Reset BIOS to defaults, turned off power saving etc, installed > 7.1-BETA-i386-disc1.iso > I now sees > rl0: watchdog timeout + 40,000 ms ping outgoing. > ping incoming fails, > it's not my net switch, I've moved to different segments etc & all else fine > > I'm remaking binaries, & will look around for netstat r whatever > commands later, meanwhile here's dmesg (via a floppy) > > Of course it could be somehow a hardaware bad config, its a new box to me. > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-BETA #0: Sun Sep 7 13:49:18 UTC 2008 > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel Pentium III (651.48-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x681 Stepping = 1 > Features=0x383f9ff > real memory = 134152192 (127 MB) > avail memory = 117157888 (111 MB) [...] > rl0: port 0xd800-0xd8ff mem 0xee000000-0xee0000ff irq 12 at device 10.0 on pci0 > miibus0: on rl0 > rlphy0: PHY 0 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > rl0: Ethernet address: 00:08:a1:6d:65:07 > rl0: [ITHREAD] [...] > rl0: link state changed to UP > rl0: watchdog timeout > rl0: link state changed to DOWN > rl0: link state changed to UP > rl0: link state changed to DOWN > rl0: link state changed to UP > rl0: watchdog timeout > rl0: watchdog timeout > Is there reliable way to reproduce the issue? Anyway, would you try attached patch and let me know result? -- Regards, Pyun YongHyeon --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rl.patch" Index: sys/pci/if_rl.c =================================================================== --- sys/pci/if_rl.c (revision 183366) +++ sys/pci/if_rl.c (working copy) @@ -650,6 +650,34 @@ static void rl_miibus_statchg(device_t dev) { + struct rl_softc *sc; + struct ifnet *ifp; + struct mii_data *mii; + + sc = device_get_softc(dev); + mii = device_get_softc(sc->rl_miibus); + ifp = sc->rl_ifp; + if (mii == NULL || ifp == NULL || + (ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) + return; + + sc->rl_flags &= ~RL_FLAG_LINK; + if ((mii->mii_media_status & (IFM_ACTIVE | IFM_AVALID)) == + (IFM_ACTIVE | IFM_AVALID)) { + switch (IFM_SUBTYPE(mii->mii_media_active)) { + case IFM_10_T: + case IFM_100_TX: + sc->rl_flags |= RL_FLAG_LINK; + break; + default: + break; + } + } + /* + * RealTek controllers does not provide any interface to + * Tx/Rx MACs for resolved speed, duplex and flow-control + * parameters. + */ } /* @@ -1236,7 +1264,6 @@ CSR_WRITE_4(sc, RL_TXCFG, RL_TXCFG_CONFIG); oldthresh = sc->rl_txthresh; /* error recovery */ - rl_reset(sc); rl_init_locked(sc); /* restore original threshold */ sc->rl_txthresh = oldthresh; @@ -1305,10 +1332,8 @@ /* XXX We should check behaviour on receiver stalls. */ - if (status & RL_ISR_SYSTEM_ERR) { - rl_reset(sc); + if (status & RL_ISR_SYSTEM_ERR) rl_init_locked(sc); - } } } #endif /* DEVICE_POLLING */ @@ -1345,10 +1370,8 @@ rl_rxeof(sc); if ((status & RL_ISR_TX_OK) || (status & RL_ISR_TX_ERR)) rl_txeof(sc); - if (status & RL_ISR_SYSTEM_ERR) { - rl_reset(sc); + if (status & RL_ISR_SYSTEM_ERR) rl_init_locked(sc); - } } if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) @@ -1423,6 +1446,10 @@ RL_LOCK_ASSERT(sc); + if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != + IFF_DRV_RUNNING || (sc->rl_flags & RL_FLAG_LINK) == 0) + return; + while (RL_CUR_TXMBUF(sc) == NULL) { IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); @@ -1489,6 +1516,8 @@ */ rl_stop(sc); + rl_reset(sc); + /* * Init our MAC address. Even though the chipset * documentation doesn't mention it, we need to enter "Config @@ -1564,6 +1593,7 @@ /* Enable receiver and transmitter. */ CSR_WRITE_1(sc, RL_COMMAND, RL_CMD_TX_ENB|RL_CMD_RX_ENB); + sc->rl_flags &= ~RL_FLAG_LINK; mii_mediachg(mii); CSR_WRITE_1(sc, RL_CFG1, RL_CFG1_DRVLOAD|RL_CFG1_FULLDUPLEX); @@ -1709,9 +1739,19 @@ sc->rl_watchdog_timer = 0; callout_stop(&sc->rl_stat_callout); ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); + sc->rl_flags &= ~RL_FLAG_LINK; + CSR_WRITE_2(sc, RL_IMR, 0x0000); CSR_WRITE_1(sc, RL_COMMAND, 0x00); - CSR_WRITE_2(sc, RL_IMR, 0x0000); + for (i = 0; i < RL_TIMEOUT; i++) { + DELAY(1); + if ((CSR_READ_1(sc, RL_COMMAND) & + (RL_CMD_RX_ENB | RL_CMD_TX_ENB)) == 0) + break; + } + if (i == RL_TIMEOUT) + device_printf(sc->rl_dev, "stopping Tx/Rx MAC timed out!\n"); + bus_dmamap_unload(sc->rl_tag, sc->rl_cdata.rl_rx_dmamap); /* --4Ckj6UjgE2iN1+kY-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 03:53:32 2008 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 D6C6D10656B2 for ; Fri, 26 Sep 2008 03:53:32 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 885A98FC14 for ; Fri, 26 Sep 2008 03:53:32 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Kj45r-00011P-2x for freebsd-stable@freebsd.org; Thu, 25 Sep 2008 20:34:11 -0700 Message-ID: <21866833.583261222400051087.JavaMail.nabble@isper.nabble.com> From: limguowei@gmail.com To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 25 Sep 2008 20:34:11 -0700 Subject: Problems with FreeBSD 7.1 Pre-Release after Upgrade from 7.0 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, 26 Sep 2008 03:53:32 -0000 After cvsuping the source and recompiling the kernel from 7.0 The follow programs produce error I created a memory disk for a /temp in FreeBSD 7.0 upon upgrading to 7.1 it refuses to created and mount /dev/md0 as successful in 7.0 pid 977/978 (mdconfig) uid 0 exit from signal 11 (core dumped) pid 977 (mdconfig), uid 0: exited on signal 11 (core dumped) pid 978 (mdconfig), uid 0: exited on signal 11 (core dumped) And when i used kldstat the same thing happens after printing one entry # kldstat Id Refs Address Size Name 1 12 0xc0400000 625fe0 kernel Segmentation fault (core dumped) My dmesg is as follows Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #4: Fri Sep 26 00:17:26 SGT 2008 4520G@ACER:/usr/obj/usr/src/sys/TYLER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-60 (2000.20-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 real memory = 3219980288 (3070 MB) avail memory = 3141251072 (2995 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) unknown: I/O range not supported Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x1d00-0x1dff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) ohci0: mem 0xf3486000-0xf3486fff irq 18 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered ehci0: mem 0xf3489000-0xf34890ff irq 19 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 12 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 4 ports with 4 removable, self powered ohci1: mem 0xf3487000-0xf3487fff irq 20 at device 4.0 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: on ohci1 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered ehci1: mem 0xf3489400-0xf34894ff irq 16 at device 4.1 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controller, 12 ports each: usb2 usb3: on ehci1 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 4 ports with 4 removable, self powered ugen0: on uhub3 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30c0-0x30cf at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pcm0: mem 0xf3480000-0xf3483fff irq 17 at device 7.0 on pci0 pcm0: [ITHREAD] pcib1: at device 8.0 on pci0 pci1: on pcib1 fwohci0: <1394 Open Host Controller Interface> mem 0xf3100000-0xf31007ff irq 10 at device 9.0 on pci1 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:24:1b:00:11:e8:a8:00 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:24:1b:e8:a8:00 fwe0: Ethernet address: 02:24:1b:e8:a8:00 fwip0: on firewire0 fwip0: Firewire address: 00:24:1b:00:11:e8:a8:00 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x18cc000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pci1: at device 9.1 (no driver attached) pci1: at device 9.2 (no driver attached) pci1: at device 9.3 (no driver attached) pci1: at device 9.4 (no driver attached) atapci1: port 0x30f0-0x30f7,0x30e4-0x30e7,0x30e8-0x30ef,0x30e0-0x30e3,0x30d0-0x30df mem 0xf3484000-0xf3485fff irq 18 at device 9.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] nfe0: port 0x30f8-0x30ff mem 0xf3488000-0xf3488fff,0xf3489c00-0xf3489cff,0xf3489800-0xf348980f irq 19 at device 10.0 on pci0 miibus0: on nfe0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:1e:68:02:78:b7 nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] pcib2: at device 11.0 on pci0 pci2: on pcib2 vgapci0: port 0x4000-0x407f mem 0xf2000000-0xf2ffffff,0xd0000000-0xdfffffff,0xf0000000-0xf1ffffff irq 20 at device 0.0 on pci2 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcib3: at device 12.0 on pci0 pci3: on pcib3 pcib4: at device 14.0 on pci0 pci7: on pcib4 ath0: mem 0xf3000000-0xf300ffff irq 16 at device 0.0 on pci7 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:1f:3a:01:63:7d ath0: mac 14.2 phy 7.0 radio 10.2 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DVDR at ata0-master UDMA33 ad4: 152627MB at ata2-master UDMA33 pcm0: pcm0: GEOM_LABEL: Label for provider ad4s5 is ntfs/Data. SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s3a acpi_ec0: wait timed out (response), forcing polled mode ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled pid 971 (kldstat), uid 0: exited on signal 11 (core dumped) fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 pid 977 (mdconfig), uid 0: exited on signal 11 (core dumped) pid 978 (mdconfig), uid 0: exited on signal 11 (core dumped) acpi_ec0: warning: EC done before starting event wait pid 1371 (kldstat), uid 1001: exited on signal 11 (core dumped) pid 4485 (kldstat), uid 0: exited on signal 11 (core dumped) From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 03:53:33 2008 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 28B4010656A2 for ; Fri, 26 Sep 2008 03:53:33 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 01A4B8FC35 for ; Fri, 26 Sep 2008 03:53:33 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Kj44D-0000xb-UK for freebsd-stable@freebsd.org; Thu, 25 Sep 2008 20:32:29 -0700 Message-ID: <5130551.582991222399949935.JavaMail.nabble@isper.nabble.com> From: limguowei@gmail.com To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 25 Sep 2008 20:32:29 -0700 Subject: Problems with FreeBSD 7.1 Pre-Release after Upgrade from 7.0 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, 26 Sep 2008 03:53:33 -0000 After cvsuping the source and recompiling the kernel from 7.0 The follow programs produce error I created a memory disk for a /temp in FreeBSD 7.0 upon upgrading to 7.1 it refuses to created and mount /dev/md0 as successful in 7.0 pid 977/978 (mdconfig) uid 0 exit from signal 11 (core dumped) pid 977 (mdconfig), uid 0: exited on signal 11 (core dumped) pid 978 (mdconfig), uid 0: exited on signal 11 (core dumped) And when i used kldstat the same thing happens after printing one entry # kldstat Id Refs Address Size Name 1 12 0xc0400000 625fe0 kernel Segmentation fault (core dumped) From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 04:27:07 2008 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 CE2E5106568D for ; Fri, 26 Sep 2008 04:27:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id B27EE8FC1A for ; Fri, 26 Sep 2008 04:27:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id JyUV1a0070EPchoA5GT7ha; Fri, 26 Sep 2008 04:27:07 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id KGT61a0014v8bD78MGT6rG; Fri, 26 Sep 2008 04:27:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=JQEzplUTJaMA:10 a=QycZ5dHgAAAA:8 a=aEG7NkBbeguagx-lYZQA:9 a=_ChMNCfmX1jLd2lD99sA:7 a=bYTb57jotuB8wVhujEX9J2U-DmgA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id C15ABC9432; Thu, 25 Sep 2008 21:27:05 -0700 (PDT) Date: Thu, 25 Sep 2008 21:27:05 -0700 From: Jeremy Chadwick To: Sean Bruno Message-ID: <20080926042705.GA14897@icarus.home.lan> References: <48DBFF5F.7050308@miralink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DBFF5F.7050308@miralink.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, kmacy@freebsd.org, Satendra Pratap Subject: Re: regarding 1 Gig Chelsio SFP support 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, 26 Sep 2008 04:27:07 -0000 On Thu, Sep 25, 2008 at 02:15:11PM -0700, Sean Bruno wrote: > Satendra Pratap wrote: >> Reposting on stable mailing list(FreeBSD 6.X): >> >> We have chelsio T304 1 Gig card which supports Fiber SFP. I have already >> asked from chelsio guys for its Driver support on FreeBSD and still >> waiting for reply. Just wondering if anybody could let me know about >> T304's Driver support on FreeBSD 6.x . >> >> One more question, because we use third party SFPs (finsar, picolight >> etc) so do we need to download SFP's drivers also or NIC (Ethernet MAC) vendor's >> device driver should already have that support? >> >> Thanks, >> Satendra >> > If it's supported, it's been supported by 6.x since 6.3 according to > the cxgb(4) man page. I couldn't cross-reference "T304" on the > chelsio web site, but perhaps it's based on the T3 chipset and will > "just work" :) > > Follow the instructions in the man page with a BSD 6.3 machine to see if > it works. > > If it doesn't, please repost the output of lspci -v here so we can see > if it's a card that should work, but doesn't. s/lspci -v/pciconf -lv/ -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 07:04:17 2008 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 CD4551065688; Fri, 26 Sep 2008 07:04:17 +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 8A0138FC08; Fri, 26 Sep 2008 07:04:17 +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 1Kj7NA-000FXz-3F; Fri, 26 Sep 2008 10:04:16 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 2008 10:04:16 +0300 From: Danny Braniss Message-ID: Cc: Subject: bad NFS/UDP 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: Fri, 26 Sep 2008 07:04:17 -0000 Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? thanks, danny From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 07:37:35 2008 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 D34A11065686 for ; Fri, 26 Sep 2008 07:37:35 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 643D28FC25 for ; Fri, 26 Sep 2008 07:37:35 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so544056fgb.35 for ; Fri, 26 Sep 2008 00:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0NTM62X0qGWRnOWfxyMg+ZUhAyADlvHH6WB0aw/7gI0=; b=R/on4lMf3de0Ipck6ME4aKBMzcpXxrDCEGPovqKof29RebQ9jsvk1/b7zxGBRA8AWD f10Kac9YU0AsZfGo4n2BcdsgyB0kFPUB0RTMEGMWpwyYqIhpsfxMKCA7Bskz5rbF9775 9YYsQz/Ywj97L6iJdc8be0s7LXfjytk9Vg+os= 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=rAQFcTuV2p99HyfczYdjOgLndS0gNzlN1A+p0fUJCJBePFXqLdBQ/xNYg+JVXNxHAL pxKbjHd/6TijJHAEXbZB/10BDNoiP1X+yso6UJjvy5ykELJcQQvkSaumhmFNh0eeyhzF /hKgGG8xyUQGRiDvqNbqghg6zvcU0MSHTJG60= Received: by 10.86.79.19 with SMTP id c19mr1061522fgb.5.1222414652938; Fri, 26 Sep 2008 00:37:32 -0700 (PDT) Received: by 10.86.79.10 with HTTP; Fri, 26 Sep 2008 00:37:32 -0700 (PDT) Message-ID: Date: Fri, 26 Sep 2008 09:37:32 +0200 From: "Claus Guttesen" To: "Danny Braniss" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 07:37:35 -0000 > There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas? Can you compare performanc with tcp? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 08:18:10 2008 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 024AE1065698 for ; Fri, 26 Sep 2008 08:18:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id A25EA8FC26 for ; Fri, 26 Sep 2008 08:18:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA06.westchester.pa.mail.comcast.net with comcast id KLFf1a0020Fqzac56LJ9rV; Fri, 26 Sep 2008 08:18:09 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA08.westchester.pa.mail.comcast.net with comcast id KLJ71a0014v8bD73ULJ7cC; Fri, 26 Sep 2008 08:18:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=shU0YM2z2wlRnnYB8ekA:9 a=-tc-E7POTj5uMGj4HiXgawpQzvYA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id CC0E0C9432; Fri, 26 Sep 2008 01:18:06 -0700 (PDT) Date: Fri, 26 Sep 2008 01:18:06 -0700 From: Jeremy Chadwick To: Danny Braniss Message-ID: <20080926081806.GA19055@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 08:18:10 -0000 On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > Hi, > There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas? 1) Network card driver changes, 2) This could be relevant, but rwatson@ will need to help determine that. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 08:43:31 2008 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 87C81106568A for ; Fri, 26 Sep 2008 08:43:31 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 354998FC21 for ; Fri, 26 Sep 2008 08:43:31 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from [192.168.0.10] by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kj8v9-000HSQ-PB; Fri, 26 Sep 2008 10:43:29 +0200 Message-ID: <48DCA0AF.5050000@kkip.pl> Date: Fri, 26 Sep 2008 10:43:27 +0200 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Jeremy Chadwick , freebsd-stable@freebsd.org References: <48DB6772.1060400@kkip.pl> <20080925130227.GA13497@icarus.home.lan> <48DB9CAA.9060807@kkip.pl> <20080925145154.GA15486@icarus.home.lan> In-Reply-To: <20080925145154.GA15486@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.9 X-Spam-Score-Int: -88 X-Exim-Version: 4.69 (build at 26-Jun-2008 18:19:28) X-Date: 2008-09-26 10:43:29 X-Connected-IP: 192.168.0.10:3134 X-Message-Linecount: 111 X-Body-Linecount: 98 X-Message-Size: 4858 X-Body-Size: 4196 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 26 Sep 2008 08:43:31 -0000 Jeremy Chadwick wrote: > On Thu, Sep 25, 2008 at 04:14:02PM +0200, Bartosz Stec wrote: > >>> Your options are: >>> >>> 1) Consider increasing it from 512M to something like 1.5GB; do not >>> increase it past that on RELENG_7, as there isn't support for more than >>> 2GB total. For example, on a 1GB memory machine, I often recommend >>> 768M. On 2GB machines, 1536M. You will need to run -CURRENT if you >>> want more. >>> >>> 2) Tune ZFS aggressively. Start by setting vfs.zfs.arc_min="16M" >>> and vfs.zfs.arc_max="64M". >>> >>> If your machine has some small amount of memory (768MB, 1GB, etc.), >>> then you probably shouldn't be using ZFS. >>> >>> >>> >> Problem occured on i386 machine with 1GB of memory and 7.1-pre (3HDD, >> 40GB, RAIDZ1). I know that i386 is highly unrecommended for ZFS, but >> it's just a home box for testing and learning purposes - I just want to >> know what I'm doing and what should I expect when I decide to put ZFS on >> server machines :) Currently, from posts on freebsd-fs, I conclude that >> even with a gigs of kmem and using AMD64, we still can experience panic >> from kmem_malloc. >> > > The i386 vs. amd64 argument is bogus, if you ask me. ZFS works on both. > amd64 is recommended because ZFS contains code that makes heavy use of > 64-bit values, and because amd64 offers large amounts of addressed > memory without disgusting hacks like PAE. > > That said -- yes, even with "gigs of kmem and using AMD64", you can > still panic due to kmem exhaustion. I have fairly decent experience > with this problem, because it haunted me for quite some time. > > A large portion of the problem is that kmem_max, on i386 and amd64 (yes, > you read that right) has a 2GB limit on RELENG_7. I repeat: a 2GB > limit, regardless of i386 or amd64. > > This limit has been increased to 512GB on CURRENT, but there are no > plans to MFC those changes, as they are too major. > > Let me tell you something I did this weekend. I had to copy literally > 200GB of data from a ZFS raidz1 pool (spread across 3 disks) to two > different places: 1) a UFS2 filesystem on a different disk, and 2) > across a gigE network to a Windows machine. I had to do this because I > was adding a disk to the vdev, which cannot be done without re-creating > the pool (this is a known problem with ZFS, and has nothing to do with > FreeBSD). > > The machine hosting the data runs RELENG_7 with amd64, and contains 4GB > of memory. However, I've accomplished the same task with only 2GB of > memory as well. > > These are the tuning settings I use: > > vm.kmem_size="1536M" > vm.kmem_size_max="1536M" > vfs.zfs.arc_min="16M" > vfs.zfs.arc_max="64M" > > The entire copying process took almost 2 hours. Not once did I > experience kmem exhaustion. I can *guarantee* that I would have crashed > the box numerous times had I not tuned the machine with the values > above. > > >> Manual tuning is hard for me because I'm not familiar >> with BSD kernel code nor kernel memory management. I'm just an end-user >> who love concepts of ZFS and wait for it to be (more) stable. Of course >> I've followed tuning guide carefully. >> > > I'm an "experienced" end-user who has very little experience with BSD > kernel code and absolutely no experience with kernel memory management. > Proper tuning is all that's needed, regardless of your knowledge set. > > Please try installing 2GB of memory in your i386 box, and then use > the exact loader.conf values I specified above. > > Thank you for hints. Yesterday I've added 512 MB memory to box (sum 1,5GB), and set vm.kmem_size and vm.kmem_size to "1024M". With pieces of 1024MB, 512MB, 256MB, 256MB available and 3 memory slots it is hard to have 2GB RAM ;) Until now it survived world cleaning/building/installing/bonnie++ benchmarkink/fs scrubing and general usage. Memory usage seems stable. If unfortunately kmem exhaustion will happen again I will experiment with ARC settings. IMHO you've explained gently a lot of zfs tuning concerns in this thread and they should be added to tuning guide - espacially explanation of ARC and prefetch settings. Thanks again! -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 09:27:10 2008 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 6EE031065692; Fri, 26 Sep 2008 09:27:10 +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 23BB68FC1E; Fri, 26 Sep 2008 09:27:09 +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 1Kj9bR-000H7t-0g; Fri, 26 Sep 2008 12:27:09 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: <20080926081806.GA19055@icarus.home.lan> References: <20080926081806.GA19055@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Fri, 26 Sep 2008 01:18:06 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 2008 12:27:08 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 09:27:10 -0000 > On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > > Hi, > > There seems to be some serious degradation in performance. > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > under 7.1 it drops to 20! > > Any ideas? > > 1) Network card driver changes, could be, but at least iperf/tcp is ok - can't get udp numbers, do you know of any tool to measure udp performance? BTW, I also checked on different hardware, and the badness is there. > > 2) This could be relevant, but rwatson@ will need to help determine > that. > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html gut feeling is that it's somewhere else: Writing 16 MB file BS Count /---- 7.0 ------/ /---- 7.1 -----/ 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s 64*512 512 0.22s 71.45MB/s 0.45s 35.41MB/s 128*512 256 0.21s 77.84MB/s 0.51s 31.34MB/s 256*512 128 0.19s 82.47MB/s 0.43s 37.22MB/s 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s Average: 75.86 33.00 the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in the measurements, but the relation are similar, good on 7.0, bad on 7.1 Cheers, danny From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 09:47:41 2008 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 4B4B91065695 for ; Fri, 26 Sep 2008 09:47:41 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [212.103.70.36]) by mx1.freebsd.org (Postfix) with ESMTP id EC1A78FC19 for ; Fri, 26 Sep 2008 09:47:30 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from 80-219-162-83.dclient.hispeed.ch ([80.219.162.83] helo=default.fsck.ch) by secure.socket.ch with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kj9uD-000Pgg-9g; Fri, 26 Sep 2008 11:47:22 +0200 Message-ID: <48DCAF74.3070900@fsck.ch> Date: Fri, 26 Sep 2008 11:46:28 +0200 From: Tobias Roth User-Agent: Thunderbird 2.0.0.16 (X11/20080919) MIME-Version: 1.0 To: Andreas Rudisch References: <48DB4E11.2060604@fsck.ch> <20080925114505.af589ce3.cyb.@gmx.net> <48DB6CC6.90402@fsck.ch> <20080925151411.5c0c4d0a.cyb.@gmx.net> In-Reply-To: <20080925151411.5c0c4d0a.cyb.@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.4 (---) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 09/25/08 15:14, Andreas Rudisch wrote: > On Thu, 25 Sep 2008 12:49:42 +0200 > Tobias Roth wrote: > >> heh, that should be RELENG_7. > > Update your source tree again and clean up the build dirs. > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#Q23.4.14.6. > > Could be caused by some left overs from a previous build. [...] Content analysis details: (-3.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.9 TVD_RCVD_IP TVD_RCVD_IP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.9 AWL AWL: From: address is in the auto white-list X-SA-Exim-Connect-IP: 80.219.162.83 X-SA-Exim-Mail-From: freebsd.lists@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false Cc: stable@freebsd.org Subject: Re: buildworld fails in csh 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, 26 Sep 2008 09:47:41 -0000 On 09/25/08 15:14, Andreas Rudisch wrote: > On Thu, 25 Sep 2008 12:49:42 +0200 > Tobias Roth wrote: > >> heh, that should be RELENG_7. > > Update your source tree again and clean up the build dirs. > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#Q23.4.14.6. > > Could be caused by some left overs from a previous build. That didn't work. What else could I try? Thanks, Tobias -- Tobias Roth || http://fsck.ch || PGP: 0xCE599B4D | God is a comedian playing to an audience too afraid to laugh. | - Voltaire From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 09:52:32 2008 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 64C73106568D for ; Fri, 26 Sep 2008 09:52:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 48DD38FC16 for ; Fri, 26 Sep 2008 09:52:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id KMDd1a0070EPchoA6MsYz3; Fri, 26 Sep 2008 09:52:32 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id KMsW1a00A4v8bD78MMsXCm; Fri, 26 Sep 2008 09:52:31 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=80Qts77T3K_gKBR54JcA:9 a=-OmQwcjttRvdMHV04IW6M1UCvTUA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 8D6ACC9437; Fri, 26 Sep 2008 02:52:30 -0700 (PDT) Date: Fri, 26 Sep 2008 02:52:30 -0700 From: Jeremy Chadwick To: Danny Braniss Message-ID: <20080926095230.GA20789@icarus.home.lan> References: <20080926081806.GA19055@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 09:52:32 -0000 On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: > > On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > > > Hi, > > > There seems to be some serious degradation in performance. > > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > > under 7.1 it drops to 20! > > > Any ideas? > > > > 1) Network card driver changes, > could be, but at least iperf/tcp is ok - can't get udp numbers, do you > know of any tool to measure udp performance? > BTW, I also checked on different hardware, and the badness is there. According to INDEX, benchmarks/iperf does UDP bandwidth testing. benchmarks/nttcp should as well. What network card is in use? If Intel, what driver version (should be in dmesg). > > 2) This could be relevant, but rwatson@ will need to help determine > > that. > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html > > gut feeling is that it's somewhere else: > > Writing 16 MB file > BS Count /---- 7.0 ------/ /---- 7.1 -----/ > 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s > 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s > 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s > 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s > 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s > 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s > 64*512 512 0.22s 71.45MB/s 0.45s 35.41MB/s > 128*512 256 0.21s 77.84MB/s 0.51s 31.34MB/s > 256*512 128 0.19s 82.47MB/s 0.43s 37.22MB/s > 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s > 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s > 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s > 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s > 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s > 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s > 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s > > Average: 75.86 33.00 > > the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in > the > measurements, but the relation are similar, good on 7.0, bad on 7.1 Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 09:59:13 2008 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 84AAC1065698 for ; Fri, 26 Sep 2008 09:59:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 2DD348FC1C for ; Fri, 26 Sep 2008 09:59:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA10.westchester.pa.mail.comcast.net with comcast id KMgT1a0080mv7h05AMzCVp; Fri, 26 Sep 2008 09:59:12 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA11.westchester.pa.mail.comcast.net with comcast id KMz01a0024v8bD73XMz08X; Fri, 26 Sep 2008 09:59:01 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=pUBjM6g3SMpyPNvdtCIA:9 a=IEEClNYn-DCY_1Ct3YsA:7 a=yJyikQBz_cww4U9JXa6tgvZN0qsA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 10ADAC9432; Fri, 26 Sep 2008 02:59:11 -0700 (PDT) Date: Fri, 26 Sep 2008 02:59:10 -0700 From: Jeremy Chadwick To: Tobias Roth Message-ID: <20080926095910.GA20964@icarus.home.lan> References: <48DB4E11.2060604@fsck.ch> <20080925114505.af589ce3.cyb.@gmx.net> <48DB6CC6.90402@fsck.ch> <20080925151411.5c0c4d0a.cyb.@gmx.net> <48DCAF74.3070900@fsck.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DCAF74.3070900@fsck.ch> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Andreas Rudisch <"cyb."@gmx.net>, stable@freebsd.org Subject: Re: buildworld fails in csh 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, 26 Sep 2008 09:59:13 -0000 On Fri, Sep 26, 2008 at 11:46:28AM +0200, Tobias Roth wrote: > On 09/25/08 15:14, Andreas Rudisch wrote: >> On Thu, 25 Sep 2008 12:49:42 +0200 >> Tobias Roth wrote: >> >>> heh, that should be RELENG_7. >> >> Update your source tree again and clean up the build dirs. >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#Q23.4.14.6. >> >> Could be caused by some left overs from a previous build. > > That didn't work. What else could I try? Did you rm -fr /usr/obj/* before rebuilding world? "That didn't work" is too ambiguous. The build is failing because it claims ICONV_CONST is undefined. ICONV_CONST is found here: $ grep -r ICONV_CONST /usr/src/contrib/tcsh /usr/src/bin/csh /usr/src/contrib/tcsh/config.h.in:#undef ICONV_CONST /usr/src/contrib/tcsh/configure:#define ICONV_CONST $am_cv_proto_iconv_arg1 /usr/src/contrib/tcsh/sh.func.c: ICONV_CONST char *src; /usr/src/bin/csh/config.h:#define ICONV_CONST const src/bin/csh/config.h declares it. The proper include files are only included if HAVE_ICONV is declared, which it is (in src/bin/csh/Makefile), as you can see from -DHAVE_ICONV. You might have to end up giving someone access to your box to solve this problem. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 10:12:52 2008 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 F336E1065687 for ; Fri, 26 Sep 2008 10:12:52 +0000 (UTC) (envelope-from chris@arnold.se) Received: from mailstore.infotropic.com (mailstore.infotropic.com [213.136.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id 441048FC1C for ; Fri, 26 Sep 2008 10:12:52 +0000 (UTC) (envelope-from chris@arnold.se) Received: (qmail 4567 invoked by uid 89); 26 Sep 2008 09:46:10 -0000 Received: from unknown (HELO ?192.168.123.35?) (chris@arnold.se@85.132.191.39) by mailstore.infotropic.com with ESMTPA; 26 Sep 2008 09:46:10 -0000 Date: Fri, 26 Sep 2008 11:46:06 +0200 (CEST) From: Christopher Arnold X-X-Sender: chris@localhost To: limguowei@gmail.com In-Reply-To: <21866833.583261222400051087.JavaMail.nabble@isper.nabble.com> Message-ID: <20080926114427.Q36664@localhost> References: <21866833.583261222400051087.JavaMail.nabble@isper.nabble.com> X-message-flag: =?ISO-8859-1?Q?Outlook_isn=B4t_compliant_with_current_standards?= =?ISO-8859-1?Q?_please_install_another_mail_client!?= MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Problems with FreeBSD 7.1 Pre-Release after Upgrade from 7.0 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, 26 Sep 2008 10:12:53 -0000 On Thu, 25 Sep 2008, limguowei@gmail.com wrote: > After cvsuping the source and recompiling the kernel from 7.0 > > pid 971 (kldstat), uid 0: exited on signal 11 (core dumped) > fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 > pid 977 (mdconfig), uid 0: exited on signal 11 (core dumped) > pid 978 (mdconfig), uid 0: exited on signal 11 (core dumped) > acpi_ec0: warning: EC done before starting event wait > pid 1371 (kldstat), uid 1001: exited on signal 11 (core dumped) > pid 4485 (kldstat), uid 0: exited on signal 11 (core dumped) > Just checking, have you rebuilt your userland too? (And i see you use fuse, you might want to rebuild that to.) /Chris -- http://www.arnold.se/chris/ From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 10:15:00 2008 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 B4FD9106569B for ; Fri, 26 Sep 2008 10:15:00 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [212.103.70.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4FCCE8FC1A for ; Fri, 26 Sep 2008 10:15:00 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from 80-219-162-83.dclient.hispeed.ch ([80.219.162.83] helo=default.fsck.ch) by secure.socket.ch with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KjALd-000Po6-MT; Fri, 26 Sep 2008 12:14:59 +0200 Message-ID: <48DCB619.9020906@fsck.ch> Date: Fri, 26 Sep 2008 12:14:49 +0200 From: Tobias Roth User-Agent: Thunderbird 2.0.0.16 (X11/20080919) MIME-Version: 1.0 To: Jeremy Chadwick References: <48DB4E11.2060604@fsck.ch> <20080925114505.af589ce3.cyb.@gmx.net> <48DB6CC6.90402@fsck.ch> <20080925151411.5c0c4d0a.cyb.@gmx.net> <48DCAF74.3070900@fsck.ch> <20080926095910.GA20964@icarus.home.lan> In-Reply-To: <20080926095910.GA20964@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.4 (---) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 09/26/08 11:59, Jeremy Chadwick wrote: > On Fri, Sep 26, 2008 at 11:46:28AM +0200, Tobias Roth wrote: >> On 09/25/08 15:14, Andreas Rudisch wrote: >>> On Thu, 25 Sep 2008 12:49:42 +0200 >>> Tobias Roth wrote: >>> >>>> heh, that should be RELENG_7. >>> Update your source tree again and clean up the build dirs. >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#Q23.4.14.6. >>> >>> Could be caused by some left overs from a previous build. >> That didn't work. What else could I try? > > Did you rm -fr /usr/obj/* before rebuilding world? "That didn't work" > is too ambiguous. [...] Content analysis details: (-3.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.9 TVD_RCVD_IP TVD_RCVD_IP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.9 AWL AWL: From: address is in the auto white-list X-SA-Exim-Connect-IP: 80.219.162.83 X-SA-Exim-Mail-From: freebsd.lists@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false Cc: Andreas Rudisch <"cyb."@gmx.net>, stable@freebsd.org Subject: Re: buildworld fails in csh 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, 26 Sep 2008 10:15:00 -0000 On 09/26/08 11:59, Jeremy Chadwick wrote: > On Fri, Sep 26, 2008 at 11:46:28AM +0200, Tobias Roth wrote: >> On 09/25/08 15:14, Andreas Rudisch wrote: >>> On Thu, 25 Sep 2008 12:49:42 +0200 >>> Tobias Roth wrote: >>> >>>> heh, that should be RELENG_7. >>> Update your source tree again and clean up the build dirs. >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#Q23.4.14.6. >>> >>> Could be caused by some left overs from a previous build. >> That didn't work. What else could I try? > > Did you rm -fr /usr/obj/* before rebuilding world? "That didn't work" > is too ambiguous. I followed the above URL and did what was suggested there. So "That didn't work" was refering to # chflags -R noschg /usr/obj/usr # rm -rf /usr/obj/usr # cd /usr/src # make cleandir # make cleandir > The build is failing because it claims ICONV_CONST is undefined. > > ICONV_CONST is found here: > > $ grep -r ICONV_CONST /usr/src/contrib/tcsh /usr/src/bin/csh > /usr/src/contrib/tcsh/config.h.in:#undef ICONV_CONST > /usr/src/contrib/tcsh/configure:#define ICONV_CONST $am_cv_proto_iconv_arg1 > /usr/src/contrib/tcsh/sh.func.c: ICONV_CONST char *src; > /usr/src/bin/csh/config.h:#define ICONV_CONST const > > src/bin/csh/config.h declares it. > > The proper include files are only included if HAVE_ICONV is declared, > which it is (in src/bin/csh/Makefile), as you can see from -DHAVE_ICONV. Nothing seems to be wrong here really. > You might have to end up giving someone access to your box to solve this > problem. That will not be possible. I'll wipe out /usr/src as well and re-cvsup, then build from single user mode for minimal intervention by shells and environments and see whether that might help. Thanks, Tobias -- Tobias Roth || http://fsck.ch || PGP: 0xCE599B4D | Percusive Maintenance: | The art of tuning or repairing equipment by hitting it. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 10:24:04 2008 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 DB311106569C for ; Fri, 26 Sep 2008 10:24:04 +0000 (UTC) (envelope-from chris@arnold.se) Received: from mailstore.infotropic.com (mailstore.infotropic.com [213.136.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47D1E8FC16 for ; Fri, 26 Sep 2008 10:24:04 +0000 (UTC) (envelope-from chris@arnold.se) Received: (qmail 11157 invoked by uid 89); 26 Sep 2008 10:24:03 -0000 Received: from unknown (HELO ?192.168.123.35?) (chris@arnold.se@85.132.191.39) by mailstore.infotropic.com with ESMTPA; 26 Sep 2008 10:24:03 -0000 Date: Fri, 26 Sep 2008 12:24:00 +0200 (CEST) From: Christopher Arnold X-X-Sender: chris@localhost To: freebsd-stable@freebsd.org Message-ID: <20080926115740.H36760@localhost> X-message-flag: =?ISO-8859-1?Q?Outlook_isn=B4t_compliant_with_current_standards?= =?ISO-8859-1?Q?_please_install_another_mail_client!?= MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: ssh problems when upgrading 5.5 to 6.3 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, 26 Sep 2008 10:24:05 -0000 Hi all, i'm trying to remotely upgrade a 5.5 system to 6.3 and have run into an issue with userland not matching my kernel. (Yes i know i am a bad guy for even trying to do a upgrade remote, but this is a dress rehersal for future such scenarios.) Symptoms: When trying to ssh to the machine with a 6.3 kernel and a 5.5 userland i get: % ssh machine Password: Warning: no access to tty (Bad file descriptor). Thus no job control in this shell. And then the motd and after the session is stuck. I can manage to do "ssh machine csh" i dont get a prompt but are able to execute commands. A tail of /var/log/messages reveal: Sep 26 12:00:36 web sshd[3012]: error: openpty: Invalid argument Sep 26 12:00:36 web sshd[3015]: error: session_pty_req: session 0 alloc failed ok lets do a "su" and reboot the machine (I have used nextboot to try the new kernel out), but su gives me a "su: Sorry" straight away. Looking in messages i see: Sep 26 11:14:14 web su: in prompt_echo_off(): tcgetattr(): Operation not supported Sep 26 11:14:14 web su: BAD SU chris to root on tty Ok, i'm totally aware that this is related to running the wrong userland for the wrong kernel. But i still would like to explore this problem a bit. Thus these questions: A) Is this issue related to going directly from 5.5 to 6.3? That is could i have gotten away without theese problems by upgrading to 6.0 first and then head on to 6.3? B) do you thing i would have been able to do an "su" or even login if i have had /usr/ports/misc/compat5x installed? C) Does anyone have a creative way to reboot the machine remote? You all where waiting for this, wasn't you ;-) (Or is there a way to get su to survive long enough to do a reebot?) /Chris From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 10:30:23 2008 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 B375D106568F for ; Fri, 26 Sep 2008 10:30:23 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from mail.webreality.org (mailserver.webreality.org [217.75.141.5]) by mx1.freebsd.org (Postfix) with ESMTP id 243E58FC19 for ; Fri, 26 Sep 2008 10:30:22 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from [10.0.1.101] (gw1.sofiasoftsolutions.com [195.34.104.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.webreality.org (Postfix) with ESMTP id 59CCD1522CFE for ; Fri, 26 Sep 2008 13:12:20 +0300 (EEST) Message-ID: <48DCB57E.8000001@lozenetz.org> Date: Fri, 26 Sep 2008 13:12:14 +0300 From: Anton - Valqk User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-HostIT-MailScanner-Information: Please contact the ISP for more information X-HostIT-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-HostIT-MailScanner-From: lists@lozenetz.org Cc: Subject: HELP DEBUG: FreeBSD 6.3-RELEASE-p3 TIMEOUT - WRITE_DMA + other strange behaviour! 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, 26 Sep 2008 10:30:23 -0000 Hello, I have a VERY strange behaving 6-3p3 with DMA tmieouts and network cards 'dropping traffic'. Following is the explanation of hardware and the thinga that are happening. The machine is DELL optiplex PII 300mHZ with 512RAM. It has 3 NICs: fxp0: flags=8843 mtu 1500 options=8 inet 7.8.9.10 netmask 0xfffff000 broadcast 7.8.9.255 ether 00:91:21:16:14:bf media: Ethernet autoselect (100baseTX ) status: active rl0: flags=8843 mtu 1500 options=8 inet 8.9.10.11 netmask 0xffffffe0 broadcast 8.9.10.255 ether 00:02:44:73:2a:fa media: Ethernet autoselect (100baseTX ) status: active xl0: flags=8843 mtu 1500 options=9 inet 192.168.123.2 netmask 0xffffff00 broadcast 192.168.123.255 inet 192.168.123.5 netmask 0xffffff00 broadcast 192.168.123.255 inet 192.168.123.6 netmask 0xffffff00 broadcast 192.168.123.255 ether 00:c0:4f:20:66:a3 media: Ethernet autoselect (100baseTX ) status: active fxp0 and rl0 are external links to the world and are plugged into pci slots xl0 is the internal interface and is integrated on motherboard. It also has 1 PROMISE ULTRA133 ATA pci IDE controller plugged into the pci slot. It has 5 disks in it - 4 connected to the PROMISE card and 1 to the motherboard ide. they are as follows: ad0 and ad6 are two identical hitachi disks in gmirror for the system and a partition that I keep backups on. ad4, ad5 and ad7 are storage disks - seagates 500GB 8mb cache that I keep isos etc files on and are the problematic (maybe because of high traffic operations compared to the other two?). What is the problem: Actually there are two problems: 1. I get a lot of dma times outs. mostly on ad5 and ad7 where I keep files over 4-5MBs and write/read very often with 3-6-8MB/s from the disk. I don't use ad4 so I can not tell if there's gona be timeous but I suppose there will (currently has linux partitions on it and is not mounted). I get these errors: dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=5554848 dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=5914112 dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=14924096 dmesg.today:ad7: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=374303456 dmesg.today:ad7: FAILURE - WRITE_DMA48 status=51 error=10 LBA=374303456 dmesg.today:g_vfs_done():ad7[WRITE(offset=191643369472, length=131072)]error = 5 dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50757760 dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50760192 dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=12032 dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50769792 strange thing is that I'm seeing the g_vfs_done just recently and this problem is from the very start of this hardware setup of the machine. The machine used to work with two hitachi disks connected to the ad0 and ad1 (integrated ide) and only one - xl0 - nic perfectly. The problems started when I plugged in the PROMISE and other nic cards and started using it as router, fileserver and backup server (each in separate jail, except the pf firewall). 2. The other strange issue is that when (I guess) it starts timeouting *sometimes* not everytime I'm loosing connection to xl0 or fxp0 (sometimes the rl0 works and accepts connections from the outside, sometimes - not). When I go to the machine and plug a monitor - there are no messages from kernel, no logs in /var/log/messages or debug - noting. Stange thing is that I ping host from the local net and it time outs, ifconfig shows that interface is connected at fd 100mbit and everyting seems ok. I've tried ifconfig xl0 down up but doesn't help, tried plugging out the cable and it got connected but not packets passed - timeout again! I've rebooted and nic came up. These 'drops' became more and more common recently and last night I wasn't able to login for about an hour and after that the machine came back up again by itself!!!that's in the lan - but it wasn't accessible at all from the outside - strange thins is that it replied to ping but I wasn't able to even open the ssh port connection and the nat wasn't working?! After that I've remembered that at this time I have a cronjob started for about an hour that fetches into a file a online radio cast for an hour.... wired!!! it also have rtorrent, apache22, samba (in a jail) runing. some output from it can be found here: http://valqk.ath.cx/tmp/dmesg http://valqk.ath.cx/tmp/vmstat http://valqk.ath.cx/tmp/smartctl please give any ideas/hints/solutions! thanks a lot to everyone! cheers, valqk. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 10:38:42 2008 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 7BE1D106569B for ; Fri, 26 Sep 2008 10:38:42 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp01.cdmon.com (smtp01.cdmon.com [212.36.75.232]) by mx1.freebsd.org (Postfix) with ESMTP id 42CF88FC2E for ; Fri, 26 Sep 2008 10:38:42 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) by smtp01.cdmon.com (Postfix) with ESMTP id 7EC41F7D62; Fri, 26 Sep 2008 12:22:56 +0200 (CEST) Message-ID: <48DCB7FF.1000604@minibofh.org> Date: Fri, 26 Sep 2008 12:22:55 +0200 From: Jordi Espasa Clofent User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Rare problems in upgrade process (corrupted FS?) 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, 26 Sep 2008 10:38:42 -0000 Hi all, I'm traying to update a FreeBSD server box from 6.3p11 to 7.0 and I've found a rare problems. 1) I do the sync process with csup(1); next I go into /usr/src/sys/amd64/conf to edit the GENERIC file (I use a custimized kernels) and this file doesn't exists. Mmmm.... I decide to repeat the process againt other cvsup mirror but I get the same results: GENERIC file isn't there. 2) I go to FreeBSD CVSWeb , locate the GENERIC file under the 7_0 tag, copy and paste. Yes, I know: a very nasty process. The big problem appears when I try to do 'make cleandir' and others. I get the next outputs: # pwd /usr/src # make cleandir make: don't know how to make cleandir. Stop # make buildworld make: don't know how to make buildworld. Stop # ls -l /usr/bin/make -r-xr-xr-x 1 root wheel 351024 Aug 18 13:19 /usr/bin/make # file /usr/bin/make /usr/bin/make: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), for FreeBSD 6.3, statically linked, stripped ¿?¿?¿?¿ * I reboot the machine (because of I suspect a very weird FS problem), boot in single user mode and do a 'fsck -fy'. Effectively, the fsck(8) found and repair several errors. Epecially, one error claims my attention: SUPERBLOCK. * After the theorical FS reparation I'm again in the point 1. ¿Any clues? -- Thanks, Jordi Espasa Clofent From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 10:47:34 2008 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 6F951106568A for ; Fri, 26 Sep 2008 10:47:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 54F568FC08 for ; Fri, 26 Sep 2008 10:47:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id KNNb1a00C0b6N64A1NnEbX; Fri, 26 Sep 2008 10:47:14 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id KNnY1a0054v8bD78PNnZjQ; Fri, 26 Sep 2008 10:47:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=TjwJzeWVk3IA:10 a=yqOlm6tamNsA:10 a=QycZ5dHgAAAA:8 a=IZi5DtbZEr1s2HTaYrAA:9 a=9tpjFpv4-tXV8Y3hOiMA:7 a=xoHNCO4gei0vjgdv8Pj4pcdGjO8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id AAFFBC9432; Fri, 26 Sep 2008 03:47:32 -0700 (PDT) Date: Fri, 26 Sep 2008 03:47:32 -0700 From: Jeremy Chadwick To: Jordi Espasa Clofent Message-ID: <20080926104732.GA22641@icarus.home.lan> References: <48DCB7FF.1000604@minibofh.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DCB7FF.1000604@minibofh.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Rare problems in upgrade process (corrupted FS?) 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, 26 Sep 2008 10:47:34 -0000 On Fri, Sep 26, 2008 at 12:22:55PM +0200, Jordi Espasa Clofent wrote: > Hi all, > > I'm traying to update a FreeBSD server box from 6.3p11 to 7.0 and I've > found a rare problems. > > 1) I do the sync process with csup(1); next I go into > /usr/src/sys/amd64/conf to edit the GENERIC file (I use a custimized > kernels) and this file doesn't exists. Mmmm.... I decide to repeat the > process againt other cvsup mirror but I get the same results: GENERIC > file isn't there. > > 2) I go to FreeBSD CVSWeb , locate the GENERIC file under the 7_0 tag, > copy and paste. Yes, I know: a very nasty process. The big problem > appears when I try to do 'make cleandir' and others. I get the next > outputs: > > # pwd > /usr/src > # make cleandir > make: don't know how to make cleandir. Stop > # make buildworld > make: don't know how to make buildworld. Stop > # ls -l /usr/bin/make > -r-xr-xr-x 1 root wheel 351024 Aug 18 13:19 /usr/bin/make > # file /usr/bin/make > /usr/bin/make: ELF 64-bit LSB executable, AMD x86-64, version 1 > (FreeBSD), for FreeBSD 6.3, statically linked, stripped Looks to me like you have no /usr/src/Makefile. > * After the theorical FS reparation I'm again in the point 1. None of the information you provided in your above output, however, shows anything about the filesystem (other than /usr/bin/make). But this sounds honestly like some sort of corrupted supdb, or a cvsup mirror that's broken. I would do the following: rm -fr /usr/src/* rm -fr /var/db/sup/src-all csup -h -L 2 -g /usr/share/examples/stable-supfile I can assure you /sys/amd64/conf/GENERIC exists, and is on the cvsup mirrors. > * I reboot the machine (because of I suspect a very weird FS problem), > boot in single user mode and do a 'fsck -fy'. Effectively, the fsck(8) > found and repair several errors. Epecially, one error claims my > attention: SUPERBLOCK. Superblock problems wouldn't explain this; there are hundreds of superblocks available (you wouldn't be able to use your machine if they were all horked). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 10:49:46 2008 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 B4AD7106569A for ; Fri, 26 Sep 2008 10:49:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8408FC25 for ; Fri, 26 Sep 2008 10:49:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA05.westchester.pa.mail.comcast.net with comcast id KNdS1a00B0xGWP855Npl1l; Fri, 26 Sep 2008 10:49:45 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA12.westchester.pa.mail.comcast.net with comcast id KNpk1a0084v8bD73YNplmP; Fri, 26 Sep 2008 10:49:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=FLvhOX2l2PChZxcUq6MA:9 a=yIxuqwrlEdmwyTuNbGwA:7 a=tFBpyZjAAdhd-MKaFFL0jq_q8R4A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 6A327C9432; Fri, 26 Sep 2008 03:49:44 -0700 (PDT) Date: Fri, 26 Sep 2008 03:49:44 -0700 From: Jeremy Chadwick To: Tobias Roth Message-ID: <20080926104944.GA22733@icarus.home.lan> References: <48DB4E11.2060604@fsck.ch> <20080925114505.af589ce3.cyb.@gmx.net> <48DB6CC6.90402@fsck.ch> <20080925151411.5c0c4d0a.cyb.@gmx.net> <48DCAF74.3070900@fsck.ch> <20080926095910.GA20964@icarus.home.lan> <48DCB619.9020906@fsck.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DCB619.9020906@fsck.ch> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Andreas Rudisch <"cyb."@gmx.net>, stable@freebsd.org Subject: Re: buildworld fails in csh 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, 26 Sep 2008 10:49:46 -0000 On Fri, Sep 26, 2008 at 12:14:49PM +0200, Tobias Roth wrote: > On 09/26/08 11:59, Jeremy Chadwick wrote: >> On Fri, Sep 26, 2008 at 11:46:28AM +0200, Tobias Roth wrote: >>> On 09/25/08 15:14, Andreas Rudisch wrote: >>>> On Thu, 25 Sep 2008 12:49:42 +0200 >>>> Tobias Roth wrote: >>>> >>>>> heh, that should be RELENG_7. >>>> Update your source tree again and clean up the build dirs. >>>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#Q23.4.14.6. >>>> >>>> Could be caused by some left overs from a previous build. >>> That didn't work. What else could I try? >> >> Did you rm -fr /usr/obj/* before rebuilding world? "That didn't work" >> is too ambiguous. > > I followed the above URL and did what was suggested there. So "That > didn't work" was refering to > > # chflags -R noschg /usr/obj/usr > # rm -rf /usr/obj/usr > # cd /usr/src > # make cleandir > # make cleandir > >> The build is failing because it claims ICONV_CONST is undefined. >> >> ICONV_CONST is found here: >> >> $ grep -r ICONV_CONST /usr/src/contrib/tcsh /usr/src/bin/csh >> /usr/src/contrib/tcsh/config.h.in:#undef ICONV_CONST >> /usr/src/contrib/tcsh/configure:#define ICONV_CONST $am_cv_proto_iconv_arg1 >> /usr/src/contrib/tcsh/sh.func.c: ICONV_CONST char *src; >> /usr/src/bin/csh/config.h:#define ICONV_CONST const >> >> src/bin/csh/config.h declares it. >> >> The proper include files are only included if HAVE_ICONV is declared, >> which it is (in src/bin/csh/Makefile), as you can see from -DHAVE_ICONV. > > Nothing seems to be wrong here really. Being as I just rebuilt world only 2 days ago and I did not run into this problem, I'm concluding the issue must be with your system. :-) It's possible you've done some bizarre tuning in /etc/make.conf or /etc/src.conf which is somehow breaking the build. >> You might have to end up giving someone access to your box to solve this >> problem. > > That will not be possible. > > I'll wipe out /usr/src as well and re-cvsup, then build from single user > mode for minimal intervention by shells and environments and see whether > that might help. I don't see how booting single-user is going to help with any of this. And do not forget to remove /var/db/sup/src-all if you remove all of /usr/src. People often forget this fact. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 11:11:45 2008 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 ACAA7106568A for ; Fri, 26 Sep 2008 11:11:45 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 56FEB8FC13 for ; Fri, 26 Sep 2008 11:11:45 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA01.westchester.pa.mail.comcast.net with comcast id KNCQ1a0020cZkys51PBkMr; Fri, 26 Sep 2008 11:11:44 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA10.westchester.pa.mail.comcast.net with comcast id KPBj1a00D4v8bD73WPBjMV; Fri, 26 Sep 2008 11:11:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=E3qIknzw5VgA:10 a=s03-oqJxaoQA:10 a=6I5d2MoRAAAA:8 a=XscjgUWWAAAA:8 a=QycZ5dHgAAAA:8 a=VZz8KL_LkZgSmSNDkSgA:9 a=wiBJNpix247FTMlOJcUA:7 a=rzxItvo4V849P2j0dICAc63cVo8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 2A510C9432; Fri, 26 Sep 2008 04:11:43 -0700 (PDT) Date: Fri, 26 Sep 2008 04:11:43 -0700 From: Jeremy Chadwick To: Anton - Valqk Message-ID: <20080926111143.GB22733@icarus.home.lan> References: <48DCB57E.8000001@lozenetz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DCB57E.8000001@lozenetz.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org Subject: Re: HELP DEBUG: FreeBSD 6.3-RELEASE-p3 TIMEOUT - WRITE_DMA + other strange behaviour! 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, 26 Sep 2008 11:11:45 -0000 On Fri, Sep 26, 2008 at 01:12:14PM +0300, Anton - Valqk wrote: > Hello, > I have a VERY strange behaving 6-3p3 with DMA tmieouts and network cards > 'dropping traffic'. The disk errors you see are well-known, but the reasons for them happening differ per person. Some people replace cables and the problem goes away. Others change controller cards. Others found no solution and went to Linux. http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting Here's some facts: 1) The LBAs reported to have problems are scattered, which indicates to me there are probably not bad blocks on your disks, 2) You have two separate disks showing the above behaviour, decreasing the probability of it being bad blocks/sectors, 3) Your dmesg.today doesn't include timestamps, so I have to assume the problems all happen at once or within short moments of one another, rather than at random moments throughout a 24 hour period, > strange thing is that I'm seeing the g_vfs_done just recently and this > problem is from the very start of this hardware setup of the machine. I believe the g_vfs_done issues can either be attributed to the disk errors you're seeing, or oddities with gmirror/GEOM. I've seen people report this before, and GEOM often spits back an error on an index/offset which seems way too large for it to be realistic. > The machine used to work with two hitachi disks connected to the ad0 and > ad1 (integrated ide) and only one - xl0 - nic perfectly. > The problems started when I plugged in the PROMISE and other nic cards > and started using it as router, fileserver and backup server (each in > separate jail, except the pf firewall). > ... > > 2. The other strange issue is that when (I guess) it starts timeouting > *sometimes* not everytime I'm loosing connection to xl0 or fxp0 > (sometimes the rl0 works and accepts connections from the outside, > sometimes - not). When I go to the machine and plug a monitor - there > are no messages from kernel, no logs in /var/log/messages or debug - > noting. Stange thing is that I ping host from the local net and it time > outs, ifconfig shows that interface is connected at fd 100mbit and > everyting seems ok. I've tried ifconfig xl0 down up but doesn't help, > tried plugging out the cable and it got connected but not packets passed > - timeout again! I've looked at your dmesg and vmstat output, and I have a feeling the problem is an obvious one. Your system has no APIC (this is not a typo), so your system *must* share IRQs. You have ***four*** devices on IRQ 11: a USB controller, your fxp0 card, your rl0 card, and your xl0 card. > http://valqk.ath.cx/tmp/dmesg > http://valqk.ath.cx/tmp/vmstat > http://valqk.ath.cx/tmp/smartctl > > please give any ideas/hints/solutions! I would recommend you start yanking PCI cards out of the system and see which solve the problem. You did state once you added the Promise card (which makes your system have FIVE PCI cards in it?!? Sheesh) the problems began. I can't imagine you'll have a stable system with that many cards in the box all sharing a single IRQ -- especially on a board that old. I'd recommend decreasing the amount of cards you have in that system, or get a motherboard that has an APIC and preferably some reliable on-board networking (read: Intel chips). Toss the rl0 card if possible, and consider replacing the Promise controller with a different one. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 11:13:18 2008 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 C1D93106572B; Fri, 26 Sep 2008 11:13:18 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id 5510C8FC1A; Fri, 26 Sep 2008 11:13:18 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m8QBDDhV010986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 21:13:15 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m8QBDDHS011116; Fri, 26 Sep 2008 21:13:13 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m8QBDDFc011115; Fri, 26 Sep 2008 21:13:13 +1000 (EST) (envelope-from peter) Date: Fri, 26 Sep 2008 21:13:13 +1000 From: Peter Jeremy To: Jordi Espasa Clofent Message-ID: <20080926111313.GA7231@server.vk2pj.dyndns.org> References: <48DCB7FF.1000604@minibofh.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <48DCB7FF.1000604@minibofh.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Rare problems in upgrade process (corrupted FS?) 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, 26 Sep 2008 11:13:18 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Sep-26 12:22:55 +0200, Jordi Espasa Clofent = wrote: >1) I do the sync process with csup(1); next I go into=20 >/usr/src/sys/amd64/conf to edit the GENERIC file (I use a custimized=20 >kernels) and this file doesn't exists. You might like to check your CVSup site against http://www.mavetju.org/unix/freebsd-mirrors/ to confirm it is updating correctly. GENERIC should exist. >* I reboot the machine (because of I suspect a very weird FS problem),=20 >boot in single user mode and do a 'fsck -fy'. Effectively, the fsck(8)=20 >found and repair several errors. Epecially, one error claims my=20 >attention: SUPERBLOCK. It might have been useful if you had kept a record of the exact messages. If you repeat the fsck, does it now report any problems? If you are using an up-to-date CVSup mirror, my next suggestion would be hardware problems. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjcw8kACgkQ/opHv/APuIeHogCfSQx1aI/iHPhd8/ZaTT2JrIsB BWwAoIj+1G/0xKDfVkW8KqDvSsrKVcZj =wZ13 -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 11:23:23 2008 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 C8BEF1065694 for ; Fri, 26 Sep 2008 11:23:23 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.cdmon.com (smtp02.cdmon.com [212.36.74.229]) by mx1.freebsd.org (Postfix) with ESMTP id 8E1E88FC20 for ; Fri, 26 Sep 2008 11:23:23 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) by smtp02.cdmon.com (Postfix) with ESMTP id 545F345F27 for ; Fri, 26 Sep 2008 13:23:20 +0200 (CEST) Message-ID: <48DCC620.9010809@minibofh.org> Date: Fri, 26 Sep 2008 13:23:12 +0200 From: Jordi Espasa Clofent User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <48DCB7FF.1000604@minibofh.org> <20080926104732.GA22641@icarus.home.lan> In-Reply-To: <20080926104732.GA22641@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Rare problems in upgrade process (corrupted FS?) 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, 26 Sep 2008 11:23:23 -0000 > I would do the following: > > rm -fr /usr/src/* > rm -fr /var/db/sup/src-all > csup -h -L 2 -g /usr/share/examples/stable-supfile I've done it. But the results are, at least, curious... # csup -h cvsup.de.FreeBSD.org -L 2 -g /usr/share/examples/cvsup/stable-supfile Parsing supfile "/usr/share/examples/cvsup/stable-supfile" Connecting to cvsup.de.FreeBSD.org Connected to 212.19.57.134 Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Shutting down connection to server Finished successfully # cd /usr/src ; ls -la total 0 Anythings exists now in /usr/src. I've tried again using another mirror and cvsup(1) instead of csup(1). Same results: nothing in /usr/src. It's desconcerting.... > I can assure you /sys/amd64/conf/GENERIC exists, and is on the cvsup > mirrors. Yes, of course. I've checked it from cvsweb. > Superblock problems wouldn't explain this; there are hundreds of > superblocks available (you wouldn't be able to use your machine if they > were all horked). I've supposed it; your words confirm it. -- Thanks, Jordi Espasa Clofent From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 11:43:12 2008 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 DE1ED1065678 for ; Fri, 26 Sep 2008 11:43:12 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 5780E8FC0C for ; Fri, 26 Sep 2008 11:43:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m8QBh9gY016665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 21:43:10 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m8QBh9gm011274; Fri, 26 Sep 2008 21:43:09 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m8QBh9KX011273; Fri, 26 Sep 2008 21:43:09 +1000 (EST) (envelope-from peter) Date: Fri, 26 Sep 2008 21:43:09 +1000 From: Peter Jeremy To: Jordi Espasa Clofent Message-ID: <20080926114309.GL15376@server.vk2pj.dyndns.org> References: <48DCB7FF.1000604@minibofh.org> <20080926104732.GA22641@icarus.home.lan> <48DCC620.9010809@minibofh.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ekVaZR3ysCuYLl6k" Content-Disposition: inline In-Reply-To: <48DCC620.9010809@minibofh.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Rare problems in upgrade process (corrupted FS?) 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, 26 Sep 2008 11:43:13 -0000 --ekVaZR3ysCuYLl6k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Sep-26 13:23:12 +0200, Jordi Espasa Clofent = wrote: >Connecting to cvsup.de.FreeBSD.org Edwin's script reports this as up-to-date. ># cd /usr/src ; ls -la >total 0 But something is obviously wrong. Can you post your supfile please. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --ekVaZR3ysCuYLl6k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjcys0ACgkQ/opHv/APuIdp8QCbBaomQ8kYkOd9Vt3P996wnphY 2l8Anjq9Yec0AeONQbRZfmg4joUNeqft =cBkR -----END PGP SIGNATURE----- --ekVaZR3ysCuYLl6k-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 11:54:36 2008 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 3F6EF10656B0 for ; Fri, 26 Sep 2008 11:54:36 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id DD82A8FC1B for ; Fri, 26 Sep 2008 11:54:33 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA01.westchester.pa.mail.comcast.net with comcast id KNt21a0060SCNGk51PuZjJ; Fri, 26 Sep 2008 11:54:33 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA09.westchester.pa.mail.comcast.net with comcast id KPuY1a00C4v8bD73VPuYnZ; Fri, 26 Sep 2008 11:54:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=TjwJzeWVk3IA:10 a=yqOlm6tamNsA:10 a=QycZ5dHgAAAA:8 a=K2p-JP_KUzUFdZVgUpwA:9 a=UniF3XM_qgVTwtqTO3QA:7 a=QOcDMek0KYW2z2vnVsxKSc1Si7kA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 39B5DC9432; Fri, 26 Sep 2008 04:54:32 -0700 (PDT) Date: Fri, 26 Sep 2008 04:54:32 -0700 From: Jeremy Chadwick To: Jordi Espasa Clofent Message-ID: <20080926115432.GA24011@icarus.home.lan> References: <48DCB7FF.1000604@minibofh.org> <20080926104732.GA22641@icarus.home.lan> <48DCC620.9010809@minibofh.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DCC620.9010809@minibofh.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Rare problems in upgrade process (corrupted FS?) 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, 26 Sep 2008 11:54:36 -0000 On Fri, Sep 26, 2008 at 01:23:12PM +0200, Jordi Espasa Clofent wrote: >> I would do the following: >> >> rm -fr /usr/src/* >> rm -fr /var/db/sup/src-all >> csup -h -L 2 -g /usr/share/examples/stable-supfile > > I've done it. But the results are, at least, curious... > > # csup -h cvsup.de.FreeBSD.org -L 2 -g > /usr/share/examples/cvsup/stable-supfile > Parsing supfile "/usr/share/examples/cvsup/stable-supfile" > Connecting to cvsup.de.FreeBSD.org > Connected to 212.19.57.134 > Server software version: SNAP_16_1h > Negotiating file attribute support > Exchanging collection information > Establishing multiplexed-mode data connection > Running > Updating collection src-all/cvs > Shutting down connection to server > Finished successfully > > # cd /usr/src ; ls -la > total 0 What's df -k have to say about this? This is truly bizarre. Can you truss the csup process? Something like this should work: truss -o truss.out -s 256 csup {...flags from above...} Then put truss.out up somewhere where we can get to it? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 12:02:07 2008 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 CF387106568B for ; Fri, 26 Sep 2008 12:02:07 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 47D5C8FC26 for ; Fri, 26 Sep 2008 12:02:06 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id m8QC1dsY002248; Fri, 26 Sep 2008 13:01:39 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KjC0x-0007HE-Oi; Fri, 26 Sep 2008 13:01:39 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id m8QC1dn7003398; Fri, 26 Sep 2008 13:01:39 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id m8QC1dNH003397; Fri, 26 Sep 2008 13:01:39 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Danny Braniss In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 26 Sep 2008 13:01:38 +0100 Message-Id: <1222430498.2993.1.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-hackers@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 12:02:07 -0000 On Fri, 2008-09-26 at 10:04 +0300, Danny Braniss wrote: > Hi, > There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas? The scheduler has been changed to ULE, and NFS has historically been very sensitive to changes like that. You could try switching back to the 4BSD scheduler and seeing if that makes a difference. If it does, toggling PREEMPTION would also be interesting to see the results of. Gavin From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 12:12:11 2008 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 67882106568E for ; Fri, 26 Sep 2008 12:12:11 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.cdmon.com (smtp02.cdmon.com [212.36.74.229]) by mx1.freebsd.org (Postfix) with ESMTP id 27EB58FC14 for ; Fri, 26 Sep 2008 12:12:11 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from jespasac.cdmon.com (62.Red-217-126-43.staticIP.rima-tde.net [217.126.43.62]) by smtp02.cdmon.com (Postfix) with ESMTP id A838145EA0 for ; Fri, 26 Sep 2008 14:12:09 +0200 (CEST) Message-ID: <48DCD198.2020308@minibofh.org> Date: Fri, 26 Sep 2008 14:12:08 +0200 From: Jordi Espasa Clofent User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <48DCB7FF.1000604@minibofh.org> <20080926104732.GA22641@icarus.home.lan> <48DCC620.9010809@minibofh.org> <20080926115432.GA24011@icarus.home.lan> In-Reply-To: <20080926115432.GA24011@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Rare problems in upgrade process (corrupted FS?) [SOLVED] 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, 26 Sep 2008 12:12:11 -0000 Finally I've modified the stable-supfile TAG from *default release=cvs tag=RELENG_7_0 to *default release=cvs tag=RELENG_7 and... voilà!... it works! I've interrupted the csup process (^C) and change again the tag to *default release=cvs tag=RELENG_7_0 and it works perfecty. Maybe it's so stupid as the first tag was miss-typed... but I think not. I checked it several times. I'ts solved, but I don't understand yet. -- Thanks, Jordi Espasa Clofent From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 12:13:34 2008 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 576F4106568D for ; Fri, 26 Sep 2008 12:13:34 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from mail.webreality.org (mailserver.webreality.org [217.75.141.5]) by mx1.freebsd.org (Postfix) with ESMTP id 8D55D8FC1B for ; Fri, 26 Sep 2008 12:13:33 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from [10.0.1.101] (gw1.sofiasoftsolutions.com [195.34.104.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.webreality.org (Postfix) with ESMTP id ECD121522D14; Fri, 26 Sep 2008 15:13:26 +0300 (EEST) Message-ID: <48DCD1DF.6010203@lozenetz.org> Date: Fri, 26 Sep 2008 15:13:19 +0300 From: Anton - Valqk User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: stable@freebsd.org References: <48DCB57E.8000001@lozenetz.org> In-Reply-To: <48DCB57E.8000001@lozenetz.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-HostIT-MailScanner-Information: Please contact the ISP for more information X-HostIT-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-HostIT-MailScanner-From: lists@lozenetz.org Cc: peterjeremy@optushome.com.au, Jeremy Chadwick Subject: Re: HELP DEBUG: FreeBSD 6.3-RELEASE-p3 TIMEOUT - WRITE_DMA + other strange behaviour! 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, 26 Sep 2008 12:13:34 -0000 Thanks Jeremy and Peter, you are right that the machine has *lots* ot hardware in it, I was thinking of the power supply as a reason and measured the 5 and 12 volts - seemd to be ok 11.8 and 5.2 with all hardware in it. The shared irq is the one I've thought of and that's why I've posted vmstat -i to hear your opinion. [forgot to mention that I've read the wiki and next step is to patch the kernel with http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-patches/ata/files/patch-ata.diff?view=markup this patch (any bad words for this patch or could just run - nothing bad can happen?)] Yes, I have 3 nics(2 on pci) + pci ide promise, I'll get a smart switch with vlans and I'll leave just the integrated xl0 and fxp0 with both external ips on it these days, but first I'll patch the kernel if Jeremy says it won't hurt (as far as I saw just a timeout is moved from hardcoded value to a sysctl?)... I have another promise card that is a raid controller, but when I've started looking for one I've asked here and there were answers for PROMISE ULTRA ATA133 for being a good card for my freebsd ( http://docs.freebsd.org/cgi/getmsg.cgi?fetch=290848+0+archive/2008/freebsd-stable/20080316.freebsd-stable ) (hmm, just saw that Jeremy pointed out promise card: 'Their Ultra133 TX2 card works fine on 33MHz PCI bus machines; don't worry about the card being 66MHz, it will downthrottle correctly.') so maybe the problem will be solved if I leave just two nics and no rl0... Actually I'm using 6.3 here because I didn't wanted this to happen and I was ware of such problems happening on 7-current.... So test must be done... pls just answer about the patch will it be helpful or I should try: 1. remove rl0 and run only one isp for the test. 2. replace the ultra 133 card with another one. 3. try to replace the ATA100 cables (the one with 80 wires) with an older ones with only 40 cabels? 4. ? anything else? Anton - Valqk wrote: > Hello, > I have a VERY strange behaving 6-3p3 with DMA tmieouts and network cards > 'dropping traffic'. > Following is the explanation of hardware and the thinga that are happening. > The machine is DELL optiplex PII 300mHZ with 512RAM. > It has 3 NICs: > fxp0: flags=8843 mtu 1500 > options=8 > inet 7.8.9.10 netmask 0xfffff000 broadcast 7.8.9.255 > ether 00:91:21:16:14:bf > media: Ethernet autoselect (100baseTX ) > status: active > rl0: flags=8843 mtu 1500 > options=8 > inet 8.9.10.11 netmask 0xffffffe0 broadcast 8.9.10.255 > ether 00:02:44:73:2a:fa > media: Ethernet autoselect (100baseTX ) > status: active > xl0: flags=8843 mtu 1500 > options=9 > inet 192.168.123.2 netmask 0xffffff00 broadcast 192.168.123.255 > inet 192.168.123.5 netmask 0xffffff00 broadcast 192.168.123.255 > inet 192.168.123.6 netmask 0xffffff00 broadcast 192.168.123.255 > ether 00:c0:4f:20:66:a3 > media: Ethernet autoselect (100baseTX ) > status: active > fxp0 and rl0 are external links to the world and are plugged into pci slots > xl0 is the internal interface and is integrated on motherboard. > It also has 1 PROMISE ULTRA133 ATA pci IDE controller plugged into the > pci slot. > It has 5 disks in it - 4 connected to the PROMISE card and 1 to the > motherboard ide. > > they are as follows: > ad0 and ad6 are two identical hitachi disks in gmirror for the system > and a partition that I keep backups on. > > ad4, ad5 and ad7 are storage disks - seagates 500GB 8mb cache that I > keep isos etc files on and are the problematic (maybe because of high > traffic operations compared to the other two?). > > What is the problem: > Actually there are two problems: > 1. I get a lot of dma times outs. mostly on ad5 and ad7 where I keep > files over 4-5MBs and write/read very often with 3-6-8MB/s from the > disk. I don't use ad4 so I can not tell if there's gona be timeous but I > suppose there will (currently has linux partitions on it and is not > mounted). I get these errors: > dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=5554848 > dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=5914112 > dmesg.today:ad7: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=14924096 > dmesg.today:ad7: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=374303456 > dmesg.today:ad7: FAILURE - WRITE_DMA48 status=51 > error=10 LBA=374303456 > dmesg.today:g_vfs_done():ad7[WRITE(offset=191643369472, > length=131072)]error = 5 > dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50757760 > dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50760192 > dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=12032 > dmesg.today:ad5: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=50769792 > > strange thing is that I'm seeing the g_vfs_done just recently and this > problem is from the very start of this hardware setup of the machine. > The machine used to work with two hitachi disks connected to the ad0 and > ad1 (integrated ide) and only one - xl0 - nic perfectly. > The problems started when I plugged in the PROMISE and other nic cards > and started using it as router, fileserver and backup server (each in > separate jail, except the pf firewall). > 2. The other strange issue is that when (I guess) it starts timeouting > *sometimes* not everytime I'm loosing connection to xl0 or fxp0 > (sometimes the rl0 works and accepts connections from the outside, > sometimes - not). When I go to the machine and plug a monitor - there > are no messages from kernel, no logs in /var/log/messages or debug - > noting. Stange thing is that I ping host from the local net and it time > outs, ifconfig shows that interface is connected at fd 100mbit and > everyting seems ok. I've tried ifconfig xl0 down up but doesn't help, > tried plugging out the cable and it got connected but not packets passed > - timeout again! > I've rebooted and nic came up. These 'drops' became more and more common > recently and last night I wasn't able to login for about an hour and > after that the machine came back up again by itself!!!that's in the lan > - but it wasn't accessible at all from the outside - strange thins is > that it replied to ping but I wasn't able to even open the ssh port > connection and the nat wasn't working?! After that I've remembered that > at this time I have a cronjob started for about an hour that fetches > into a file a online radio cast for an hour.... wired!!! it also have > rtorrent, apache22, samba (in a jail) runing. > > some output from it can be found here: > http://valqk.ath.cx/tmp/dmesg > http://valqk.ath.cx/tmp/vmstat > http://valqk.ath.cx/tmp/smartctl > > > please give any ideas/hints/solutions! > > thanks a lot to everyone! > cheers, > valqk. > _______________________________________________ > 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 Sep 26 12:21:38 2008 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 E657D1065695 for ; Fri, 26 Sep 2008 12:21:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id C8E7A8FC08 for ; Fri, 26 Sep 2008 12:21:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id KNkt1a00916AWCUA5QMeHR; Fri, 26 Sep 2008 12:21:38 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id KQMd1a0044v8bD78SQMdRg; Fri, 26 Sep 2008 12:21:37 +0000 X-Authority-Analysis: v=1.0 c=1 a=3aKZLtI_pAwA:10 a=yqOlm6tamNsA:10 a=QycZ5dHgAAAA:8 a=czw6Oud3n_a6ldQQI-YA:9 a=grkk9V6CJPw2soPPfqc3rkTscK4A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id F1747C9432; Fri, 26 Sep 2008 05:21:36 -0700 (PDT) Date: Fri, 26 Sep 2008 05:21:36 -0700 From: Jeremy Chadwick To: Jordi Espasa Clofent Message-ID: <20080926122136.GA24548@icarus.home.lan> References: <48DCB7FF.1000604@minibofh.org> <20080926104732.GA22641@icarus.home.lan> <48DCC620.9010809@minibofh.org> <20080926115432.GA24011@icarus.home.lan> <48DCD198.2020308@minibofh.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <48DCD198.2020308@minibofh.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Rare problems in upgrade process (corrupted FS?) [SOLVED] 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, 26 Sep 2008 12:21:39 -0000 On Fri, Sep 26, 2008 at 02:12:08PM +0200, Jordi Espasa Clofent wrote: > Finally I've modified the stable-supfile TAG from > > *default release=cvs tag=RELENG_7_0 > > to > > *default release=cvs tag=RELENG_7 > > and... voilà!... it works! > > I've interrupted the csup process (^C) and change again the tag to > > *default release=cvs tag=RELENG_7_0 > > and it works perfecty. > > Maybe it's so stupid as the first tag was miss-typed... but I think not. > I checked it several times. > I'ts solved, but I don't understand yet. The part that doesn't make sense to me is why csup using /usr/share/example/cvsup/stable-supfile did not work for you. That file contains tag=RELENG_7. Are you modifying this file? If so, please don't. Make a copy of it somewhere and refer to that location. /root might be a good place. The next time you install world, /usr/share/examples will be overwritten, and you'll lose your changes. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 13:35:19 2008 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 0EF0C106569D; Fri, 26 Sep 2008 13:35:19 +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 B6B0F8FC27; Fri, 26 Sep 2008 13:35:18 +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 1KjDTZ-000Jqb-Bh; Fri, 26 Sep 2008 16:35:17 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: <20080926095230.GA20789@icarus.home.lan> References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Fri, 26 Sep 2008 02:52:30 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 2008 16:35:17 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 13:35:19 -0000 > On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: > > > On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > > > > Hi, > > > > There seems to be some serious degradation in performance. > > > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > > > under 7.1 it drops to 20! > > > > Any ideas? > > > > > > 1) Network card driver changes, > > could be, but at least iperf/tcp is ok - can't get udp numbers, do you > > know of any tool to measure udp performance? > > BTW, I also checked on different hardware, and the badness is there. > > According to INDEX, benchmarks/iperf does UDP bandwidth testing. I know, but I get about 1mgb, which seems somewhat low :-( > > benchmarks/nttcp should as well. > > What network card is in use? If Intel, what driver version (should be > in dmesg). bge: and bce: and intels, but haven't tested there yet. > > > > 2) This could be relevant, but rwatson@ will need to help determine > > > that. > > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html > > > > gut feeling is that it's somewhere else: > > > > Writing 16 MB file > > BS Count /---- 7.0 ------/ /---- 7.1 -----/ > > 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s > > 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s > > 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s > > 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s > > 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s > > 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s > > 64*512 512 0.22s 71.45MB/s 0.45s 35.41MB/s > > 128*512 256 0.21s 77.84MB/s 0.51s 31.34MB/s > > 256*512 128 0.19s 82.47MB/s 0.43s 37.22MB/s > > 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s > > 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s > > 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s > > 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s > > 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s > > 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s > > 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s > > > > Average: 75.86 33.00 > > > > the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in > > the > > measurements, but the relation are similar, good on 7.0, bad on 7.1 > > Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? > no, but diffing the sysctl show: -vfs.nfs.realign_test: 22141777 +vfs.nfs.realign_test: 498351 -vfs.nfsrv.realign_test: 5005908 +vfs.nfsrv.realign_test: 0 +vfs.nfsrv.commit_miss: 0 +vfs.nfsrv.commit_blks: 0 changing them did nothing - or at least with respect to nfs throughput :-) danny From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 13:41:24 2008 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 4190F1065691; Fri, 26 Sep 2008 13:41:24 +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 E99C18FC21; Fri, 26 Sep 2008 13:41:23 +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 1KjDZS-000Juj-Vd; Fri, 26 Sep 2008 16:41:23 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Gavin Atkinson In-reply-to: <1222430498.2993.1.camel@buffy.york.ac.uk> References: <1222430498.2993.1.camel@buffy.york.ac.uk> Comments: In-reply-to Gavin Atkinson message dated "Fri, 26 Sep 2008 13:01:38 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 2008 16:41:22 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 13:41:24 -0000 > On Fri, 2008-09-26 at 10:04 +0300, Danny Braniss wrote: > > Hi, > > There seems to be some serious degradation in performance. > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > under 7.1 it drops to 20! > > Any ideas? > > The scheduler has been changed to ULE, and NFS has historically been > very sensitive to changes like that. You could try switching back to > the 4BSD scheduler and seeing if that makes a difference. If it does, > toggling PREEMPTION would also be interesting to see the results of. > > Gavin I'm testing 7.0-stable vs 7.1-prerelease, and both have ULE. BTW, the nfs client hosts I'm testing are idle. danny From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 14:05:29 2008 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 3B5F41065694; Fri, 26 Sep 2008 14:05:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D3D928FC1F; Fri, 26 Sep 2008 14:05:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8QE4dH6007656; Fri, 26 Sep 2008 10:04:57 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 26 Sep 2008 09:52:26 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809260952.26896.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Fri, 26 Sep 2008 10:04:58 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8343/Fri Sep 26 05:43:08 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 14:05:29 -0000 On Friday 26 September 2008 03:04:16 am Danny Braniss wrote: > Hi, > There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas? > > thanks, > danny Perhaps use nfsstat to see if 7.1 is performing more on-the-wire requests? Also, if you can, do a binary search to narrow down when the regression occurred in RELENG_7. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 14:31:55 2008 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 8FA4A106568F for ; Fri, 26 Sep 2008 14:31:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 71A2E8FC1E for ; Fri, 26 Sep 2008 14:31:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id KP8h1a0030FhH24A5SXvM5; Fri, 26 Sep 2008 14:31:55 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id KSXt1a00k4v8bD78USXujm; Fri, 26 Sep 2008 14:31:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=4ahL9xAdBQ21JVSEjwgA:9 a=t40GXK5bKRwRqXnMqnYA:7 a=OpEWCI36gf_DNcgCPdlVQNapDp0A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 881B0C9432; Fri, 26 Sep 2008 07:31:53 -0700 (PDT) Date: Fri, 26 Sep 2008 07:31:53 -0700 From: Jeremy Chadwick To: Danny Braniss Message-ID: <20080926143153.GA26978@icarus.home.lan> References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 14:31:55 -0000 On Fri, Sep 26, 2008 at 04:35:17PM +0300, Danny Braniss wrote: > > On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: > > > > On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > > > > > Hi, > > > > > There seems to be some serious degradation in performance. > > > > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > > > > under 7.1 it drops to 20! > > > > > Any ideas? > > > > > > > > 1) Network card driver changes, > > > could be, but at least iperf/tcp is ok - can't get udp numbers, do you > > > know of any tool to measure udp performance? > > > BTW, I also checked on different hardware, and the badness is there. > > > > According to INDEX, benchmarks/iperf does UDP bandwidth testing. > > I know, but I get about 1mgb, which seems somewhat low :-( > > > > > benchmarks/nttcp should as well. > > > > What network card is in use? If Intel, what driver version (should be > > in dmesg). > > bge: > and > bce: > and intels, but haven't tested there yet. Both bge(4) and bce(4) claim to support checksum offloading. You might try disabling it (ifconfig ... -txcsum -rxcsum) to see if things improve. If not, more troubleshooting is needed. You might also try turning off TSO if it's supported (check your ifconfig output for TSO in the options=<> section. Then use ifconfig ... -tso) > > Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? > > > no, but diffing the sysctl show: > > -vfs.nfs.realign_test: 22141777 > +vfs.nfs.realign_test: 498351 > > -vfs.nfsrv.realign_test: 5005908 > +vfs.nfsrv.realign_test: 0 > > +vfs.nfsrv.commit_miss: 0 > +vfs.nfsrv.commit_blks: 0 > > changing them did nothing - or at least with respect to nfs throughput :-) I'm not sure what any of these do, as NFS is a bit out of my league. :-) I'll be following this thread though! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 14:45:57 2008 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 E1EA7106568B; Fri, 26 Sep 2008 14:45:57 +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 93FF08FC22; Fri, 26 Sep 2008 14:45:57 +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 1KjEZw-000KkH-GP; Fri, 26 Sep 2008 17:45:56 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: <20080926095230.GA20789@icarus.home.lan> References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Fri, 26 Sep 2008 02:52:30 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 2008 17:45:56 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 14:45:58 -0000 > On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: > > > On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > > > > Hi, > > > > There seems to be some serious degradation in performance. > > > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > > > under 7.1 it drops to 20! > > > > Any ideas? > > > > > > 1) Network card driver changes, > > could be, but at least iperf/tcp is ok - can't get udp numbers, do you > > know of any tool to measure udp performance? > > BTW, I also checked on different hardware, and the badness is there. > > According to INDEX, benchmarks/iperf does UDP bandwidth testing. > > benchmarks/nttcp should as well. > > What network card is in use? If Intel, what driver version (should be > in dmesg). > > > > 2) This could be relevant, but rwatson@ will need to help determine > > > that. > > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html > > > > gut feeling is that it's somewhere else: > > > > Writing 16 MB file > > BS Count /---- 7.0 ------/ /---- 7.1 -----/ > > 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s > > 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s > > 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s > > 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s > > 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s > > 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s > > 64*512 512 0.22s 71.45MB/s 0.45s 35.41MB/s > > 128*512 256 0.21s 77.84MB/s 0.51s 31.34MB/s > > 256*512 128 0.19s 82.47MB/s 0.43s 37.22MB/s > > 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s > > 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s > > 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s > > 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s > > 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s > > 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s > > 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s > > > > Average: 75.86 33.00 > > > > the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in > > the > > measurements, but the relation are similar, good on 7.0, bad on 7.1 > > Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? > after more testing, it seems it's related to changes made between Aug 4 and Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now try and close the gap. danny From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 15:26:26 2008 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 374681065688 for ; Fri, 26 Sep 2008 15:26:26 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 65E788FC1A for ; Fri, 26 Sep 2008 15:26:25 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A7128.dip.t-dialin.net [84.154.113.40]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id m8QFQKf8019398; Fri, 26 Sep 2008 17:26:21 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m8QFQ9XL006087; Fri, 26 Sep 2008 17:26:09 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m8QFPxwS009766; Fri, 26 Sep 2008 17:26:09 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200809261526.m8QFPxwS009766@fire.js.berklix.net> To: Jeremy Chadwick From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Thu, 25 Sep 2008 09:45:08 PDT." <20080925164508.GA2105@icarus.home.lan> Date: Fri, 26 Sep 2008 17:25:59 +0200 Sender: jhs@berklix.org Cc: PYUN Yong-Hyeon , stable@freebsd.org Subject: Re: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso 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, 26 Sep 2008 15:26:26 -0000 Hi All Jeremy Chadwick wrote: > On Thu, Sep 25, 2008 at 05:36:44PM +0200, Julian Stacey wrote: > > Hi stable@, > > I just imported an old tower from a friend. Used to run Linux OK. > > Reset BIOS to defaults, turned off power saving etc, installed > > 7.1-BETA-i386-disc1.iso > > I now sees > > rl0: watchdog timeout + 40,000 ms ping outgoing. > > ping incoming fails, > > it's not my net switch, I've moved to different segments etc & all else fine > > > > I'm remaking binaries, & will look around for netstat r whatever > > commands later, meanwhile here's dmesg (via a floppy) > > > > Of course it could be somehow a hardaware bad config, its a new box to me. > > It's a "new box" with hardware from the late 90s? :-) Yes, new to me :-) The offer I got was "Do you want this or shall I dump it ?" :-) > > Copyright (c) 1992-2008 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 7.1-BETA #0: Sun Sep 7 13:49:18 UTC 2008 > > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Intel Pentium III (651.48-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0x681 Stepping = 1 > > Features=0x383f9ff > > real memory = 134152192 (127 MB) > > avail memory = 117157888 (111 MB) > > kbd1 at kbdmux0 > > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > > acpi0: on motherboard > > acpi0: [ITHREAD] > > ACPI Error (psargs-0459): [INX_] Namespace lookup failure, AE_NOT_FOUND > > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0._PRW] (Node 0xc1bd6700), AE_NOT_FOUND > > acpi0: Power Button (fixed) > > acpi0: reservation of 0, a0000 (3) failed > > acpi0: reservation of 100000, 7ef0000 (3) failed > > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > > pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f on acpi0 > > pci0: on pcib0 > > agp0: on hostb0 > > agp0: aperture size is 256M > > pcib1: at device 1.0 on pci0 > > pci1: on pcib1 > > vgapci0: port 0xc000-0xc0ff mem 0xe0000000-0xe7ffffff,0xed000000-0xed00ffff irq 11 at device 0.0 on pci1 > > isab0: at device 7.0 on pci0 > > isa0: on isab0 > > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 7.1 on pci0 > > ata0: on atapci0 > > ata0: [ITHREAD] > > ata1: on atapci0 > > ata1: [ITHREAD] > > uhci0: port 0xd400-0xd41f irq 10 at device 7.2 on pci0 > > uhci0: [GIANT-LOCKED] > > uhci0: [ITHREAD] > > usb0: on uhci0 > > usb0: USB revision 1.0 > > uhub0: on usb0 > > uhub0: 2 ports with 2 removable, self powered > > pci0: at device 7.3 (no driver attached) > > rl0: port 0xd800-0xd8ff mem 0xee000000-0xee0000ff irq 12 at device 10.0 on pci0 > > miibus0: on rl0 > > rlphy0: PHY 0 on miibus0 > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > rl0: Ethernet address: 00:08:a1:6d:65:07 > > rl0: [ITHREAD] > > pci0: at device 11.0 (no driver attached) > > cpu0: on acpi0 > > acpi_throttle0: on cpu0 > > acpi_button0: on acpi0 > > acpi_tz0: on acpi0 > > fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > > fdc0: [FILTER] > > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > > sio0: type 16550A > > sio0: [FILTER] > > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > > sio1: type 16550A > > sio1: [FILTER] > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > atkbd0: irq 1 on atkbdc0 > > kbd0 at atkbd0 > > atkbd0: [GIANT-LOCKED] > > atkbd0: [ITHREAD] > > ACPI Error (psargs-0459): [INX_] Namespace lookup failure, AE_NOT_FOUND > > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0._PRW] (Node 0xc1bd6700), AE_NOT_FOUND > > ACPI Error (psargs-0459): [INX_] Namespace lookup failure, AE_NOT_FOUND > > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0._PRW] (Node 0xc1bd6700), AE_NOT_FOUND > > pmtimer0 on isa0 > > orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 > > sc0: at flags 0x100 on isa0 > > sc0: VGA <16 virtual consoles, flags=0x300> > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > Timecounter "TSC" frequency 651482522 Hz quality 800 > > Timecounters tick every 1.000 msec > > ad0: 4110MB at ata0-master UDMA33 > > acd0: CDROM at ata1-master UDMA33 > > Trying to mount root from ufs:/dev/ad0s1a > > rl0: link state changed to UP > > rl0: watchdog timeout > > rl0: link state changed to DOWN > > rl0: link state changed to UP > > rl0: link state changed to DOWN > > rl0: link state changed to UP > > rl0: watchdog timeout > > rl0: watchdog timeout > > I've CC'd PYUN Yong-Hyeon (surname is Pyun), who helps maintain the rl(4) > driver. He might have some ideas. Thanks, I'll try his patch next. > For now, please provide the output from "vmstat -i" and "pciconf -lv". Thanks. Appended | hostb0@pci0:0:0:0: class=0x060000 card=0x00000000 chip=0x06911106 rev=0x44 hdr=0x00 | vendor = 'VIA Technologies Inc' | device = 'VT82C691/693A/694X Apollo Pro/133/133A System Controller' | class = bridge | subclass = HOST-PCI | pcib1@pci0:0:1:0: class=0x060400 card=0x00000000 chip=0x85981106 rev=0x00 hdr=0x01 | vendor = 'VIA Technologies Inc' | device = 'VT82C598MVP/694x Apollo MVP3/Pro133x PCI to AGP Bridge' | class = bridge | subclass = PCI-PCI | isab0@pci0:0:7:0: class=0x060100 card=0x00001106 chip=0x05961106 rev=0x12 hdr=0x00 | vendor = 'VIA Technologies Inc' | device = 'VT82C596/A/B "Mobile South" PCI to ISA Bridge' | class = bridge | subclass = PCI-ISA | atapci0@pci0:0:7:1: class=0x01018a card=0x00000000 chip=0x05711106 rev=0x06 hdr=0x00 | vendor = 'VIA Technologies Inc' | device = 'VT82C586A/B/VT82C686/A/B/VT823x/A/C Bus Master IDE Controller' | class = mass storage | subclass = ATA | uhci0@pci0:0:7:2: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x08 hdr=0x00 | vendor = 'VIA Technologies Inc' | device = 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host Controller' | class = serial bus | subclass = USB | none0@pci0:0:7:3: class=0x060000 card=0x00000000 chip=0x30501106 rev=0x20 hdr=0x00 | vendor = 'VIA Technologies Inc' | device = 'VT82C596/596A/596 Power Management and SMBus Controller' | class = bridge | subclass = HOST-PCI | rl0@pci0:0:10:0: class=0x020000 card=0x50323030 chip=0x813910ec rev=0x10 hdr=0x00 | vendor = 'Realtek Semiconductor' | device = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter' | class = network | subclass = ethernet | none1@pci0:0:11:0: class=0x040100 card=0x00011565 chip=0x1969125d rev=0x01 hdr=0x00 | vendor = 'ESS Technology' | device = 'ES72222 Solo-1 PCI AudioDrive family' | class = multimedia | subclass = audio | vgapci0@pci0:1:0:0: class=0x030000 card=0x031018bc chip=0x51591002 rev=0x00 hdr=0x00 | vendor = 'ATI Technologies Inc' | device = 'RV100 Radeon 7000 / Radeon VE' | class = display | subclass = VGA | interrupt total rate | irq0: clk 2736899 999 | irq1: atkbd0 135 0 | irq6: fdc0 10 0 | irq8: rtc 350307 127 | irq12: rl0 525 0 | irq14: ata0 1221 0 | irq15: ata1 59 0 | Total 3089156 1128 > And some stuff to ponder, just ideas/comments in passing: > > * Board does not appear to have an APIC (not a typo), so IRQ sharing is > likely. IRQ 12 is often used for PS/2 devices (mice, keyboards), and I > see rl0 is sitting on that IRQ. Ah ! About all I did before installing BSD was go in BIOS, rest to defaults & turn off power management. > * Read the BUGS section of the rl(4) manpage; these NICs are known to be > questionable in many regards. The CVS commit log for this driver also > has quite a list of other documented (major) bugs. "User beware": > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c Ah ! > * It's a VIA chipset board. Old Tyan server boards I had using VIA > chips (Apollo with 686B southbridge) would, even so often, stop > handling/firing IRQs. This would happen with almost any device, > even ones which were known to be relible (like fxp(4)). The only > solution would be to hard reset it. OK. Just did a power off & on. Still 10 to 35 second pings Next I'll try those patches. Thanks Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 16:13:54 2008 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 0345D1065696; Fri, 26 Sep 2008 16:13:54 +0000 (UTC) (envelope-from bkelly@vadev.org) Received: from ianto.vadev.org (vadev.org [66.92.166.151]) by mx1.freebsd.org (Postfix) with ESMTP id 81F3A8FC12; Fri, 26 Sep 2008 16:13:53 +0000 (UTC) (envelope-from bkelly@vadev.org) Received: from harkness.vadev.org (harkness.vadev.org [192.168.1.210]) (authenticated bits=0) by ianto.vadev.org (8.14.3/8.14.3) with ESMTP id m8QFq88Z093585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Sep 2008 15:52:09 GMT (envelope-from bkelly@vadev.org) Message-Id: From: Ben Kelly To: Bartosz Stec In-Reply-To: <48DCA0AF.5050000@kkip.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 26 Sep 2008 11:52:08 -0400 References: <48DB6772.1060400@kkip.pl> <20080925130227.GA13497@icarus.home.lan> <48DB9CAA.9060807@kkip.pl> <20080925145154.GA15486@icarus.home.lan> <48DCA0AF.5050000@kkip.pl> X-Mailer: Apple Mail (2.929.2) X-Spam-Score: 0.01 () ALL_TRUSTED,AWL X-Scanned-By: MIMEDefang 2.64 on 192.168.1.110 Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: vm.kmem_size settings doesn't affect loader? 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, 26 Sep 2008 16:13:54 -0000 On Sep 26, 2008, at 4:43 AM, Bartosz Stec wrote: > Jeremy Chadwick wrote: >> >> These are the tuning settings I use: >> >> vm.kmem_size="1536M" >> vm.kmem_size_max="1536M" >> vfs.zfs.arc_min="16M" >> vfs.zfs.arc_max="64M" >> > Yesterday I've added 512 MB memory to box (sum 1,5GB), and set > vm.kmem_size and vm.kmem_size to "1024M". With pieces of 1024MB, > 512MB, 256MB, 256MB available and 3 memory slots it is hard to have > 2GB RAM ;) > Until now it survived world cleaning/building/installing/bonnie++ > benchmarkink/fs scrubing and general usage. Memory usage seems > stable. If unfortunately kmem exhaustion will happen again I will > experiment with ARC settings. > IMHO you've explained gently a lot of zfs tuning concerns in this > thread and they should be added to tuning guide - espacially > explanation of ARC and prefetch settings. Thanks again! Did you increase KVA_PAGES in your kernel config as well? The default of 256 only allows 1GB of kernel memory total. Setting KVA_PAGES to 384 would probably be good for a kmem_size of 1GB. This would give leave you with 512MB of space for other things in the kernel. In your kernel config: options KVA_PAGES=384 Sorry if you already knew this. I know its in the zfs tuning guide. I just hadn't seen it mentioned in the thread yet and wanted to make sure it wasn't missed. Hope that helps. - Ben From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 16:19:29 2008 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 0E5B01065689; Fri, 26 Sep 2008 16:19:29 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [212.103.70.36]) by mx1.freebsd.org (Postfix) with ESMTP id ABB338FC08; Fri, 26 Sep 2008 16:19:28 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from 80-219-162-83.dclient.hispeed.ch ([80.219.162.83] helo=default.fsck.ch) by secure.socket.ch with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KjG2J-0001IJ-Vk; Fri, 26 Sep 2008 18:19:27 +0200 Message-ID: <48DD0B82.1000400@fsck.ch> Date: Fri, 26 Sep 2008 18:19:14 +0200 From: Tobias Roth User-Agent: Thunderbird 2.0.0.16 (X11/20080919) MIME-Version: 1.0 To: Jeremy Chadwick References: <48DB4E11.2060604@fsck.ch> <20080925114505.af589ce3.cyb.@gmx.net> <48DB6CC6.90402@fsck.ch> <20080925151411.5c0c4d0a.cyb.@gmx.net> <48DCAF74.3070900@fsck.ch> <20080926095910.GA20964@icarus.home.lan> <48DCB619.9020906@fsck.ch> <20080926104944.GA22733@icarus.home.lan> In-Reply-To: <20080926104944.GA22733@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.4 (---) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 09/26/08 12:49, Jeremy Chadwick wrote: > Being as I just rebuilt world only 2 days ago and I did not run into > this problem, I'm concluding the issue must be with your system. :-) > It's possible you've done some bizarre tuning in /etc/make.conf or > /etc/src.conf which is somehow breaking the build. [...] Content analysis details: (-3.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.9 TVD_RCVD_IP TVD_RCVD_IP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.0 AWL AWL: From: address is in the auto white-list X-SA-Exim-Connect-IP: 80.219.162.83 X-SA-Exim-Mail-From: freebsd.lists@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false Cc: Andreas Rudisch <"cyb."@gmx.net>, stable@freebsd.org Subject: Re: buildworld fails in csh 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, 26 Sep 2008 16:19:29 -0000 On 09/26/08 12:49, Jeremy Chadwick wrote: > Being as I just rebuilt world only 2 days ago and I did not run into > this problem, I'm concluding the issue must be with your system. :-) > It's possible you've done some bizarre tuning in /etc/make.conf or > /etc/src.conf which is somehow breaking the build. I checked make.conf already, since that is usually the cause when I have such problems. I didn't know about src.conf, I'll have a look at its manpage (so, since I don't have one, that can't be the cause of my problem either). >> I'll wipe out /usr/src as well and re-cvsup, then build from single user >> mode for minimal intervention by shells and environments and see whether >> that might help. > > I don't see how booting single-user is going to help with any of this. I was finally able to do a buildworld by doing it from single user mode. My guess is that the root of the problem was with either the shell I was using or some environment variables. Going to single user mode was just the safest way to remove all those possible effects, since I'm not quite sure how to do it in another way. But I agree, single user mode itself is not likely to help other than that. > And do not forget to remove /var/db/sup/src-all if you remove all of > /usr/src. People often forget this fact. I forgot it as well :-) Thanks, Tobias -- Tobias Roth || http://fsck.ch || PGP: 0xCE599B4D | You can't have everything. Where would you put it? | - Steven Wright From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 16:21:03 2008 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 672BD1065687 for ; Fri, 26 Sep 2008 16:21:03 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from kazon.borderworlds.dk (kazon.borderworlds.dk [213.239.213.48]) by mx1.freebsd.org (Postfix) with ESMTP id 2B5498FC25 for ; Fri, 26 Sep 2008 16:21:03 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from dominion.borderworlds.dk (localhost [127.0.0.1]) by kazon.borderworlds.dk (Postfix) with ESMTP id D0D78170A8 for ; Fri, 26 Sep 2008 18:21:01 +0200 (CEST) Received: by dominion.borderworlds.dk (Postfix, from userid 2000) id 55B5C472; Fri, 26 Sep 2008 18:21:01 +0200 (CEST) To: freebsd-stable@freebsd.org From: Christian Laursen Date: Fri, 26 Sep 2008 18:21:01 +0200 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: 7.1-PRERELEASE freezes 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, 26 Sep 2008 16:21:03 -0000 Hello, I decided to give 7.1-PRERELEASE a try on one of my machines to find out if there might be any problems I should be aware of. I quickly ran into problems. After a while the system freezes completely. It seems to be somehow related to the load of the machine as it doesn't seem to happen when it is idle. I built a kernel with software watchdog enabled and enabled watchdog which had the nice effect of turning the freeze into a panic. Hopefully that will be of some help. I first encountered the problem using SCHED_ULE and then tried if SCHED_4BSD made any difference. But the freeze happens with either scheduler. I have disabled xorg and the nvidia driver but that doesn't help either. I can cut down on various other stuff too, but first I hope that someone here have a more educated guess about what could be the cause of the freezes. I have placed the backtraces from the most recent crashes as well as the demsg output from the most recent boot at this URL: http://borderworlds.dk/~xi/7.1-PRERELEASE.freeze.txt My kernel config is also included. As far as I can tell the two backtraces are identical and look like this: #0 doadump () at pcpu.h:196 #1 0xc05abd03 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05abeff in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc0570d18 in hardclock (usermode=0, pc=3231434181) at /usr/src/sys/kern/kern_clock.c:642 #4 0xc07d194f in clkintr (frame=0xe38e1c68) at /usr/src/sys/i386/isa/clock.c:164 #5 0xc07c0465 in intr_execute_handlers (isrc=0xc0866700, frame=0xe38e1c68) at /usr/src/sys/i386/i386/intr_machdep.c:366 #6 0xc07d0fa8 in atpic_handle_intr (vector=0, frame=0xe38e1c68) at /usr/src/sys/i386/isa/atpic.c:596 #7 0xc07bbf41 in Xatpic_intr0 () at atpic_vector.s:62 #8 0xc09bc5c5 in acpi_cpu_c1 () at /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_machdep.c:550 #9 0xc09b54f4 in acpi_cpu_idle () at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_cpu.c:945 #10 0xc07c35b6 in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1183 #11 0xc05c9275 in sched_idletd (dummy=0x0) at /usr/src/sys/kern/sched_4bsd.c:1429 #12 0xc05895d6 in fork_exit (callout=0xc05c9260 , arg=0x0, frame=0xe38e1d38) at /usr/src/sys/kern/kern_fork.c:804 #13 0xc07bbf10 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 I can provide more information as needed. Any help will be greatly appreciated. Thanks. -- Christian Laursen From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 17:17:34 2008 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 6129E1065688 for ; Fri, 26 Sep 2008 17:17:34 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id C2E978FC12 for ; Fri, 26 Sep 2008 17:17:33 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A77C9.dip.t-dialin.net [84.154.119.201]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id m8QHHV2G020953; Fri, 26 Sep 2008 19:17:32 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m8QHH7cW006881; Fri, 26 Sep 2008 19:17:07 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m8QHGvmx011312; Fri, 26 Sep 2008 19:17:02 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200809261717.m8QHGvmx011312@fire.js.berklix.net> To: pyunyh@gmail.com From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Fri, 26 Sep 2008 10:33:46 +0900." <20080926013346.GA43015@cdnetworks.co.kr> Date: Fri, 26 Sep 2008 19:16:57 +0200 Sender: jhs@berklix.org Cc: stable@freebsd.org Subject: Re: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso 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, 26 Sep 2008 17:17:34 -0000 > > I'm remaking binaries, New generic kernel built & installed, & install of all src/ done too. No improvement. > Is there reliable way to reproduce the issue? Its continuous, the machine virtually never does a ping in less than 10 seconds. > Anyway, would you try attached patch and let me know result? Thanks Done, doesnt help. Seeing a new message now too: ping: sendto: No buffer space available. Output of vmstat -i and pciconf -lv look the same as before It's a small card. Weighs 46 gram. I was going to write I could simply post it to you, & you could keep it if you want. As I had quessed it might be some new kind of card unexperienced before, RTL8139D, card just says made in China But I just grabbed another card card says Level One. chip 8139B & with both patched kernel & original no improvement. So I tried a totaly different card xl0 fails too, I think that 3com xl0 card was OK before in another box, so I'd guess not an rl problem, Sorry. Probably not 7.1 either, but probably a BIOS config problem of some sort. IRQ 12 was listed in Award BIOS as Primary, options were also secondary or disabled, so Ive set it disabled. PNP OS Yes Resources: Auto "Reset config data" to Enabled (I forgot before after card changes) Did another restore BIOS factory defaults, no help. Moved xl0 to another slot (all other 3 slots never use I guess, as chassis plates not torn off on what I guess is original chassis. No luck with xl0 I'm out of ideas. Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 17:54:32 2008 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 5C91E1065688 for ; Fri, 26 Sep 2008 17:54:32 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 58A4F8FC1C for ; Fri, 26 Sep 2008 17:54:30 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A77C9.dip.t-dialin.net [84.154.119.201]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id m8QHsQHC021362; Fri, 26 Sep 2008 19:54:28 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m8QHsEIk007075; Fri, 26 Sep 2008 19:54:14 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m8QHs41D011762; Fri, 26 Sep 2008 19:54:09 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200809261754.m8QHs41D011762@fire.js.berklix.net> From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Fri, 26 Sep 2008 19:16:57 +0200." <200809261717.m8QHGvmx011312@fire.js.berklix.net> Date: Fri, 26 Sep 2008 19:54:04 +0200 Sender: jhs@berklix.org Cc: pyunyh@gmail.com, stable@freebsd.org Subject: Re: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso 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, 26 Sep 2008 17:54:32 -0000 Hi, Reference: > From: "Julian Stacey" > Date: Fri, 26 Sep 2008 19:16:57 +0200 > Message-id: <200809261717.m8QHGvmx011312@fire.js.berklix.net> "Julian Stacey" wrote: > > > I'm remaking binaries, > > New generic kernel built & installed, & install of all src/ done too. > No improvement. > > > Is there reliable way to reproduce the issue? > > Its continuous, the machine virtually never does a ping in less > than 10 seconds. > > > Anyway, would you try attached patch and let me know result? > > Thanks > Done, doesnt help. > Seeing a new message now too: > ping: sendto: No buffer space available. > > Output of vmstat -i and pciconf -lv look the same as before > > It's a small card. Weighs 46 gram. I was going to write > I could simply post it to you, & you could keep it if you > want. As I had quessed it might be some new kind of card > unexperienced before, > RTL8139D, card just says made in China > > But I just grabbed another card > card says Level One. > chip 8139B > & with both patched kernel & original no improvement. > So I tried a totaly different card xl0 fails too, > I think that 3com xl0 card was OK before in another box, > so I'd guess not an rl problem, Sorry. > > Probably not 7.1 either, but probably a BIOS config problem of some sort. > > IRQ 12 was listed in Award BIOS as Primary, options were also secondary or disabled, so Ive set it disabled. > PNP OS Yes > Resources: Auto > "Reset config data" to Enabled (I forgot before after card changes) > > Did another restore BIOS factory defaults, no help. > Moved xl0 to another slot (all other 3 slots never use I guess, as > chassis plates not torn off on what I guess is original chassis. > No luck with xl0 > I'm out of ideas. Got it working on xl interrupt problem, I turned off lpt com2 & something else in bios. Got to go out now Ill go back to rl0 too & report back soon thanks for help both ! Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 18:03:32 2008 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 180CD1065690 for ; Fri, 26 Sep 2008 18:03:32 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: from web33701.mail.mud.yahoo.com (web33701.mail.mud.yahoo.com [68.142.201.198]) by mx1.freebsd.org (Postfix) with SMTP id D01328FC1A for ; Fri, 26 Sep 2008 18:03:31 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: (qmail 45412 invoked by uid 60001); 26 Sep 2008 17:36:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=mO++5JMsFsopcAufuZ/4lyoq0VZyOuDyi+q2+ig9c53amguL6Ag78aWgP3NJh/UGgO3cIGE0IeNpM4kH/dc5v+JyYUrzYi/JQ4OapN/qkeARb8B6ZkTM8Uj28+ep8V8/cqeqIRtR6G3RJ9f1C00sxrSEVZCUubWz199SCRDmXNk=; X-YMail-OSG: fAsfz_wVM1nd5Ei77YZy.JLPheKYPTPgMBhulX0E28un59paz.gbrJioOJKwVbUbdzC26WMdj4GSGCVOX3fBTiP2D2Avy.SsFoq8TBiYyuRezCazW1rLY7fokwZoP0gDXJA3xHp.CPOZZBIrDeZlN07b.JorsO_R0Qg4eLGAf_30E8I- Received: from [89.211.82.248] by web33701.mail.mud.yahoo.com via HTTP; Fri, 26 Sep 2008 10:36:51 PDT X-Mailer: YahooMailRC/1096.28 YahooMailWebService/0.7.218.2 Date: Fri, 26 Sep 2008 10:36:51 -0700 (PDT) From: Abdullah Ibn Hamad Al-Marri To: Julian Stacey , pyunyh@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <87885.45152.qm@web33701.mail.mud.yahoo.com> Cc: stable@freebsd.org Subject: Re: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso 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, 26 Sep 2008 18:03:32 -0000 ----- Original Message ---- > From: Julian Stacey > To: pyunyh@gmail.com > Cc: stable@freebsd.org > Sent: Friday, September 26, 2008 8:16:57 PM > Subject: Re: rl0: watchdog timeout + 40, 000 ms ping with 7.1-BETA-i386-disc1.iso > > > > I'm remaking binaries, > > New generic kernel built & installed, & install of all src/ done too. > No improvement. > > > Is there reliable way to reproduce the issue? > > Its continuous, the machine virtually never does a ping in less > than 10 seconds. > > > Anyway, would you try attached patch and let me know result? > > Thanks > Done, doesnt help. > Seeing a new message now too: > ping: sendto: No buffer space available. > > Output of vmstat -i and pciconf -lv look the same as before > > It's a small card. Weighs 46 gram. I was going to write > I could simply post it to you, & you could keep it if you > want. As I had quessed it might be some new kind of card > unexperienced before, > RTL8139D, card just says made in China > > But I just grabbed another card > card says Level One. > chip 8139B > & with both patched kernel & original no improvement. > So I tried a totaly different card xl0 fails too, > I think that 3com xl0 card was OK before in another box, > so I'd guess not an rl problem, Sorry. > > Probably not 7.1 either, but probably a BIOS config problem of some sort. > > IRQ 12 was listed in Award BIOS as Primary, options were also secondary or > disabled, so Ive set it disabled. > PNP OS Yes > Resources: Auto > "Reset config data" to Enabled (I forgot before after card changes) > > Did another restore BIOS factory defaults, no help. > Moved xl0 to another slot (all other 3 slots never use I guess, as > chassis plates not torn off on what I guess is original chassis. > No luck with xl0 > I'm out of ideas. > > > Cheers, > Julian > -- > Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com > Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org Just a shot in the darkness. Do you have poll enabled for rl0 ? Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 18:30:32 2008 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 D7818106564A; Fri, 26 Sep 2008 18:30:32 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id A95168FC13; Fri, 26 Sep 2008 18:30:32 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m8QII6UT004334; Fri, 26 Sep 2008 11:18:06 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m8QII6jF004333; Fri, 26 Sep 2008 11:18:06 -0700 (PDT) Date: Fri, 26 Sep 2008 11:18:06 -0700 (PDT) From: Matthew Dillon Message-Id: <200809261818.m8QII6jF004333@apollo.backplane.com> To: Jeremy Chadwick References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> <20080926143153.GA26978@icarus.home.lan> Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 18:30:32 -0000 :> -vfs.nfs.realign_test: 22141777 :> +vfs.nfs.realign_test: 498351 :> :> -vfs.nfsrv.realign_test: 5005908 :> +vfs.nfsrv.realign_test: 0 :> :> +vfs.nfsrv.commit_miss: 0 :> +vfs.nfsrv.commit_blks: 0 :> :> changing them did nothing - or at least with respect to nfs throughput :-) : :I'm not sure what any of these do, as NFS is a bit out of my league. ::-) I'll be following this thread though! : :-- :| Jeremy Chadwick jdc at parodius.com | A non-zero nfs_realign_count is bad, it means NFS had to copy the mbuf chain to fix the alignment. nfs_realign_test is just the number of times it checked. So nfs_realign_test is irrelevant. it's nfs_realign_count that matters. Several things can cause NFS payloads to be improperly aligned. Anything from older network drivers which can't start DMA on a 2-byte boundary, resulting in the 14-byte encapsulation header causing improper alignment of the IP header & payload, to rpc embedded in NFS TCP streams winding up being misaligned. Modern network hardware either support 2-byte-aligned DMA, allowing the encapsulation to be 2-byte aligned so the payload winds up being 4-byte aligned, or support DMA chaining allowing the payload to be placed in its own mbuf, or pad, etc. -- One thing I would check is to be sure a couple of nfsiod's are running on the client when doing your tests. If none are running the RPCs wind up being more synchronous and less pipelined. Another thing I would check is IP fragment reassembly statistics (for UDP) - there should be none for TCP connections no matter what the NFS I/O size selected. (It does seem more likely to be scheduler-related, though). -Matt From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 18:37:02 2008 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 604101065694 for ; Fri, 26 Sep 2008 18:37:02 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 33CC18FC29 for ; Fri, 26 Sep 2008 18:37:02 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 76ACC1A90D4 for ; Fri, 26 Sep 2008 11:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFJaCSYAhg35 for ; Fri, 26 Sep 2008 11:31:54 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id A1FE51A8EEF for ; Fri, 26 Sep 2008 11:31:54 -0700 (PDT) Message-ID: <48DD2BCC.1040903@miralink.com> Date: Fri, 26 Sep 2008 11:37:00 -0700 From: Sean Bruno User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [RELENG_6] Works Fine For Me! 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, 26 Sep 2008 18:37:02 -0000 Just an effort to test RELENG_6 . No issues noted on my Dell server. Nice work folks! Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.4-PRERELEASE #1 r183385M: Fri Sep 26 11:13:48 PDT 2008 root@desdemona.office.miralink.com:/usr/obj/home/sbruno/bsd/6/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.19-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100000 Logical CPUs per core: 2 real memory = 1073479680 (1023 MB) avail memory = 1037283328 (989 MB) ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Sep 26 2008 11:10:49) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 mpt0: port 0xec00-0xecff mem 0xfe9f0000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 34 at device 5.0 on pci2 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.12.0 pcib3: at device 0.2 on pci1 pci3: on pcib3 ahc0: port 0xdc00-0xdcff mem 0xfe7ff000-0xfe7fffff irq 37 at device 11.0 on pci3 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 5.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci6: on pcib6 em0: port 0xccc0-0xccff mem 0xfe4e0000-0xfe4fffff irq 64 at device 7.0 on pci6 em0: Ethernet address: 00:11:43:e2:ff:fd pcib7: at device 0.2 on pci5 pci7: on pcib7 em1: port 0xbcc0-0xbcff mem 0xfe2e0000-0xfe2fffff irq 65 at device 8.0 on pci7 em1: Ethernet address: 00:11:43:e2:ff:fe pcib8: at device 6.0 on pci0 pci8: on pcib8 uhci0: port 0x9ce0-0x9cff irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x9cc0-0x9cdf irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x9ca0-0x9cbf irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfeb00000-0xfeb003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered uhub4: vendor 0x413c product 0xa001, class 9/0, rev 2.00/0.00, addr 2 uhub4: multiple transaction translators uhub4: 2 ports with 2 removable, self powered pcib9: at device 30.0 on pci0 pci9: on pcib9 pci9: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xcffff,0xd0000-0xd0fff,0xec000-0xeffff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2793191800 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. Waiting 5 seconds for SCSI devices to settle acd0: CDROM at ata0-master UDMA33 ses0 at mpt0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device da2 at ahc0 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Enabled da2: 952856MB (1951449088 512 byte sectors: 255H 63S/T 121472C) da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 70007MB (143374650 512 byte sectors: 255H 63S/T 8924C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) GEOM_MIRROR: Device gm0 created (id=2295809732). GEOM_MIRROR: Device gm0: provider da0 detected. GEOM_MIRROR: Device gm0: provider da1 detected. GEOM_MIRROR: Device gm0: provider da1 activated. GEOM_MIRROR: Device gm0: provider da0 activated. GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. Trying to mount root from ufs:/dev/mirror/gm0s1a em0: link state changed to UP [sbruno@desdemona ~]$ uname -a FreeBSD desdemona.office.miralink.com 6.4-PRERELEASE FreeBSD 6.4-PRERELEASE #1 r183385M: Fri Sep 26 11:13:48 PDT 2008 root@desdemona.office.miralink.com:/usr/obj/home/sbruno/bsd/6/sys/GENERIC i386 -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 19:08:52 2008 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 B8DAE1065686; Fri, 26 Sep 2008 19:08:52 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id A97D48FC08; Fri, 26 Sep 2008 19:08:51 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 26 Sep 2008 20:08:49 +0100 (BST) Date: Fri, 26 Sep 2008 20:08:48 +0100 From: David Malone To: Danny Braniss Message-ID: <20080926190848.GA65901@walton.maths.tcd.ie> References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@FreeBSD.org, Jeremy Chadwick , freebsd-stable@FreeBSD.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 19:08:52 -0000 On Fri, Sep 26, 2008 at 04:35:17PM +0300, Danny Braniss wrote: > I know, but I get about 1mgb, which seems somewhat low :-( Since UDP has no way to know how fast to send, you need to tell iperf how fast to send the packets. I think 1Mbps is the default speed. David. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 21:59:41 2008 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 4CFA7106568A for ; Fri, 26 Sep 2008 21:59:41 +0000 (UTC) (envelope-from peterjeremy@optushome.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 C1A488FC2B for ; Fri, 26 Sep 2008 21:59:40 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m8QLxXXX028381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Sep 2008 07:59:37 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m8QLxWf8030698; Sat, 27 Sep 2008 07:59:32 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m8QLxVNq030697; Sat, 27 Sep 2008 07:59:31 +1000 (EST) (envelope-from peter) Date: Sat, 27 Sep 2008 07:59:31 +1000 From: Peter Jeremy To: Anton - Valqk Message-ID: <20080926215931.GM15376@server.vk2pj.dyndns.org> References: <48DCB57E.8000001@lozenetz.org> <48DCD1DF.6010203@lozenetz.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3r2sERxeG5twY2zu" Content-Disposition: inline In-Reply-To: <48DCD1DF.6010203@lozenetz.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org Subject: Re: HELP DEBUG: FreeBSD 6.3-RELEASE-p3 TIMEOUT - WRITE_DMA + other strange behaviour! 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, 26 Sep 2008 21:59:41 -0000 --3r2sERxeG5twY2zu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Anton, On 2008-Sep-26 15:13:19 +0300, Anton - Valqk wrote: >you are right that the machine has *lots* ot hardware in it, >I was thinking of the power supply as a reason and measured the 5 and 12 >volts - seemd to be ok 11.8 and 5.2 with all hardware in it. A multimeter won't show noise or load spikes. That said, if the PSU is reasonably new and running well within its ratings, it shouldn't be a problem. >1. remove rl0 and run only one isp for the test. It's definitely worthwhile getting rid of rl(4) cards. Read the top of the driver source for reasons. >3. try to replace the ATA100 cables (the one with 80 wires) with an >older ones with only 40 cabels? I wouldn't recommend this. The 80-wire cables are electrically much better than the 40-wire ones. You might like to try a different cable. You should verify that the master/slave/MB sockets on the cable are plugged into the correct device. If you want to slow down the ATA bus, I suggest you do it in software. >4. ? anything else? Try disconnecting some of the disks and see if the problem goes away - this would help rule out PSU problems. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --3r2sERxeG5twY2zu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjdW0MACgkQ/opHv/APuIeNCQCfZeWDcess5d47M7pe5YczKQ+K NXQAn0fV0f4iOm4NtBKCDqeUCMCprMi9 =84o7 -----END PGP SIGNATURE----- --3r2sERxeG5twY2zu-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 22:17:03 2008 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 B0EA2106569B for ; Fri, 26 Sep 2008 22:17:03 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal4.es.net [198.124.252.66]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4038FC1B for ; Fri, 26 Sep 2008 22:17:03 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal3.es.net [198.128.3.207]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id GFR02302; Fri, 26 Sep 2008 15:17:02 -0700 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id GFR53800; Fri, 26 Sep 2008 15:17:00 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 1C4AE4500E; Fri, 26 Sep 2008 15:17:00 -0700 (PDT) To: David Malone In-Reply-To: Your message of "Fri, 26 Sep 2008 20:08:48 BST." <20080926190848.GA65901@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1222467420_5817P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 26 Sep 2008 15:17:00 -0700 From: "Kevin Oberman" Message-Id: <20080926221700.1C4AE4500E@ptavv.es.net> X-Sender-IP: 198.128.3.207 X-Sender-Domain: es.net X-Recipent: ; ; ; ; ; X-Sender: X-To_Name: David Malone X-To_Domain: maths.tcd.ie X-To: David Malone X-To_Email: dwmalone@maths.tcd.ie X-To_Alias: dwmalone Cc: freebsd-hackers@FreeBSD.org, Jeremy Chadwick , freebsd-stable@FreeBSD.org Subject: Re: bad NFS/UDP 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: Fri, 26 Sep 2008 22:17:03 -0000 --==_Exmh_1222467420_5817P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline David, You beat me to it. Danny, read the iperf man page: -b, --bandwidth n[KM] set target bandwidth to n bits/sec (default 1 Mbit/sec). This setting requires UDP (-u). The page needs updating, though. It should read "-b, --bandwidth n[KMG]. It also does NOT require -u. If you use -b, UDP is assumed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1222467420_5817P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFI3V9ckn3rs5h7N1ERAiyHAJ9bLra2puNNXtyoZSsaFkSnCUbxMACgi0vt Fli2cgG1hEAVg9b+A2eAsbk= =q4xd -----END PGP SIGNATURE----- --==_Exmh_1222467420_5817P-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 26 22:21:21 2008 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 29209106568C for ; Fri, 26 Sep 2008 22:21:21 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8B95B8FC13 for ; Fri, 26 Sep 2008 22:21:19 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m8QBN7Vw010280 for ; Fri, 26 Sep 2008 21:23:07 +1000 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m8QBN4sJ002648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 21:23:06 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m8QBN4fW011187; Fri, 26 Sep 2008 21:23:04 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m8QBN4Ce011186; Fri, 26 Sep 2008 21:23:04 +1000 (EST) (envelope-from peter) Date: Fri, 26 Sep 2008 21:23:04 +1000 From: Peter Jeremy To: Anton - Valqk Message-ID: <20080926112304.GK15376@server.vk2pj.dyndns.org> References: <48DCB57E.8000001@lozenetz.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3LDjyuwMyYgFmzqN" Content-Disposition: inline In-Reply-To: <48DCB57E.8000001@lozenetz.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org Subject: Re: HELP DEBUG: FreeBSD 6.3-RELEASE-p3 TIMEOUT - WRITE_DMA + other strange behaviour! 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, 26 Sep 2008 22:21:21 -0000 --3LDjyuwMyYgFmzqN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Sep-26 13:12:14 +0300, Anton - Valqk wrote: >1. I get a lot of dma times outs. mostly on ad5 and ad7 where I keep =2E.. >dmesg.today:ad7: FAILURE - WRITE_DMA48 status=3D51 >error=3D10 LBA=3D374303456 This is a bad sign and suggests dying disk but... >2. The other strange issue is that when (I guess) it starts timeouting >*sometimes* not everytime I'm loosing connection to xl0 or fxp0 You have an awful lot of hardware in this box. Are you sure the power supply and cooling is up to scratch? Sagging power could cause the problems you report, as could overheating. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --3LDjyuwMyYgFmzqN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjcxhgACgkQ/opHv/APuIcI8wCfRF2OVo2pwpR1y39hEKeyLNfl i0EAoJ6uOTiaJ+f6B91mCHtnOYvCmc7i =/v/N -----END PGP SIGNATURE----- --3LDjyuwMyYgFmzqN-- From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 01:10:07 2008 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 ACEBB1065686 for ; Sat, 27 Sep 2008 01:10:07 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 3B2978FC15 for ; Sat, 27 Sep 2008 01:10:06 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from [10.29.62.12] (port=64090) by fish.ish.com.au with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1KjOeJ-0004yC-31; Sat, 27 Sep 2008 11:31:08 +1000 Message-Id: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> From: Aristedes Maniatis To: freebsd-stable Stable Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 27 Sep 2008 11:10:01 +1000 X-Mailer: Apple Mail (2.929.2) Subject: sysctl maxfiles 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: Sat, 27 Sep 2008 01:10:07 -0000 By default FreeBSD 7.0 shipped with the sysctls set to: kern.maxfiles: 12328 kern.maxfilesperproc: 11095 We recently bumped up against these limits in an unfortunate way and we are going to raise them. I have some questions: * why are the numbers set the way they are? They aren't round numbers, they aren't powers of 2. But they were arrived at somehow with planning and thought presumably, so when I increase them I'd like to know a bit more about why these numbers were chosen. * why are the numbers so close together? Surely there should be more gap between max files per process and the max files for the whole system. What happens is that with one runaway broken process is that it hits 11095 and the 1233 files left for everything else is not enough (on many servers) to allow the admin to login using ssh. That gets very ugly very quickly. * Under OSX (both server and client), these numbers are 12288 and 10240. A bit more of a gap, but not terribly different to FreeBSD. Still interesting that someone changed these numbers just slightly. * why do these controls exist at all? That is, if they were set to infinite what part of the system would be exhausted by a runaway process which kept opening files? Would the kernel run out of memory? What memory setting would be relevant here? I don't want to set maxfiles too high and then run out of some other resource which this maxfiles was protecting. Thanks Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 02:50:20 2008 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 1E9E51065693 for ; Sat, 27 Sep 2008 02:50:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 03CBB8FC1E for ; Sat, 27 Sep 2008 02:50:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id KcH41a01J0mlR8UA1epyN4; Sat, 27 Sep 2008 02:49:58 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id KeqJ1a0014v8bD78XeqJSb; Sat, 27 Sep 2008 02:50:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=A3ZAM6IVAAAA:8 a=QycZ5dHgAAAA:8 a=NZNOqxvlP-IiRRzuxGQA:9 a=GlGGwONWUt28xUEOUF8A:7 a=2AS3X9mAd2bQUUMLPgpUxsyIxb4A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id CF5DFC9432; Fri, 26 Sep 2008 19:50:17 -0700 (PDT) Date: Fri, 26 Sep 2008 19:50:17 -0700 From: Jeremy Chadwick To: Christian Laursen Message-ID: <20080927025017.GA40195@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: 7.1-PRERELEASE freezes 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: Sat, 27 Sep 2008 02:50:20 -0000 On Fri, Sep 26, 2008 at 06:21:01PM +0200, Christian Laursen wrote: > I decided to give 7.1-PRERELEASE a try on one of my machines to find > out if there might be any problems I should be aware of. > > I quickly ran into problems. After a while the system freezes > completely. It seems to be somehow related to the load of the machine > as it doesn't seem to happen when it is idle. I built a kernel with > software watchdog enabled and enabled watchdog which had the nice > effect of turning the freeze into a panic. Hopefully that will be of > some help. > > I first encountered the problem using SCHED_ULE and then tried if > SCHED_4BSD made any difference. But the freeze happens with either > scheduler. > > I have disabled xorg and the nvidia driver but that doesn't help > either. I can cut down on various other stuff too, but first I hope > that someone here have a more educated guess about what could be the > cause of the freezes. > > I have placed the backtraces from the most recent crashes as well as > the demsg output from the most recent boot at this URL: > http://borderworlds.dk/~xi/7.1-PRERELEASE.freeze.txt > > My kernel config is also included. > > #0 doadump () at pcpu.h:196 > #1 0xc05abd03 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc05abeff in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:572 > #3 0xc0570d18 in hardclock (usermode=0, pc=3231434181) at /usr/src/sys/kern/kern_clock.c:642 > #4 0xc07d194f in clkintr (frame=0xe38e1c68) at /usr/src/sys/i386/isa/clock.c:164 > #5 0xc07c0465 in intr_execute_handlers (isrc=0xc0866700, frame=0xe38e1c68) at /usr/src/sys/i386/i386/intr_machdep.c:366 > #6 0xc07d0fa8 in atpic_handle_intr (vector=0, frame=0xe38e1c68) at /usr/src/sys/i386/isa/atpic.c:596 > #7 0xc07bbf41 in Xatpic_intr0 () at atpic_vector.s:62 > #8 0xc09bc5c5 in acpi_cpu_c1 () at /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_machdep.c:550 > #9 0xc09b54f4 in acpi_cpu_idle () at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_cpu.c:945 > #10 0xc07c35b6 in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1183 > #11 0xc05c9275 in sched_idletd (dummy=0x0) at /usr/src/sys/kern/sched_4bsd.c:1429 > #12 0xc05895d6 in fork_exit (callout=0xc05c9260 , arg=0x0, frame=0xe38e1d38) at /usr/src/sys/kern/kern_fork.c:804 > #13 0xc07bbf10 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 > A couple generic things, although I think jhb@ might be able to figure out what's going on here: 1) Is this machine running the latest BIOS available? 2) Are you running powerd(8) on this box? 3) Does disabling ACPI (it's a menu option when booting) help? 4) Does removing "device cpufreq" help? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 03:02:09 2008 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 250391065690 for ; Sat, 27 Sep 2008 03:02:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 09B0B8FC19 for ; Sat, 27 Sep 2008 03:02:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id KcRK1a00R0S2fkCA8f28pn; Sat, 27 Sep 2008 03:02:08 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id Kf241a00K4v8bD78Vf25lo; Sat, 27 Sep 2008 03:02:05 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=Pd3Si49nVNFPp4pYRB4A:9 a=HRHXUg4pcuvBOhoxypwZtxG2lz8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id CBE34C9432; Fri, 26 Sep 2008 20:02:04 -0700 (PDT) Date: Fri, 26 Sep 2008 20:02:04 -0700 From: Jeremy Chadwick To: Aristedes Maniatis Message-ID: <20080927030204.GB40195@icarus.home.lan> References: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable Stable Subject: Re: sysctl maxfiles 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: Sat, 27 Sep 2008 03:02:09 -0000 On Sat, Sep 27, 2008 at 11:10:01AM +1000, Aristedes Maniatis wrote: > By default FreeBSD 7.0 shipped with the sysctls set to: > > kern.maxfiles: 12328 > kern.maxfilesperproc: 11095 > > We recently bumped up against these limits in an unfortunate way and we > are going to raise them. I have some questions: > > * why are the numbers set the way they are? They aren't round numbers, > they aren't powers of 2. But they were arrived at somehow with planning > and thought presumably, so when I increase them I'd like to know a bit > more about why these numbers were chosen. The values are calculated when the kernel is loaded, based on many other parameters; you won't find "12328" hard-coded anywhere in the kernel source, for example. The Handbook goes over this fact: http://www.freebsd.org/doc/en/books/handbook/configtuning-kernel-limits.html By the way, DO NOT let the term "maxusers" make you think that has something to do with the number of users which can be logged in simultaneously or added to a box. It has nothing to do with that. Anyway, I'd like to know why you have so many fds open simultaneously in the first place. We're talking over 11,000 fds actively open at once -- this is not a small number. What exactly is this machine doing? Are you absolutely certain tuning this higher is justified? Have you looked into the possibility that you have a program which is exhausting fds by not closing them when finished? (Yes, this is quite common; I've seen bad Java code cause this problem on Solaris.) > * why are the numbers so close together? Surely there should be more gap > between max files per process and the max files for the whole system. > What happens is that with one runaway broken process is that it hits > 11095 and the 1233 files left for everything else is not enough (on many > servers) to allow the admin to login using ssh. That gets very ugly very > quickly. Others will have to comment on this. > * Under OSX (both server and client), these numbers are 12288 and 10240. > A bit more of a gap, but not terribly different to FreeBSD. Still > interesting that someone changed these numbers just slightly. OS X isn't based on FreeBSD 7. The calculation logic has changed over time. > * why do these controls exist at all? That is, if they were set to > infinite what part of the system would be exhausted by a runaway process > which kept opening files? Would the kernel run out of memory? What memory > setting would be relevant here? I don't want to set maxfiles too high and > then run out of some other resource which this maxfiles was protecting. You're asking for trouble setting these values to the equivalent of unlimited. Instead of asking "what would happen", you should be asking "why would I need to do that". Regarding memory implications, the Handbook goes over it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 04:35:04 2008 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 162281065688; Sat, 27 Sep 2008 04:35:04 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (h-74-0-89-210.lsanca54.covad.net [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id E26FE8FC1B; Sat, 27 Sep 2008 04:35:03 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from takeda.lan (takeda.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.2/8.14.2) with ESMTP id m8R4Z2RA061287 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 21:35:02 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Fri, 26 Sep 2008 21:33:41 -0700 From: =?utf-8?Q?Derek_Kuli=C5=84ski?= X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <249873145.20080926213341@takeda.tk> To: Jeremy Chadwick In-Reply-To: <20080921220720.GA9847@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94/8345/Fri Sep 26 18:20:01 2008 on chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, Clint Olsen Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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: Sat, 27 Sep 2008 04:35:04 -0000 Hello Jeremy, Sunday, September 21, 2008, 3:07:20 PM, you wrote: > Consider using background_fsck="no" in /etc/rc.conf if you prefer the > old behaviour. Otherwise, boot single-user then do the fsck. Actually what's the advantage of having fsck run in background if it isn't capable of fixing things? Isn't it more dangerous to be it like that? i.e. administrator might not notice the problem; also filesystem could break even further... -- Best regards, Derek mailto:takeda@takeda.tk I tried to daydream, but my mind kept wandering. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 05:14:15 2008 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 12F301065687 for ; Sat, 27 Sep 2008 05:14:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id E8A9D8FC19 for ; Sat, 27 Sep 2008 05:14:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id KgWY1a00H17UAYkA2hEEB9; Sat, 27 Sep 2008 05:14:14 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id KhED1a0084v8bD78ZhEDVh; Sat, 27 Sep 2008 05:14:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=inZtLy6cd8y2bcjepY8A:9 a=efwyIIf47CVO53V7Upy5Hfgc21AA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 13A3AC9432; Fri, 26 Sep 2008 22:14:13 -0700 (PDT) Date: Fri, 26 Sep 2008 22:14:13 -0700 From: Jeremy Chadwick To: Derek Kuli??ski Message-ID: <20080927051413.GA42700@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <249873145.20080926213341@takeda.tk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, Clint Olsen Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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: Sat, 27 Sep 2008 05:14:15 -0000 On Fri, Sep 26, 2008 at 09:33:41PM -0700, Derek Kuli??ski wrote: > Hello Jeremy, > > Sunday, September 21, 2008, 3:07:20 PM, you wrote: > > > Consider using background_fsck="no" in /etc/rc.conf if you prefer the > > old behaviour. Otherwise, boot single-user then do the fsck. > > Actually what's the advantage of having fsck run in background if it > isn't capable of fixing things? > Isn't it more dangerous to be it like that? i.e. administrator might > not notice the problem; also filesystem could break even further... This question should really be directed at a set of different folks, e.g. actual developers of said stuff (UFS2 and soft updates in specific), because it's opening up a can of worms. I believe it has to do with the fact that there is much faith given to UFS2 soft updates -- the ability to background fsck allows the user to boot their system and have it up and working (able to log in, etc.) in a much shorter amount of time[1]. It makes the assumption that "everything will work just fine", which is faulty. It also gives the impression of a journalled filesystem, which UFS2 soft updates are not. gjournal(8) on the other hand, is, and doesn't require fsck at all[2]. I also think this further adds fuel to the "so why are we enabling soft updates by default and using UFS2 as a filesystem again?" fire. I'm sure someone will respond to this with "So use ZFS and shut up". *sigh* [1]: http://lists.freebsd.org/pipermail/freebsd-questions/2004-December/069114.html [2]: http://lists.freebsd.org/pipermail/freebsd-questions/2008-April/173501.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 05:36:06 2008 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 CD42D1065686; Sat, 27 Sep 2008 05:36:06 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (h-74-0-89-210.lsanca54.covad.net [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 844548FC16; Sat, 27 Sep 2008 05:36:06 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from takeda.lan (takeda.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.2/8.14.2) with ESMTP id m8R5a5ZW062047 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 22:36:05 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Fri, 26 Sep 2008 22:35:57 -0700 From: =?utf-8?Q?Derek_Kuli=C5=84ski?= X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <765067435.20080926223557@takeda.tk> To: Jeremy Chadwick In-Reply-To: <20080927051413.GA42700@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94/8345/Fri Sep 26 18:20:01 2008 on chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-stable@FreeBSD.org, Clint Olsen Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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: Sat, 27 Sep 2008 05:36:06 -0000 Hello Jeremy, Friday, September 26, 2008, 10:14:13 PM, you wrote: >> Actually what's the advantage of having fsck run in background if it >> isn't capable of fixing things? >> Isn't it more dangerous to be it like that? i.e. administrator might >> not notice the problem; also filesystem could break even further... > This question should really be directed at a set of different folks, > e.g. actual developers of said stuff (UFS2 and soft updates in > specific), because it's opening up a can of worms. > I believe it has to do with the fact that there is much faith given to > UFS2 soft updates -- the ability to background fsck allows the user to > boot their system and have it up and working (able to log in, etc.) in a > much shorter amount of time[1]. It makes the assumption that "everything > will work just fine", which is faulty. As far as I know (at least ideally, when write caching is disabled) the data should always be consistent, and all fsck supposed to be doing is to free unreferenced blocks that were allocated. Wouldn't be possible for background fsck to do that while the filesystem is mounted, and if there's some unrepairable error, that somehow happen (while in theory it should be impossible) just periodically scream on the emergency log level? > It also gives the impression of a journalled filesystem, which UFS2 soft > updates are not. gjournal(8) on the other hand, is, and doesn't require > fsck at all[2]. > I also think this further adds fuel to the "so why are we enabling soft > updates by default and using UFS2 as a filesystem again?" fire. I'm > sure someone will respond to this with "So use ZFS and shut up". *sigh* I think the reason for using Soft Updates by default is that it was a pretty hard thing to implement, and (at least in theory it supposed by as reliable as journaling. Also, if I remember correctly, PJD said that gjournal is performing much better with small files, while softupdates is faster with big ones. -- Best regards, Derek mailto:takeda@takeda.tk Programmers are tools for converting caffeine into code. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 06:44:19 2008 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 1395E1065678 for ; Sat, 27 Sep 2008 06:44:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id E607B8FC17 for ; Sat, 27 Sep 2008 06:44:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id KiAQ1a00M17UAYkA1ijxha; Sat, 27 Sep 2008 06:43:57 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id KikH1a0014v8bD78ZikHan; Sat, 27 Sep 2008 06:44:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=H0umD5oqAAAA:8 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=_OaQ9GrwlmQ36l0rxd0A:9 a=3IQQfE3oOPw-PTbXXRAA:7 a=8Atas1TtQs9DCbB1GHqyLtYDCJIA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 2FB69C9432; Fri, 26 Sep 2008 23:44:17 -0700 (PDT) Date: Fri, 26 Sep 2008 23:44:17 -0700 From: Jeremy Chadwick To: Derek Kuli??ski Message-ID: <20080927064417.GA43638@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <765067435.20080926223557@takeda.tk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@FreeBSD.org, Clint Olsen Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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: Sat, 27 Sep 2008 06:44:19 -0000 On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote: > Hello Jeremy, > > Friday, September 26, 2008, 10:14:13 PM, you wrote: > > >> Actually what's the advantage of having fsck run in background if it > >> isn't capable of fixing things? > >> Isn't it more dangerous to be it like that? i.e. administrator might > >> not notice the problem; also filesystem could break even further... > > > This question should really be directed at a set of different folks, > > e.g. actual developers of said stuff (UFS2 and soft updates in > > specific), because it's opening up a can of worms. > > > I believe it has to do with the fact that there is much faith given to > > UFS2 soft updates -- the ability to background fsck allows the user to > > boot their system and have it up and working (able to log in, etc.) in a > > much shorter amount of time[1]. It makes the assumption that "everything > > will work just fine", which is faulty. > > As far as I know (at least ideally, when write caching is disabled) Re: write caching: wheelies and burn-outs in empty parking lots detected. Let's be realistic. We're talking about ATA and SATA hard disks, hooked up to on-board controllers -- these are the majority of users. Those with ATA/SATA RAID controllers (not on-board RAID either; most/all of those do not let you disable drive write caching) *might* have a RAID BIOS menu item for disabling said feature. FreeBSD atacontrol does not let you toggle such features (although "cap" will show you if feature is available and if it's enabled or not). Users using SCSI will most definitely have the ability to disable said feature (either via SCSI BIOS or via camcontrol). But the majority of users are not using SCSI disks, because the majority of users are not going to spend hundreds of dollars on a controller followed by hundreds of dollars for a small (~74GB) disk. Regardless of all of this, end-users should, in no way shape or form, be expected to go to great lengths to disable their disk's write cache. They will not, I can assure you. Thus, we must assume: write caching on a disk will be enabled, period. If a filesystem is engineered with that fact ignored, then the filesystem is either 1) worthless, or 2) serves a very niche purpose and should not be the default filesystem. Do we agree? > the data should always be consistent, and all fsck supposed to be > doing is to free unreferenced blocks that were allocated. fsck does a heck of a lot more than that, and there's no guarantee that's all fsck is going to do on a UFS2+SU filesystem. I'm under the impression it does a lot more than just looking for unref'd blocks. > Wouldn't be possible for background fsck to do that while the > filesystem is mounted, and if there's some unrepairable error, that > somehow happen (while in theory it should be impossible) just > periodically scream on the emergency log level? The system is already up and the filesystems mounted. If the error in question is of such severity that it would impact a user's ability to reliably use the filesystem, how do you expect constant screaming on the console will help? A user won't know what it means; there is already evidence of this happening (re: mysterious ATA DMA errors which still cannot be figured out[6]). IMHO, a dirty filesystem should not be mounted until it's been fully analysed/scanned by fsck. So again, people are putting faith into UFS2+SU despite actual evidence proving that it doesn't handle all scenarios. > > It also gives the impression of a journalled filesystem, which UFS2 soft > > updates are not. gjournal(8) on the other hand, is, and doesn't require > > fsck at all[2]. > > > I also think this further adds fuel to the "so why are we enabling soft > > updates by default and using UFS2 as a filesystem again?" fire. I'm > > sure someone will respond to this with "So use ZFS and shut up". *sigh* > > I think the reason for using Soft Updates by default is that it was > a pretty hard thing to implement, and (at least in theory it supposed > by as reliable as journaling. The problem here is that when it was created, it was sort of an "experiment". Now, when someone installs FreeBSD, UFS2 is the default filesystem used, and SU are enabled on every filesystem except the root fs. Thus, we have now put ourselves into a situation where said feature ***must*** be reliable in all cases. You're also forgetting a huge focus of SU -- snapshots[1]. However, there are more than enough facts on the table at this point concluding that snapshots are causing more problems[7] than previously expected. And there's further evidence filesystem snapshots shouldn't even be used in this way[8]. > Also, if I remember correctly, PJD said that gjournal is performing > much better with small files, while softupdates is faster with big > ones. Okay, so now we want to talk about benchmarks. The benchmarks you're talking about are in two places[2][3]. The benchmarks pjd@ provided were very basic/simple, which I feel is good, because the tests were realistic (common tasks people will do). The benchmarks mckusick@ provided for UFS2+SU were based on SCSI disks, which is... interesting to say the least. Bruce Evans responded with some more data[4]. I particularly enjoy this quote in his benchmark: "I never found the exact cause of the slower readback ...", followed by (plausible) speculations as to why that is. I'm sorry that I sound like such a hard-ass on this matter, but there is a glaring fact that people seem to be overlooking intentionally: Filesystems have to be reliable; data integrity is focus #1, and cannot be sacrificed. Users and administrators *expect* a filesystem to be reliable. No one is going to keep using a filesystem if it has disadvantages which can result in data loss or "waste of administrative time" (which I believe is what's occurring here). Users *will* switch to another operating system that has filesystems which were not engineered/invented with these features in mind. Or, they can switch to another filesystem assuming the OS offers one which performs equally as good/well and is guaranteed to be reliable -- and that's assuming the user wants to spend the time to reformat and reinstall just to get that. In the case of "bit rot" (e.g. drive cache going bad silently, bad cables, or other forms of low-level data corruption), a filesystem is likely not to be able to cope with this (but see below). A common rebuttal here would be: "so use UFS2 without soft updates". Excellent advice! I might consider it myself! But the problem is that we cannot expect users to do that. Why? Because the defaults chosen during sysinstall are to use SU for all filesystems except root. If SU is not reliable (or is "reliable in most cases" -- same thing if you ask me), then it should not be enabled by default. I think we (FreeBSD) might have been a bit hasty in deciding to choose that as a default. Next: a system locking up (or a kernel panic) should result in a dirty filesystem. That filesystem should be *fully recoverable* from that kind of error, with no risk of data loss (but see below). (There is the obvious case where a file is written to the disk, and the disk has not completed writing the data from its internal cache to the disk itself (re: write caching); if power is lost, the disk may not have finished writing the cache to disk. In this case, the file is going to be sparse -- there is absolutely nothing that can be done about this with any filesystem, including ZFS (to my knowledge). This situation is acceptable; nature of the beast.) The filesystem should be fully analysed and any errors repaired (either with user interaction or automatically -- I'm sure it depends on the kind of error) **before** the filesystem is mounted. This is where SU gets in the way. The filesystem is mounted and the system is brought up + online 60 seconds before the fsck starts. The assumption made is that the errors in question will be fully recoverable by an automatic fsck, which as this thread proves, is not always the case. ZFS is the first filesystem, to my knowledge, which provides 1) a reliable filesystem, 2) detection of filesystem problems in real-time or during scrubbing, 3) repair of problems in real-time (assuming raidz1 or raidz2 are used), and 4) does not need fsck. This makes ZFS powerful. "So use ZFS!" A good piece of advice -- however, I've already had reports from users that they will not consider ZFS for FreeBSD at this time. Why? Because ZFS on FreeBSD can panic the system easily due to kmem exhaustion. Proper tuning can alleviate this problem, but users do not want to to have to "tune" their system to get stability (and I feel this is a very legitimate argument). Additionally, FreeBSD doesn't offer ZFS as a filesystem during installation. PC-BSD does, AFAIK. So on FreeBSD, you have to go through a bunch of rigmarole[5] to get it to work (and doing this after-the-fact is a real pain in the rear -- believe me, I did it this weekend.) So until both of these ZFS-oriented issues can be dealt with, some users aren't considering it. This is the reality of the situation. I don't think what users and administrators want is unreasonable; they may be rough demands, but that's how things are in this day and age. Have I provided enough evidence? :-) [1]: http://www.usenix.org/publications/library/proceedings/bsdcon02/mckusick/mckusick_html/index.html [2]: http://lists.freebsd.org/pipermail/freebsd-current/2006-June/064043.html [3]: http://www.usenix.org/publications/library/proceedings/usenix2000/general/full_papers/seltzer/seltzer_html/index.html [4]: http://lists.freebsd.org/pipermail/freebsd-current/2006-June/064166.html [5]: http://wiki.freebsd.org/JeremyChadwick/FreeBSD_7.x_on_a_ZFS_pool [6]: http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting [7]: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues [8]: http://lists.freebsd.org/pipermail/freebsd-stable/2007-January/032070.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 07:20:40 2008 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 483461065678; Sat, 27 Sep 2008 07:20:40 +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 EBAFF8FC1B; Sat, 27 Sep 2008 07:20:39 +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 1KjU6X-0005dk-On; Sat, 27 Sep 2008 10:20:37 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Matthew Dillon In-reply-to: <200809261818.m8QII6jF004333@apollo.backplane.com> References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> <20080926143153.GA26978@icarus.home.lan> <200809261818.m8QII6jF004333@apollo.backplane.com> Comments: In-reply-to Matthew Dillon message dated "Fri, 26 Sep 2008 11:18:06 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Sep 2008 10:20:37 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Sat, 27 Sep 2008 07:20:40 -0000 > > :> -vfs.nfs.realign_test: 22141777 > :> +vfs.nfs.realign_test: 498351 > :> > :> -vfs.nfsrv.realign_test: 5005908 > :> +vfs.nfsrv.realign_test: 0 > :> > :> +vfs.nfsrv.commit_miss: 0 > :> +vfs.nfsrv.commit_blks: 0 > :> > :> changing them did nothing - or at least with respect to nfs throughput :-) > : > :I'm not sure what any of these do, as NFS is a bit out of my league. > ::-) I'll be following this thread though! > : > :-- > :| Jeremy Chadwick jdc at parodius.com | > > A non-zero nfs_realign_count is bad, it means NFS had to copy the > mbuf chain to fix the alignment. nfs_realign_test is just the > number of times it checked. So nfs_realign_test is irrelevant. > it's nfs_realign_count that matters. > it's zero, so I guess I'm ok there. funny though, on my 'good' machine, vfs.nfsrv.realign_test: 5862999 and on the slow one, it's 0 - but then again the good one has been up for several days. > Several things can cause NFS payloads to be improperly aligned. > Anything from older network drivers which can't start DMA on a > 2-byte boundary, resulting in the 14-byte encapsulation header > causing improper alignment of the IP header & payload, to rpc > embedded in NFS TCP streams winding up being misaligned. > > Modern network hardware either support 2-byte-aligned DMA, allowing > the encapsulation to be 2-byte aligned so the payload winds up being > 4-byte aligned, or support DMA chaining allowing the payload to be > placed in its own mbuf, or pad, etc. > > -- > > One thing I would check is to be sure a couple of nfsiod's are running > on the client when doing your tests. If none are running the RPCs wind > up being more synchronous and less pipelined. Another thing I would > check is IP fragment reassembly statistics (for UDP) - there should be > none for TCP connections no matter what the NFS I/O size selected. > ahh, nfsiod, it seems that it's now dynamicaly started! at least none show when host is idle, after i run my tests there are 20! with ppid 0 need to refresh my NFS knowledge. how can I see the IP fragment reassembly statistics? > (It does seem more likely to be scheduler-related, though). > tend to agree, I tried bith ULE/BSD, but the badness is there. > -Matt > thanks, danny From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 07:23:50 2008 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 CCE261065693; Sat, 27 Sep 2008 07:23:50 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 83C088FC14; Sat, 27 Sep 2008 07:23:50 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m8R7Nevi009153; Sat, 27 Sep 2008 00:23:40 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m8R7NeEv009152; Sat, 27 Sep 2008 00:23:40 -0700 (PDT) Date: Sat, 27 Sep 2008 00:23:40 -0700 (PDT) From: Matthew Dillon Message-Id: <200809270723.m8R7NeEv009152@apollo.backplane.com> To: Danny Braniss References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> <20080926143153.GA26978@icarus.home.lan> <200809261818.m8QII6jF004333@apollo.backplane.com> Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Sat, 27 Sep 2008 07:23:50 -0000 :how can I see the IP fragment reassembly statistics? : :thanks, : danny netstat -s Also look for unexpected dropped packets, dropped fragments, and errors during the test and such, they are counted in the statistics as well. -Matt Matthew Dillon From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 07:36:22 2008 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 2C4071065686 for ; Sat, 27 Sep 2008 07:36:22 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id ACFCC8FC1B for ; Sat, 27 Sep 2008 07:36:21 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m8R7aIAC031314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Sep 2008 17:36:19 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m8R7aHbq089886; Sat, 27 Sep 2008 17:36:17 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m8R7aHnK089881; Sat, 27 Sep 2008 17:36:17 +1000 (EST) (envelope-from peter) Date: Sat, 27 Sep 2008 17:36:17 +1000 From: Peter Jeremy To: Jeremy Chadwick Message-ID: <20080927073616.GP15376@server.vk2pj.dyndns.org> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="InRyi6yyXSYzKD4c" Content-Disposition: inline In-Reply-To: <20080927064417.GA43638@icarus.home.lan> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Derek Kuli??ski , freebsd-stable@freebsd.org, Clint Olsen Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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: Sat, 27 Sep 2008 07:36:22 -0000 --InRyi6yyXSYzKD4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Sep-26 23:44:17 -0700, Jeremy Chadwick wrote: >On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote: >> As far as I know (at least ideally, when write caching is disabled) =2E.. >FreeBSD atacontrol does not let you toggle such features (although "cap" >will show you if feature is available and if it's enabled or not). True but it can be disabled via the loader tunable hw.ata.wc (at least in theory - apparently some drives don't obey the cache disable command to make them look better in benchmarks). >Users using SCSI will most definitely have the ability to disable >said feature (either via SCSI BIOS or via camcontrol). Soft-updates plus write caching isn't an issue with tagged queueing (which is standard for SCSI) because the critical point for soft-updates is knowing when the data is written to non-volatile storage - which tagged queuing provides. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --InRyi6yyXSYzKD4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjd4nAACgkQ/opHv/APuIfu8ACgiVxzBQXk8Nv7v3n9qQ70Ht1k 9q0AmgMzIKxTvks9+CXUyGENwP7FJTN7 =y0+F -----END PGP SIGNATURE----- --InRyi6yyXSYzKD4c-- From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 07:38:00 2008 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 1F3B31065677; Sat, 27 Sep 2008 07:38:00 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (h-74-0-89-210.lsanca54.covad.net [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id E13CC8FC08; Sat, 27 Sep 2008 07:37:59 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from takeda.lan (takeda.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.2/8.14.2) with ESMTP id m8R7bw37063357 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 27 Sep 2008 00:37:59 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Sat, 27 Sep 2008 00:37:50 -0700 From: =?utf-8?Q?Derek_Kuli=C5=84ski?= X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <588787159.20080927003750@takeda.tk> To: Jeremy Chadwick In-Reply-To: <20080927064417.GA43638@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94/8345/Fri Sep 26 18:20:01 2008 on chinatsu.takeda.tk X-Virus-Status: Clean Cc: freebsd-stable@FreeBSD.org, Clint Olsen Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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: Sat, 27 Sep 2008 07:38:00 -0000 Hello Jeremy, Friday, September 26, 2008, 11:44:17 PM, you wrote: >> As far as I know (at least ideally, when write caching is disabled) > Re: write caching: wheelies and burn-outs in empty parking lots > detected. > Let's be realistic. We're talking about ATA and SATA hard disks, hooked > up to on-board controllers -- these are the majority of users. Those > with ATA/SATA RAID controllers (not on-board RAID either; most/all of > those do not let you disable drive write caching) *might* have a RAID > BIOS menu item for disabling said feature. > FreeBSD atacontrol does not let you toggle such features (although "cap" > will show you if feature is available and if it's enabled or not). > Users using SCSI will most definitely have the ability to disable > said feature (either via SCSI BIOS or via camcontrol). But the majority > of users are not using SCSI disks, because the majority of users are not > going to spend hundreds of dollars on a controller followed by hundreds > of dollars for a small (~74GB) disk. > Regardless of all of this, end-users should, in no way shape or form, > be expected to go to great lengths to disable their disk's write cache. > They will not, I can assure you. Thus, we must assume: write caching > on a disk will be enabled, period. If a filesystem is engineered with > that fact ignored, then the filesystem is either 1) worthless, or 2) > serves a very niche purpose and should not be the default filesystem. > Do we agree? Yes, but... In the link you sent to me, someone mentioned that write cache is always creates problem, and it doesn't matter on OS or filesystem. There's more below. >> the data should always be consistent, and all fsck supposed to be >> doing is to free unreferenced blocks that were allocated. > fsck does a heck of a lot more than that, and there's no guarantee > that's all fsck is going to do on a UFS2+SU filesystem. I'm under the > impression it does a lot more than just looking for unref'd blocks. Yes, fsck does a lot more than that. But the whole point of soft updates is to reduce the work of fsck to deallocate allocated blocks. Anyway, maybe my information are invalid, though funny thing is that Soft Updates was mentioned in one of my lecture on Operating Systems. Apparently the goal of Soft Updates is to always enforce those rules in very efficient manner, by reordering the writes: 1. Never point to a data structure before initializing it 2. Never reuse a structure before nullifying pointers to it 3. Never reset last pointer to live structure before setting a new one 4. Always mark free-block bitmap entries as used before making the directory entry point to it The problem comes with disks which for performance reasons cache the data and then write it in different order back to the disk. I think that's the reason why it's recommended to disable it. If a disk is reordering the writes, it renders the soft updates useless. But if the writing order is preserved, all data remains always consistent, the only thing that might appear are blocks that were marked as being used, but nothing was pointing to them yet. So (in ideal situation, when nothing interferes) all fsck needs to do is just to scan the filesystem and deallocate those blocks. > The system is already up and the filesystems mounted. If the error in > question is of such severity that it would impact a user's ability to > reliably use the filesystem, how do you expect constant screaming on > the console will help? A user won't know what it means; there is > already evidence of this happening (re: mysterious ATA DMA errors which > still cannot be figured out[6]). > IMHO, a dirty filesystem should not be mounted until it's been fully > analysed/scanned by fsck. So again, people are putting faith into > UFS2+SU despite actual evidence proving that it doesn't handle all > scenarios. Yes, I think the background fsck should be disabled by default, with a possibility to enable it if the user is sure that nothing will interfere with soft updates. > The problem here is that when it was created, it was sort of an > "experiment". Now, when someone installs FreeBSD, UFS2 is the default > filesystem used, and SU are enabled on every filesystem except the root > fs. Thus, we have now put ourselves into a situation where said > feature ***must*** be reliable in all cases. I think in worst case it just is as realiable as if it wouldn't be enabled (the only danger is the background fsck) > You're also forgetting a huge focus of SU -- snapshots[1]. However, there > are more than enough facts on the table at this point concluding that > snapshots are causing more problems[7] than previously expected. And > there's further evidence filesystem snapshots shouldn't even be used in > this way[8]. there's not much to argue about that. >> Also, if I remember correctly, PJD said that gjournal is performing >> much better with small files, while softupdates is faster with big >> ones. > Okay, so now we want to talk about benchmarks. The benchmarks you're > talking about are in two places[2][3]. > The benchmarks pjd@ provided were very basic/simple, which I feel is > good, because the tests were realistic (common tasks people will do). > The benchmarks mckusick@ provided for UFS2+SU were based on SCSI > disks, which is... interesting to say the least. > Bruce Evans responded with some more data[4]. > I particularly enjoy this quote in his benchmark: "I never found the > exact cause of the slower readback ...", followed by (plausible) > speculations as to why that is. > I'm sorry that I sound like such a hard-ass on this matter, but there is > a glaring fact that people seem to be overlooking intentionally: > Filesystems have to be reliable; data integrity is focus #1, and cannot > be sacrificed. Users and administrators *expect* a filesystem to be > reliable. No one is going to keep using a filesystem if it has > disadvantages which can result in data loss or "waste of administrative > time" (which I believe is what's occurring here). > Users *will* switch to another operating system that has filesystems > which were not engineered/invented with these features in mind. Or, > they can switch to another filesystem assuming the OS offers one which > performs equally as good/well and is guaranteed to be reliable -- > and that's assuming the user wants to spend the time to reformat and > reinstall just to get that. I wasn't trying to argue about that. Perhaps my assumption is wrong, but I belive that the problems that we know about Soft Updates, at worst case make system as reliable as it was without using it. > In the case of "bit rot" (e.g. drive cache going bad silently, bad > cables, or other forms of low-level data corruption), a filesystem is > likely not to be able to cope with this (but see below). > A common rebuttal here would be: "so use UFS2 without soft updates". > Excellent advice! I might consider it myself! But the problem is that > we cannot expect users to do that. Why? Because the defaults chosen > during sysinstall are to use SU for all filesystems except root. If SU > is not reliable (or is "reliable in most cases" -- same thing if you ask > me), then it should not be enabled by default. I think we (FreeBSD) > might have been a bit hasty in deciding to choose that as a default. > Next: a system locking up (or a kernel panic) should result in a dirty > filesystem. That filesystem should be *fully recoverable* from that > kind of error, with no risk of data loss (but see below). > (There is the obvious case where a file is written to the disk, and the > disk has not completed writing the data from its internal cache to the > disk itself (re: write caching); if power is lost, the disk may not have > finished writing the cache to disk. In this case, the file is going to > be sparse -- there is absolutely nothing that can be done about this > with any filesystem, including ZFS (to my knowledge). This situation > is acceptable; nature of the beast.) > The filesystem should be fully analysed and any errors repaired (either > with user interaction or automatically -- I'm sure it depends on the > kind of error) **before** the filesystem is mounted. > This is where SU gets in the way. The filesystem is mounted and the > system is brought up + online 60 seconds before the fsck starts. The > assumption made is that the errors in question will be fully recoverable > by an automatic fsck, which as this thread proves, is not always the > case. That's why I think background fsck should be disabled by default. Though I still don't think that soft updates hurt anything (probably except performance) > ZFS is the first filesystem, to my knowledge, which provides 1) a > reliable filesystem, 2) detection of filesystem problems in real-time or > during scrubbing, 3) repair of problems in real-time (assuming raidz1 or > raidz2 are used), and 4) does not need fsck. This makes ZFS powerful. > "So use ZFS!" A good piece of advice -- however, I've already had > reports from users that they will not consider ZFS for FreeBSD at this > time. Why? Because ZFS on FreeBSD can panic the system easily due to > kmem exhaustion. Proper tuning can alleviate this problem, but users do > not want to to have to "tune" their system to get stability (and I feel > this is a very legitimate argument). > Additionally, FreeBSD doesn't offer ZFS as a filesystem during > installation. PC-BSD does, AFAIK. So on FreeBSD, you have to go > through a bunch of rigmarole[5] to get it to work (and doing this > after-the-fact is a real pain in the rear -- believe me, I did it this > weekend.) > So until both of these ZFS-oriented issues can be dealt with, some > users aren't considering it. > This is the reality of the situation. I don't think what users and > administrators want is unreasonable; they may be rough demands, but > that's how things are in this day and age. > Have I provided enough evidence? :-) Yes, but as far as I understand it's not as bad as you think :) I could be wrong though. I 100% agree on disabling background fsck, but I don't think soft updates are making the system any less reliable than it would be without it. Also, I'll have to play with ZFS some day :) -- Best regards, Derek mailto:takeda@takeda.tk It's a little-known fact that the Y1K problem caused the Dark Ages. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 08:04:02 2008 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 5305D106569E for ; Sat, 27 Sep 2008 08:04:02 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id D2C768FC1B for ; Sat, 27 Sep 2008 08:04:01 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:50304 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1KjUXw-0001Dq-4b for freebsd-stable@FreeBSD.org; Sat, 27 Sep 2008 09:48:56 +0200 Received: (qmail 68452 invoked from network); 27 Sep 2008 09:48:53 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 27 Sep 2008 09:48:53 +0200 Received: (qmail 64448 invoked by uid 1001); 27 Sep 2008 09:48:53 +0200 Date: Sat, 27 Sep 2008 09:48:53 +0200 From: Erik Trulsson To: Jeremy Chadwick Message-ID: <20080927074853.GA64298@owl.midgard.homeip.net> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080927064417.GA43638@icarus.home.lan> User-Agent: Mutt/1.5.18 (2008-05-17) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1KjUXw-0001Dq-4b. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1KjUXw-0001Dq-4b d7c47301fa55f3ccaf9b0cebdb1a7901 Cc: Derek Kuli??ski , freebsd-stable@FreeBSD.org, Clint Olsen Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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: Sat, 27 Sep 2008 08:04:02 -0000 On Fri, Sep 26, 2008 at 11:44:17PM -0700, Jeremy Chadwick wrote: > On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote: > > Hello Jeremy, > > > > Friday, September 26, 2008, 10:14:13 PM, you wrote: > > > > >> Actually what's the advantage of having fsck run in background if it > > >> isn't capable of fixing things? > > >> Isn't it more dangerous to be it like that? i.e. administrator might > > >> not notice the problem; also filesystem could break even further... > > > > > This question should really be directed at a set of different folks, > > > e.g. actual developers of said stuff (UFS2 and soft updates in > > > specific), because it's opening up a can of worms. > > > > > I believe it has to do with the fact that there is much faith given to > > > UFS2 soft updates -- the ability to background fsck allows the user to > > > boot their system and have it up and working (able to log in, etc.) in a > > > much shorter amount of time[1]. It makes the assumption that "everything > > > will work just fine", which is faulty. > > > > As far as I know (at least ideally, when write caching is disabled) > > Re: write caching: wheelies and burn-outs in empty parking lots > detected. > > Let's be realistic. We're talking about ATA and SATA hard disks, hooked > up to on-board controllers -- these are the majority of users. Those > with ATA/SATA RAID controllers (not on-board RAID either; most/all of > those do not let you disable drive write caching) *might* have a RAID > BIOS menu item for disabling said feature. > > FreeBSD atacontrol does not let you toggle such features (although "cap" > will show you if feature is available and if it's enabled or not). No, but using 'sysctl hw.ata.wc=0' will quickly and easily let you disable write caching on all ATA/SATA devices. This was actually the default setting briefly (back in 4.3 IIRC) but was reverted due to the performance penalty being considered too severe. > > Users using SCSI will most definitely have the ability to disable > said feature (either via SCSI BIOS or via camcontrol). But the majority > of users are not using SCSI disks, because the majority of users are not > going to spend hundreds of dollars on a controller followed by hundreds > of dollars for a small (~74GB) disk. > > Regardless of all of this, end-users should, in no way shape or form, > be expected to go to great lengths to disable their disk's write cache. > They will not, I can assure you. Thus, we must assume: write caching > on a disk will be enabled, period. If a filesystem is engineered with > that fact ignored, then the filesystem is either 1) worthless, or 2) > serves a very niche purpose and should not be the default filesystem. > > Do we agree? Sort of, but soft updates does not technically need write caching to be disabled. It does assume that disks will not 'lie' about if data has actually been written to the disk or just to the disk's cache. Many (most?) ATA/SATA disks are unreliable in this regard which means that the guarantees Soft Updates normally give about consistency of the file system can no longer be guaranteed. Using UFS2+soft updates on standard ATA/SATA disks (with write caching enabled) connected to a standard disk controller is not a problem (not any more than any other file system anyway.) Using background fsck together with the above setup is not recommended however. Background fsck will only handle a subset of the errors that a standard foreground fsck can handle. In particular it assumes that the soft updates guarantees of consistency are in place which would mean that there are only a few non-critical problems that could happen. With the above setup those guarantees are not in place, which means that background fsck can encounter errors it cannot (and will not) fix. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 08:05:01 2008 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 BCD7410656D0 for ; Sat, 27 Sep 2008 08:05:01 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id BA0D28FC13 for ; Sat, 27 Sep 2008 08:05:00 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 97203 invoked from network); 27 Sep 2008 08:04:58 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 27 Sep 2008 08:04:58 -0000 Date: Sat, 27 Sep 2008 10:04:58 +0200 (CEST) Message-Id: <20080927.100458.74661341.sthaug@nethelp.no> To: freebsd-stable@FreeBSD.org From: sthaug@nethelp.no In-Reply-To: <588787159.20080927003750@takeda.tk> References: <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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: Sat, 27 Sep 2008 08:05:01 -0000 > > IMHO, a dirty filesystem should not be mounted until it's been fully > > analysed/scanned by fsck. So again, people are putting faith into > > UFS2+SU despite actual evidence proving that it doesn't handle all > > scenarios. > > Yes, I think the background fsck should be disabled by default, with a > possibility to enable it if the user is sure that nothing will > interfere with soft updates. Having been bitten by problems in this area more than once, I now always disable background fsck. Having it disabled by default has my vote too. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 08:12:41 2008 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 83D43106569C; Sat, 27 Sep 2008 08:12:41 +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 36FAD8FC17; Sat, 27 Sep 2008 08:12:41 +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 1KjUur-0006DE-GA; Sat, 27 Sep 2008 11:12:37 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Kevin Oberman" In-reply-to: <20080926221700.1C4AE4500E@ptavv.es.net> References: <20080926221700.1C4AE4500E@ptavv.es.net> Comments: In-reply-to "Kevin Oberman" message dated "Fri, 26 Sep 2008 15:17:00 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Sep 2008 11:12:37 +0300 From: Danny Braniss Message-ID: Cc: David Malone , freebsd-hackers@FreeBSD.org, Jeremy Chadwick , freebsd-stable@FreeBSD.org Subject: Re: bad NFS/UDP 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: Sat, 27 Sep 2008 08:12:41 -0000 > --==_Exmh_1222467420_5817P > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > David, > > You beat me to it. > > Danny, read the iperf man page: > -b, --bandwidth n[KM] > set target bandwidth to n bits/sec (default 1 Mbit/sec). This > setting requires UDP (-u). > > The page needs updating, though. It should read "-b, --bandwidth > n[KMG]. It also does NOT require -u. If you use -b, UDP is assumed. I did RTFM(*), but when i tried it just wouldn't work, I tried today and it's actually working - so don't RTFM before coffee! btw, even though iperf sucks, netperf udp tends to bring the server down to it's knees. danny PS: * - i don't seem to have the iperf man, all I have is iperf -h From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 09:05:14 2008 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 248D0106568A for ; Sat, 27 Sep 2008 09:05:14 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id A0AB58FC1A for ; Sat, 27 Sep 2008 09:05:13 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from [10.29.62.12] (port=64599) by fish.ish.com.au with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1KjW47-0001sv-2F; Sat, 27 Sep 2008 19:26:15 +1000 Message-Id: From: Aristedes Maniatis To: Jeremy Chadwick In-Reply-To: <20080927030204.GB40195@icarus.home.lan> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 27 Sep 2008 19:05:08 +1000 References: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> <20080927030204.GB40195@icarus.home.lan> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-stable Stable Subject: Re: sysctl maxfiles 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: Sat, 27 Sep 2008 09:05:14 -0000 On 27/09/2008, at 1:02 PM, Jeremy Chadwick wrote: > Anyway, I'd like to know why you have so many fds open > simultaneously in > the first place. We're talking over 11,000 fds actively open at > once -- > this is not a small number. What exactly is this machine doing? Are > you absolutely certain tuning this higher is justified? Have you > looked > into the possibility that you have a program which is exhausting fds > by > not closing them when finished? (Yes, this is quite common; I've seen > bad Java code cause this problem on Solaris.) Well, there was a runaway process which looks like it is leaking fds. We haven't solved it yet, but the fact that the maxfiles per machine and the maxfiles per process were so close together was really causing us grief for a while. > You're asking for trouble setting these values to the equivalent of > unlimited. Instead of asking "what would happen", you should be > asking > "why would I need to do that". > > Regarding memory implications, the Handbook goes over it. Unfortunately I've been unable to find it. While we fix the fd leak I'd like to know how high I can push these numbers and not cause other problems. Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 09:34:25 2008 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 5109D1065687 for ; Sat, 27 Sep 2008 09:34:24 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from kazon.borderworlds.dk (kazon.borderworlds.dk [213.239.213.48]) by mx1.freebsd.org (Postfix) with ESMTP id 0FFF38FC14 for ; Sat, 27 Sep 2008 09:34:23 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from dominion.borderworlds.dk (localhost [127.0.0.1]) by kazon.borderworlds.dk (Postfix) with ESMTP id ADE63170EC; Sat, 27 Sep 2008 11:34:22 +0200 (CEST) Received: by dominion.borderworlds.dk (Postfix, from userid 2000) id 4C23247A; Sat, 27 Sep 2008 11:34:22 +0200 (CEST) To: Jeremy Chadwick References: <20080927025017.GA40195@icarus.home.lan> From: Christian Laursen Date: Sat, 27 Sep 2008 11:34:21 +0200 In-Reply-To: <20080927025017.GA40195@icarus.home.lan> (Jeremy Chadwick's message of "Fri\, 26 Sep 2008 19\:50\:17 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: 7.1-PRERELEASE freezes (IPFW related) 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: Sat, 27 Sep 2008 09:34:25 -0000 Jeremy Chadwick writes: > On Fri, Sep 26, 2008 at 06:21:01PM +0200, Christian Laursen wrote: >> I decided to give 7.1-PRERELEASE a try on one of my machines to find >> out if there might be any problems I should be aware of. >> >> I quickly ran into problems. After a while the system freezes >> completely. It seems to be somehow related to the load of the machine >> as it doesn't seem to happen when it is idle. I built a kernel with >> software watchdog enabled and enabled watchdog which had the nice >> effect of turning the freeze into a panic. Hopefully that will be of >> some help. >> [snip] > A couple generic things, although I think jhb@ might be able to figure > out what's going on here: > > 1) Is this machine running the latest BIOS available? > 2) Are you running powerd(8) on this box? > 3) Does disabling ACPI (it's a menu option when booting) help? > 4) Does removing "device cpufreq" help? I tried without ACPI right after writing the previous mail without any luck. However I tried turning off various stuff and found the cause of the problem. When I tried running without my ipfw rules the crashes went away. I then immediately suspected the rules using uid matching and those were indeed responsible. I am now back to running with everything I usually have running on this machine (my primary desktop) but without the ipfw uid rules and the machine is rock stable. I have been running with debug.mpsafenet="0" most likely because I have been using ipfw uid matching. Has RELENG_7 had significant changes in this area? Since I don't need these rules anymore I have just removed them. -- Christian Laursen From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 10:14:22 2008 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 665B6106568E; Sat, 27 Sep 2008 10:14:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2FB8FC15; Sat, 27 Sep 2008 10:14:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id CAF8746B37; Sat, 27 Sep 2008 06:14:21 -0400 (EDT) Date: Sat, 27 Sep 2008 11:14:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Christian Laursen In-Reply-To: Message-ID: References: <20080927025017.GA40195@icarus.home.lan> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: 7.1-PRERELEASE freezes (IPFW related) 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: Sat, 27 Sep 2008 10:14:22 -0000 On Sat, 27 Sep 2008, Christian Laursen wrote: > I am now back to running with everything I usually have running on this > machine (my primary desktop) but without the ipfw uid rules and the machine > is rock stable. > > I have been running with debug.mpsafenet="0" most likely because I have been > using ipfw uid matching. Has RELENG_7 had significant changes in this area? > > Since I don't need these rules anymore I have just removed them. In the last few days, some previously undiscovered interactions have been discovered between the rwlock work for udp/tcp performance and ipfw uid/gid/jail rules. In essence, there were a number of edge cases where it turned out ipfw was relying on lock recursion on those locks, and that's no longer possible. I've fixed two such edge cases in HEAD and will MFC them shortly, but there is at least one other known case. I'm on the fence about whether to continue playing whack-a-mole knocking off the bugs as they are discovered, and fixing it with a hammer (having ipfw and friends check for the lock held before trying to acquire it) -- if this keeps up it's the latter for -STABLE and continuing to fix them as one-off bugs in HEAD. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 10:16:00 2008 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 4FB74106569C; Sat, 27 Sep 2008 10:16:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 26DD48FC27; Sat, 27 Sep 2008 10:16:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id B42AE46B46; Sat, 27 Sep 2008 06:15:59 -0400 (EDT) Date: Sat, 27 Sep 2008 11:15:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Danny Braniss In-Reply-To: Message-ID: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Sat, 27 Sep 2008 10:16:00 -0000 On Fri, 26 Sep 2008, Danny Braniss wrote: > after more testing, it seems it's related to changes made between Aug 4 and > Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now try > and close the gap. I think this is the best way forward -- skimming August changes, there are a number of candidate commits, including retuning of UDP hashes by mav, my rwlock changes, changes to mbuf chain handling, etc. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 11:03:31 2008 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 CC3CF1065698 for ; Sat, 27 Sep 2008 11:03:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 708D68FC1D for ; Sat, 27 Sep 2008 11:03:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA08.westchester.pa.mail.comcast.net with comcast id Kn1d1a0081HzFnQ58n3WsU; Sat, 27 Sep 2008 11:03:30 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA14.westchester.pa.mail.comcast.net with comcast id Kn3V1a0064v8bD73an3Vvi; Sat, 27 Sep 2008 11:03:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=QycZ5dHgAAAA:8 a=dMzvZbSur6M3SCRB3wAA:9 a=ZXk5nPfR0Cx_XzaHtt8A:7 a=7Nwyayq0x_QOiBbQBpnDXByYlnkA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 5250EC9432; Sat, 27 Sep 2008 04:03:29 -0700 (PDT) Date: Sat, 27 Sep 2008 04:03:29 -0700 From: Jeremy Chadwick To: Derek Kuli??ski Message-ID: <20080927110329.GA50142@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <588787159.20080927003750@takeda.tk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@FreeBSD.org, Clint Olsen Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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: Sat, 27 Sep 2008 11:03:31 -0000 On Sat, Sep 27, 2008 at 12:37:50AM -0700, Derek Kuli??ski wrote: > Friday, September 26, 2008, 11:44:17 PM, you wrote: > > >> As far as I know (at least ideally, when write caching is disabled) > > > Re: write caching: wheelies and burn-outs in empty parking lots > > detected. > > > Let's be realistic. We're talking about ATA and SATA hard disks, hooked > > up to on-board controllers -- these are the majority of users. Those > > with ATA/SATA RAID controllers (not on-board RAID either; most/all of > > those do not let you disable drive write caching) *might* have a RAID > > BIOS menu item for disabling said feature. > > > FreeBSD atacontrol does not let you toggle such features (although "cap" > > will show you if feature is available and if it's enabled or not). > > > Users using SCSI will most definitely have the ability to disable > > said feature (either via SCSI BIOS or via camcontrol). But the majority > > of users are not using SCSI disks, because the majority of users are not > > going to spend hundreds of dollars on a controller followed by hundreds > > of dollars for a small (~74GB) disk. > > > Regardless of all of this, end-users should, in no way shape or form, > > be expected to go to great lengths to disable their disk's write cache. > > They will not, I can assure you. Thus, we must assume: write caching > > on a disk will be enabled, period. If a filesystem is engineered with > > that fact ignored, then the filesystem is either 1) worthless, or 2) > > serves a very niche purpose and should not be the default filesystem. > > > Do we agree? > > Yes, but... > > In the link you sent to me, someone mentioned that write cache is > always creates problem, and it doesn't matter on OS or filesystem. > > There's more below. > > >> the data should always be consistent, and all fsck supposed to be > >> doing is to free unreferenced blocks that were allocated. > > fsck does a heck of a lot more than that, and there's no guarantee > > that's all fsck is going to do on a UFS2+SU filesystem. I'm under the > > impression it does a lot more than just looking for unref'd blocks. > > Yes, fsck does a lot more than that. But the whole point of soft > updates is to reduce the work of fsck to deallocate allocated blocks. > > Anyway, maybe my information are invalid, though funny thing is that > Soft Updates was mentioned in one of my lecture on Operating Systems. > > Apparently the goal of Soft Updates is to always enforce those rules > in very efficient manner, by reordering the writes: > 1. Never point to a data structure before initializing it > 2. Never reuse a structure before nullifying pointers to it > 3. Never reset last pointer to live structure before setting a new one > 4. Always mark free-block bitmap entries as used before making the > directory entry point to it > > The problem comes with disks which for performance reasons cache the > data and then write it in different order back to the disk. > I think that's the reason why it's recommended to disable it. > If a disk is reordering the writes, it renders the soft updates > useless. > > But if the writing order is preserved, all data remains always > consistent, the only thing that might appear are blocks that were > marked as being used, but nothing was pointing to them yet. > > So (in ideal situation, when nothing interferes) all fsck needs to do > is just to scan the filesystem and deallocate those blocks. > > > The system is already up and the filesystems mounted. If the error in > > question is of such severity that it would impact a user's ability to > > reliably use the filesystem, how do you expect constant screaming on > > the console will help? A user won't know what it means; there is > > already evidence of this happening (re: mysterious ATA DMA errors which > > still cannot be figured out[6]). > > > IMHO, a dirty filesystem should not be mounted until it's been fully > > analysed/scanned by fsck. So again, people are putting faith into > > UFS2+SU despite actual evidence proving that it doesn't handle all > > scenarios. > > Yes, I think the background fsck should be disabled by default, with a > possibility to enable it if the user is sure that nothing will > interfere with soft updates. > > > The problem here is that when it was created, it was sort of an > > "experiment". Now, when someone installs FreeBSD, UFS2 is the default > > filesystem used, and SU are enabled on every filesystem except the root > > fs. Thus, we have now put ourselves into a situation where said > > feature ***must*** be reliable in all cases. > > I think in worst case it just is as realiable as if it wouldn't be > enabled (the only danger is the background fsck) > > > You're also forgetting a huge focus of SU -- snapshots[1]. However, there > > are more than enough facts on the table at this point concluding that > > snapshots are causing more problems[7] than previously expected. And > > there's further evidence filesystem snapshots shouldn't even be used in > > this way[8]. > > there's not much to argue about that. > > >> Also, if I remember correctly, PJD said that gjournal is performing > >> much better with small files, while softupdates is faster with big > >> ones. > > > Okay, so now we want to talk about benchmarks. The benchmarks you're > > talking about are in two places[2][3]. > > > The benchmarks pjd@ provided were very basic/simple, which I feel is > > good, because the tests were realistic (common tasks people will do). > > The benchmarks mckusick@ provided for UFS2+SU were based on SCSI > > disks, which is... interesting to say the least. > > > Bruce Evans responded with some more data[4]. > > > I particularly enjoy this quote in his benchmark: "I never found the > > exact cause of the slower readback ...", followed by (plausible) > > speculations as to why that is. > > > I'm sorry that I sound like such a hard-ass on this matter, but there is > > a glaring fact that people seem to be overlooking intentionally: > > > Filesystems have to be reliable; data integrity is focus #1, and cannot > > be sacrificed. Users and administrators *expect* a filesystem to be > > reliable. No one is going to keep using a filesystem if it has > > disadvantages which can result in data loss or "waste of administrative > > time" (which I believe is what's occurring here). > > > Users *will* switch to another operating system that has filesystems > > which were not engineered/invented with these features in mind. Or, > > they can switch to another filesystem assuming the OS offers one which > > performs equally as good/well and is guaranteed to be reliable -- > > and that's assuming the user wants to spend the time to reformat and > > reinstall just to get that. > > I wasn't trying to argue about that. Perhaps my assumption is wrong, > but I belive that the problems that we know about Soft Updates, at > worst case make system as reliable as it was without using it. > > > In the case of "bit rot" (e.g. drive cache going bad silently, bad > > cables, or other forms of low-level data corruption), a filesystem is > > likely not to be able to cope with this (but see below). > > > A common rebuttal here would be: "so use UFS2 without soft updates". > > Excellent advice! I might consider it myself! But the problem is that > > we cannot expect users to do that. Why? Because the defaults chosen > > during sysinstall are to use SU for all filesystems except root. If SU > > is not reliable (or is "reliable in most cases" -- same thing if you ask > > me), then it should not be enabled by default. I think we (FreeBSD) > > might have been a bit hasty in deciding to choose that as a default. > > > Next: a system locking up (or a kernel panic) should result in a dirty > > filesystem. That filesystem should be *fully recoverable* from that > > kind of error, with no risk of data loss (but see below). > > > (There is the obvious case where a file is written to the disk, and the > > disk has not completed writing the data from its internal cache to the > > disk itself (re: write caching); if power is lost, the disk may not have > > finished writing the cache to disk. In this case, the file is going to > > be sparse -- there is absolutely nothing that can be done about this > > with any filesystem, including ZFS (to my knowledge). This situation > > is acceptable; nature of the beast.) > > > The filesystem should be fully analysed and any errors repaired (either > > with user interaction or automatically -- I'm sure it depends on the > > kind of error) **before** the filesystem is mounted. > > > This is where SU gets in the way. The filesystem is mounted and the > > system is brought up + online 60 seconds before the fsck starts. The > > assumption made is that the errors in question will be fully recoverable > > by an automatic fsck, which as this thread proves, is not always the > > case. > > That's why I think background fsck should be disabled by default. > Though I still don't think that soft updates hurt anything (probably > except performance) > > > ZFS is the first filesystem, to my knowledge, which provides 1) a > > reliable filesystem, 2) detection of filesystem problems in real-time or > > during scrubbing, 3) repair of problems in real-time (assuming raidz1 or > > raidz2 are used), and 4) does not need fsck. This makes ZFS powerful. > > > "So use ZFS!" A good piece of advice -- however, I've already had > > reports from users that they will not consider ZFS for FreeBSD at this > > time. Why? Because ZFS on FreeBSD can panic the system easily due to > > kmem exhaustion. Proper tuning can alleviate this problem, but users do > > not want to to have to "tune" their system to get stability (and I feel > > this is a very legitimate argument). > > > Additionally, FreeBSD doesn't offer ZFS as a filesystem during > > installation. PC-BSD does, AFAIK. So on FreeBSD, you have to go > > through a bunch of rigmarole[5] to get it to work (and doing this > > after-the-fact is a real pain in the rear -- believe me, I did it this > > weekend.) > > > So until both of these ZFS-oriented issues can be dealt with, some > > users aren't considering it. > > > This is the reality of the situation. I don't think what users and > > administrators want is unreasonable; they may be rough demands, but > > that's how things are in this day and age. > > > Have I provided enough evidence? :-) > > Yes, but as far as I understand it's not as bad as you think :) > I could be wrong though. > > I 100% agree on disabling background fsck, but I don't think soft > updates are making the system any less reliable than it would be > without it. With regards to all you've said: Thank you for these insights. Everything you and Erik have said has been quite educational, and I greatly appreciate it. Always good to learn from people who know more! :-) I believe we're in overall agreement with regards to background_fsck (should be disabled by default). I'd file a PR for this sort of thing, but it almost seems like something that should go to the (private) developers list for discussion first. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 11:32:57 2008 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 65F15106568B; Sat, 27 Sep 2008 11:32:57 +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 18DEE8FC1B; Sat, 27 Sep 2008 11:32:56 +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 1KjY2h-0008GC-PP; Sat, 27 Sep 2008 14:32:55 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Comments: In-reply-to Robert Watson message dated "Sat, 27 Sep 2008 11:15:59 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Sep 2008 14:32:55 +0300 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Sat, 27 Sep 2008 11:32:57 -0000 > On Fri, 26 Sep 2008, Danny Braniss wrote: > > > after more testing, it seems it's related to changes made between Aug 4 and > > Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now try > > and close the gap. > > I think this is the best way forward -- skimming August changes, there are a > number of candidate commits, including retuning of UDP hashes by mav, my > rwlock changes, changes to mbuf chain handling, etc. it more difficult than I expected. for one, the kernel date was missleading, the actual source update is the key, so the window of changes is now 28/July to 19/August. I have the diffs, but nothing yet seems relevant. on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' give the same throughput, which seem to point to UDP changes ... danny From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 16:46:17 2008 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 71595106569E for ; Sat, 27 Sep 2008 16:46:17 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id E2B048FC17 for ; Sat, 27 Sep 2008 16:46:16 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id m8RGkEar075242; Sat, 27 Sep 2008 18:46:15 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id m8RGkEIt075241; Sat, 27 Sep 2008 18:46:14 +0200 (CEST) (envelope-from olli) Date: Sat, 27 Sep 2008 18:46:14 +0200 (CEST) Message-Id: <200809271646.m8RGkEIt075241@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <20080927.100458.74661341.sthaug@nethelp.no> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sat, 27 Sep 2008 18:46:15 +0200 (CEST) Cc: Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2008 16:46:17 -0000 sthaug@nethelp.no wrote: > [...] > > > IMHO, a dirty filesystem should not be mounted until it's been fully > > > analysed/scanned by fsck. So again, people are putting faith into > > > UFS2+SU despite actual evidence proving that it doesn't handle all > > > scenarios. > > > > Yes, I think the background fsck should be disabled by default, with a > > possibility to enable it if the user is sure that nothing will > > interfere with soft updates. > > Having been bitten by problems in this area more than once, I now always > disable background fsck. Having it disabled by default has my vote too. Just a "me too" here. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 16:56:36 2008 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 B5EA3106568C for ; Sat, 27 Sep 2008 16:56:36 +0000 (UTC) (envelope-from talon@lpthe.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 464B78FC19 for ; Sat, 27 Sep 2008 16:56:36 +0000 (UTC) (envelope-from talon@lpthe.jussieu.fr) Received: from parthe.lpthe.jussieu.fr (parthe.lpthe.jussieu.fr [134.157.10.1]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id m8RGuYX5075811 for ; Sat, 27 Sep 2008 18:56:35 +0200 (CEST) X-Ids: 168 Received: from niobe.lpthe.jussieu.fr (niobe.lpthe.jussieu.fr [134.157.10.41]) by parthe.lpthe.jussieu.fr (Postfix) with ESMTP id 8104D8A074 for ; Sat, 27 Sep 2008 18:56:33 +0200 (CEST) Received: by niobe.lpthe.jussieu.fr (Postfix, from userid 2005) id 6FDEC10B; Sat, 27 Sep 2008 18:56:33 +0200 (CEST) Date: Sat, 27 Sep 2008 18:56:33 +0200 From: Michel Talon To: freebsd-stable@FreeBSD.org Message-ID: <20080927165633.GA77239@lpthe.jussieu.fr> Mail-Followup-To: Michel Talon , freebsd-stable@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (shiva.jussieu.fr [134.157.0.168]); Sat, 27 Sep 2008 18:56:35 +0200 (CEST) X-Virus-Scanned: ClamAV 0.93.3/8346/Sat Sep 27 09:08:52 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 48DE65C2.01A by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 48DE65C2.01A/134.157.10.1/parthe.lpthe.jussieu.fr/parthe.lpthe.jussieu.fr/ X-j-chkmail-Score: MSGID : 48DE65C2.01A on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.010 -> S=0.010 X-j-chkmail-Status: Ham Cc: Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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: Sat, 27 Sep 2008 16:56:36 -0000 Jeremy Chadwick wrote: > I believe we're in overall agreement with regards to background_fsck > (should be disabled by default). In fact background fsck has been introduced for a good reason: waiting for a full fsck on modern big disks is far too long. Similarly write cache is enabled on ata disks for the reason that without it performance sucks too much. My humble opinion is that you attach far far too much importance to reliability in this game. There are many reasons why corruption may happen in the files, most of them being hardware related (bad ram, overheating chipset, etc.) Hence you can never be assured that your data is perfectly reliable (except perhaps ZFS permanent checksumming), all you have is some probability of reliability. I think that for most people what is important is a good balance between the risk of catastrophic failure (which is always here, and is increased little by background fsck) and the performance and ease of use. The FreeBSD developers have chosen this middle ground, with good reason, in my opinion. People who are more concerned with the reliability of their data, and want to pay the price can always disable background fsck, maintain backups, etc. Personnally i would run away from a system requiring hours of fsck before being able to run multiuser. Neither Windows, with NTFS, nor Linux, with ext3, reiserfs, xfs, jfs, etc. require any form of scandisk or fsck. Demanding that full fsck is the default in FreeBSD is akin to alienating a large fraction of users who have greener pasture easily available. Idem for asking to disable write caching on the disks. So for most people there is a probability to get some day the UNEXPECTED SOFT UPDATE INCONSISTENCY message. They will run a full fsck in that occasion, not a terrible thing. In many years of FreeBSD use, it happened me a small number of times, and i have still to loose a file, at least that i remarked. -- Michel TALON From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 18:47:57 2008 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 C871A106568E for ; Sat, 27 Sep 2008 18:47:57 +0000 (UTC) (envelope-from john_templer@comcast.com) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 604A98FC15 for ; Sat, 27 Sep 2008 18:47:57 +0000 (UTC) (envelope-from john_templer@comcast.com) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA03.westchester.pa.mail.comcast.net with comcast id KpSh1a0010vyq2s53udwcU; Sat, 27 Sep 2008 18:37:56 +0000 Received: from [192.168.1.2] ([69.250.45.68]) by OMTA05.westchester.pa.mail.comcast.net with comcast id Kudv1a00C1UFfxx3RudwN7; Sat, 27 Sep 2008 18:37:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=gVzI5DE1bnIA:10 a=Ua6tzyQM5U0A:10 a=Tm713JXGad7zcN4kAnsA:9 a=EZLjpsD38qrNupZfJSTi71-HhB8A:4 a=CWfAmLVWKswA:10 a=764fWzJf_iXjtBBcKwwA:9 a=uaM9d_k9stlX8NCaoFEA:7 a=9DB1cXECiNgesREQTmmznH8j0YsA:4 a=gzCLkQuDyKQA:10 Message-ID: <48DE7D83.2070205@comcast.com> Date: Sat, 27 Sep 2008 14:37:55 -0400 From: "John L. Templer" User-Agent: Thunderbird 2.0.0.16 (X11/20080924) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary="------------090509000207030808030502" Cc: sos@freebsd.org Subject: 7.1-PRELEASE sporadically panicking with fatal trap 12 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: Sat, 27 Sep 2008 18:47:57 -0000 This is a multi-part message in MIME format. --------------090509000207030808030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm running 7.1-PRERELEASE, with /usr/src and /usr/ports last csup-ed just a few days ago. After being up for about a day or so the system will panic because of a page fault. I'm not completely sure, but it seems that the system is more stable when gdm and gnome are disabled in rc.conf. At least it stayed up for several days when I did that. I've run memtest several times, so I'm pretty confident it's not a memory problem. Also the stack trace is always the same, so I'm thinking it's not hardware related. I've attached a stack trace from kgdb, and the output from dmesg. I'd appreciate any help you could give me with this. --------------090509000207030808030502 Content-Type: text/plain; name="crash_report" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="crash_report" /var/crash# kgdb -n 5 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: acd1: WARNING - READ_TOC read data overrun 18>12 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:0xc0782714 stack pointer = 0x28:0xe52aec00 frame pointer = 0x28:0xe52aec18 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 = 18 (swi6: task queue) trap number = 12 panic: page fault cpuid = 0 Uptime: 8h10m38s Physical memory: 1779 MB Dumping 195 MB: 180 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/snd_cmi.ko...Reading symbols from /boot/kernel/snd_cmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_cmi.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /boot/kernel/mach64.ko...Reading symbols from /boot/kernel/mach64.ko.symbols...done. done. Loaded symbols for /boot/kernel/mach64.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:196 #1 0xc078fae7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc078fda9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc0aa174c in trap_fatal (frame=0xe52aebc0, eva=392) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0aa19d0 in trap_pfault (frame=0xe52aebc0, usermode=0, eva=392) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0aa238c in trap (frame=0xe52aebc0) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0a8827b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc0782714 in _mtx_lock_sleep (m=0xc4ff804c, tid=3302734576, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 #8 0xc078ed66 in _sema_post (sema=0xc4ff804c, file=0x0, line=0) at /usr/src/sys/kern/kern_sema.c:79 #9 0xc0513350 in ata_completed (context=0xc4ff8000, dummy=1) at /usr/src/sys/dev/ata/ata-queue.c:481 #10 0xc07c2e15 in taskqueue_run (queue=0xc4dbab80) at /usr/src/sys/kern/subr_taskqueue.c:282 #11 0xc07c3123 in taskqueue_swi_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:324 #12 0xc076f8db in ithread_loop (arg=0xc4dadb30) at /usr/src/sys/kern/kern_intr.c:1088 #13 0xc076c449 in fork_exit (callout=0xc076f720 , arg=0xc4dadb30, frame=0xe52aed38) at /usr/src/sys/kern/kern_fork.c:804 ---Type to continue, or q to quit--- #14 0xc0a882f0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 (kgdb) up 7 #7 0xc0782714 in _mtx_lock_sleep (m=0xc4ff804c, tid=3302734576, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 339 owner = (struct thread *)(v & ~MTX_FLAGMASK); (kgdb) list 334 * If the owner is running on another CPU, spin until the 335 * owner stops running or the state of the lock changes. 336 */ 337 v = m->mtx_lock; 338 if (v != MTX_UNOWNED) { 339 owner = (struct thread *)(v & ~MTX_FLAGMASK); 340 #ifdef ADAPTIVE_GIANT 341 if (TD_IS_RUNNING(owner)) { 342 #else 343 if (m != &Giant && TD_IS_RUNNING(owner)) { (kgdb) q /var/crash# dmesg Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #3: Tue Sep 23 00:01:44 EDT 2008 root@tigger:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP2000+ (1666.74-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383f9ff AMD Features=0xc0400800 real memory = 1878966272 (1791 MB) avail memory = 1828048896 (1743 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 6ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 256M pcib1: at device 1.0 on pci0 pci1: on pcib1 pcm0: port 0xd800-0xd8ff irq 10 at device 5.0 on pci0 pcm0: [ITHREAD] ohci0: mem 0xf9000000-0xf9000fff irq 5 at device 12.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xf8800000-0xf8800fff irq 11 at device 12.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xf8000000-0xf80000ff irq 10 at device 12.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 5 ports with 5 removable, self powered umass0: on uhub2 uhub3: on uhub2 uhub3: single transaction translator uhub3: 4 ports with 4 removable, self powered dc0: port 0xd400-0xd4ff mem 0xf7800000-0xf78003ff irq 11 at device 13.0 on pci0 miibus0: on dc0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:14:bf:5d:74:f6 dc0: [ITHREAD] vgapci0: port 0xd000-0xd0ff mem 0xfa000000-0xfaffffff,0xf7000000-0xf7000fff irq 10 at device 14.0 on pci0 ahc0: port 0xb800-0xb8ff mem 0xf6800000-0xf6800fff irq 15 at device 15.0 on pci0 ahc0: [ITHREAD] aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb400-0xb40f at device 17.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: flags 0x200 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 cpu0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcd7ff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen0: on uhub0 ulpt0: on uhub1 ulpt0: using bi-directional mode Timecounter "TSC" frequency 1666738536 Hz quality 800 Timecounters tick every 1.000 msec acd0: DVDROM at ata0-master UDMA33 acd1: DVDR at ata0-slave UDMA66 Waiting 5 seconds for SCSI devices to settle da1 at ahc0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 63, 16bit) da1: Command Queueing Enabled da1: 8755MB (17930694 512 byte sectors: 255H 63S/T 1116C) da2 at ahc0 bus 0 target 12 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 40.000MB/s transfers (20.000MHz, offset 127, 16bit) da2: Command Queueing Enabled da2: 35074MB (71833096 512 byte sectors: 255H 63S/T 4471C) cd0 at ahc0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 305245MB (625142448 512 byte sectors: 255H 63S/T 38913C) GEOM_LABEL: Label for provider da0s2 is msdosfs/ . Trying to mount root from ufs:/dev/da2s4a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 drm0: <3D Rage Pro 215GP> on vgapci0 info: [drm] Initialized mach64 1.0.0 20020904 --------------090509000207030808030502-- From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 18:52:29 2008 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 646B61065688; Sat, 27 Sep 2008 18:52:29 +0000 (UTC) (envelope-from dart@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.freebsd.org (Postfix) with ESMTP id 392ED8FC14; Sat, 27 Sep 2008 18:52:29 +0000 (UTC) (envelope-from dart@es.net) Received: from [192.168.13.32] (c-24-4-182-157.hsd1.ca.comcast.net [24.4.182.157]) by postal1.es.net (Postal Node 1) with ASMTP (SSL) id HBR44523; Sat, 27 Sep 2008 11:42:23 -0700 Message-ID: <48DE7E76.8050209@es.net> Date: Sat, 27 Sep 2008 11:41:58 -0700 From: Eli Dart User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Danny Braniss References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sender-IP: 24.4.182.157 X-Sender-Domain: es.net X-Recipent: ; ; ; ; X-Sender: X-To_Name: Danny Braniss X-To_Domain: cs.huji.ac.il X-To: Danny Braniss X-To_Email: danny@cs.huji.ac.il X-To_Alias: danny Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: bad NFS/UDP 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: Sat, 27 Sep 2008 18:52:29 -0000 Danny Braniss wrote: > I know, but I get about 1mgb, which seems somewhat low :-( If you don't tell iperf how much bandwidth to use for a UDP test, it defaults to 1Mbps. See -b option. http://dast.nlanr.net/projects/Iperf/iperfdocs_1.7.0.php#bandwidth --eli -- Eli Dart ESnet Network Engineering Group Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 19:42:53 2008 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 A4CCE1065690 for ; Sat, 27 Sep 2008 19:42:53 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 506BC8FC13 for ; Sat, 27 Sep 2008 19:42:53 +0000 (UTC) (envelope-from spork@bway.net) Received: (qmail 46072 invoked by uid 0); 27 Sep 2008 19:16:12 -0000 Received: from unknown (HELO toasty.nat.fasttrackmonkey.com) (spork@96.57.102.250) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Sep 2008 19:16:12 -0000 Date: Sat, 27 Sep 2008 15:16:11 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@toasty.nat.fasttrackmonkey.com To: freebsd-stable@FreeBSD.org In-Reply-To: <20080927064417.GA43638@icarus.home.lan> Message-ID: References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Recommendations for servers running SATA drives 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: Sat, 27 Sep 2008 19:42:53 -0000 I'm forking the thread on fsck/soft-updates in hopes of getting some practical advice based on the discussion here of background fsck, softupdates and write-caching on SATA drives. On Fri, 26 Sep 2008, Jeremy Chadwick wrote: > Let's be realistic. We're talking about ATA and SATA hard disks, hooked > up to on-board controllers -- these are the majority of users. Those > with ATA/SATA RAID controllers (not on-board RAID either; most/all of > those do not let you disable drive write caching) *might* have a RAID > BIOS menu item for disabling said feature. While I would love to deploy every server with SAS, that's not practical in many cases, especially for light-duty servers that are not being pushed very hard. I am taking my chances with multiple affordable drives and gmirror where I cannot throw in a 3Ware card. I imagine that many non-desktop FreeBSD users are doing the same considering you can fetch a decent 1U box with plenty of storage for not much more than $1K. I assume many here are in agreement on this point -- just making it clear that the bargain crowd is not some weird edge case in the userbase... > Regardless of all of this, end-users should, in no way shape or form, > be expected to go to great lengths to disable their disk's write cache. > They will not, I can assure you. Thus, we must assume: write caching > on a disk will be enabled, period. If a filesystem is engineered with > that fact ignored, then the filesystem is either 1) worthless, or 2) > serves a very niche purpose and should not be the default filesystem. Arguments about defaults aside, this is my first questions. If I've got a server with multiple SATA drives mirrored with gmirror, is turning on write-caching a good idea? What kind of performance impact should I expect? What is the relationship between caching, soft-updates, and either NCQ or TCQ? Here's an example of a Seagate, trimmed for brevity: Protocol Serial ATA v1.0 device model ST3160811AS Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F TCQ is clearly not supported, NCQ seems to be supported, but I don't know how to tell if it's actually enabled or not. Write-caching is currently on. The tradeoff is apparently performance vs. more reliable recovery should the machine lose power, smoke itself, etc., but all I've seen is anecdotal evidence of how bad performance gets. FWIW, this machine in particular had it's mainboard go up in smoke last week. One drive was too far gone for gmirror to rebuild it without doing a "forget" and "insert". The remaining drive was too screwy for background fsck, but a manual check in single-user left me with no real suprises or problems. > The system is already up and the filesystems mounted. If the error in > question is of such severity that it would impact a user's ability to > reliably use the filesystem, how do you expect constant screaming on > the console will help? A user won't know what it means; there is > already evidence of this happening (re: mysterious ATA DMA errors which > still cannot be figured out[6]). > > IMHO, a dirty filesystem should not be mounted until it's been fully > analysed/scanned by fsck. So again, people are putting faith into > UFS2+SU despite actual evidence proving that it doesn't handle all > scenarios. I'll ask, but it seems like the consensus here is that background fsck, while the default, is best left disabled. The cases where it might make sense are: -desktop systems -servers that have incredibly huge filesystems (and even there being able to selectively background fsck filesystems might be helpful) The first example is obvious, people want a fast-booting desktop. The second is trading long fsck times in single-user for some uncertainty. > The problem here is that when it was created, it was sort of an > "experiment". Now, when someone installs FreeBSD, UFS2 is the default > filesystem used, and SU are enabled on every filesystem except the root > fs. Thus, we have now put ourselves into a situation where said > feature ***must*** be reliable in all cases. > > You're also forgetting a huge focus of SU -- snapshots[1]. However, there > are more than enough facts on the table at this point concluding that > snapshots are causing more problems[7] than previously expected. And > there's further evidence filesystem snapshots shouldn't even be used in > this way[8]. ... > Filesystems have to be reliable; data integrity is focus #1, and cannot > be sacrificed. Users and administrators *expect* a filesystem to be > reliable. No one is going to keep using a filesystem if it has > disadvantages which can result in data loss or "waste of administrative > time" (which I believe is what's occurring here). The softupdates question seems tied quite closely to the write-caching question. If write-caching "breaks" SU, that makes things tricky. So another big question: If write-caching is enabled, should SU be disabled? And again, what kind of performance and/or reliability sacrifices are being made? I'd love to hear some input from both admins dealing with this stuff in production and from any developers who are making decisions about the future direction of all of this. Thanks, Charles > [1]: http://www.usenix.org/publications/library/proceedings/bsdcon02/mckusick/mckusick_html/index.html > [6]: http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting > [7]: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > [8]: http://lists.freebsd.org/pipermail/freebsd-stable/2007-January/032070.html > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > 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 Sat Sep 27 20:13:39 2008 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 D0131106568C; Sat, 27 Sep 2008 20:13:39 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8C88FC15; Sat, 27 Sep 2008 20:13:39 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 9B6DC19E02A; Sat, 27 Sep 2008 22:13:37 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 6B29519E027; Sat, 27 Sep 2008 22:13:35 +0200 (CEST) Message-ID: <48DE9411.8010002@quip.cz> Date: Sat, 27 Sep 2008 22:14:09 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Jeremy Chadwick References: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> <20080927030204.GB40195@icarus.home.lan> In-Reply-To: <20080927030204.GB40195@icarus.home.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Stable Subject: Re: sysctl maxfiles 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: Sat, 27 Sep 2008 20:13:39 -0000 Jeremy Chadwick wrote: > On Sat, Sep 27, 2008 at 11:10:01AM +1000, Aristedes Maniatis wrote: > >>By default FreeBSD 7.0 shipped with the sysctls set to: >> >>kern.maxfiles: 12328 >>kern.maxfilesperproc: 11095 [...] > Anyway, I'd like to know why you have so many fds open simultaneously in > the first place. We're talking over 11,000 fds actively open at once -- > this is not a small number. What exactly is this machine doing? Are > you absolutely certain tuning this higher is justified? Have you looked > into the possibility that you have a program which is exhausting fds by > not closing them when finished? (Yes, this is quite common; I've seen > bad Java code cause this problem on Solaris.) I can imagine some webhosting machine running Apache virtualhosts. Each virtual host using 3 logfiles (access log, error log, IO log) so it is "only" about 4000 domains (virtualhosts) which is not so uncommon in these days ;) I don't know what files are "really" open in the meaning of kern.maxfiles. I have webserver with about 100 hosted domains and there is some numbers: root@roxy ~/# fstat -u www | wc -l 9931 root@roxy ~/# fstat -u root | wc -l 718 root@roxy ~/# fstat | grep httpd | wc -l 6379 root@roxy ~/# fstat | grep httpd | wc -l 6002 root@roxy ~/# fstat -u www | wc -l 4691 root@roxy ~/# sysctl kern.openfiles kern.openfiles: 846 All above taken within few seconds. Can somebody explain the difference between kern.openfiles and fstat? Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 20:22:53 2008 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 B6BC61065698 for ; Sat, 27 Sep 2008 20:22:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 5A59F8FC0A for ; Sat, 27 Sep 2008 20:22:52 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA05.westchester.pa.mail.comcast.net with comcast id KpaB1a00A0SCNGk55wNs7X; Sat, 27 Sep 2008 20:22:52 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA09.westchester.pa.mail.comcast.net with comcast id KwNq1a00F4v8bD73VwNrf8; Sat, 27 Sep 2008 20:22:52 +0000 X-Authority-Analysis: v=1.0 c=1 a=T7u0UfHZMGYA:10 a=6gU17RteXIwA:10 a=QycZ5dHgAAAA:8 a=wfoEADXWh1VhxFxo5dAA:9 a=_rjbnX32jb-BWE60tPkA:7 a=6-6gS2jo6fUNmTzoeezKdfBfMqoA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 7A61AC9432; Sat, 27 Sep 2008 13:22:50 -0700 (PDT) Date: Sat, 27 Sep 2008 13:22:50 -0700 From: Jeremy Chadwick To: Charles Sprickman Message-ID: <20080927202250.GA60980@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@FreeBSD.org Subject: Re: Recommendations for servers running SATA drives 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: Sat, 27 Sep 2008 20:22:53 -0000 On Sat, Sep 27, 2008 at 03:16:11PM -0400, Charles Sprickman wrote: > On Fri, 26 Sep 2008, Jeremy Chadwick wrote: >> Let's be realistic. We're talking about ATA and SATA hard disks, hooked >> up to on-board controllers -- these are the majority of users. Those >> with ATA/SATA RAID controllers (not on-board RAID either; most/all of >> those do not let you disable drive write caching) *might* have a RAID >> BIOS menu item for disabling said feature. > > While I would love to deploy every server with SAS, that's not practical > in many cases, especially for light-duty servers that are not being > pushed very hard. I am taking my chances with multiple affordable drives > and gmirror where I cannot throw in a 3Ware card. I imagine that many > non-desktop FreeBSD users are doing the same considering you can fetch a > decent 1U box with plenty of storage for not much more than $1K. I > assume many here are in agreement on this point -- just making it clear > that the bargain crowd is not some weird edge case in the userbase... I'm in full agreement here. As much as I love SCSI (and I sincerely do) it's (IMHO unjustifiably) overpriced, simply because "it can be". You'd expect the price of SCSI to decrease over the years, but it hasn't; it's become part of a niche market, primarily intended for large businesses with cash to blow. As I said, I love SCSI, the protocol is excellent, and it's very well-supported all over the place -- and though I have no personal experience with SAS, it appears to be equally as excellent, yet the price is comparative to SCSI. Even at my place of work we use SATA disks in our filers. I suppose this is justified in the sense that a disk failure there will be less painful than it would be in a single or dual-disk server, so saving money is legitimate since RAID-5 (or whatever) is in use. But with regards to our server boxes, either single or dual SATA disks are now being used, rather than SCSI. I haven't asked our datacenter and engineering folks why we've switched, but gut feeling says "saving money" >> Regardless of all of this, end-users should, in no way shape or form, >> be expected to go to great lengths to disable their disk's write cache. >> They will not, I can assure you. Thus, we must assume: write caching >> on a disk will be enabled, period. If a filesystem is engineered with >> that fact ignored, then the filesystem is either 1) worthless, or 2) >> serves a very niche purpose and should not be the default filesystem. > > Arguments about defaults aside, this is my first questions. If I've got > a server with multiple SATA drives mirrored with gmirror, is turning on > write-caching a good idea? What kind of performance impact should I > expect? What is the relationship between caching, soft-updates, and > either NCQ or TCQ? > > Here's an example of a Seagate, trimmed for brevity: > > Protocol Serial ATA v1.0 > device model ST3160811AS > > Feature Support Enable Value Vendor > write cache yes yes > read ahead yes yes > Native Command Queuing (NCQ) yes - 31/0x1F > Tagged Command Queuing (TCQ) no no 31/0x1F > > TCQ is clearly not supported, NCQ seems to be supported, but I don't know > how to tell if it's actually enabled or not. Write-caching is currently > on. Actually, no -- FreeBSD ata(4) does not support NCQ. I believe there are some unofficial patches (or even a PR) floating around which are for testing, but out of the box, it lacks support. The hyphen you see under the Enable column is supposed to signify that (I feel it's badly placed; it should say "notsupp" or "unsupp" or something like that. Hyphen is too vague). The NCQ support patches might require AHCI as well, I forget. It's been a while. > The tradeoff is apparently performance vs. more reliable recovery should > the machine lose power, smoke itself, etc., but all I've seen is > anecdotal evidence of how bad performance gets. > > FWIW, this machine in particular had it's mainboard go up in smoke last > week. One drive was too far gone for gmirror to rebuild it without doing > a "forget" and "insert". The remaining drive was too screwy for > background fsck, but a manual check in single-user left me with no real > suprises or problems. As long as the array rebuilt fine, I believe small quirks are acceptable. Scenarios where the array *doesn't* rebuild properly when a new disk is added are of great concern (and in the case of some features such as Intel MatrixRAID, the FreeBSD bugs are so severe that you are liable to lose data in such scenarios. MatrixRAID != gmirror, of course). This also leads me a little off-topic -- when it comes to disk replacements, administrators want to be able to do this without taking the system down. There are problems with this, but it often depends greatly on hardware and BIOS configuration. I've successfully done a hot-swap (hardware: SATA hot-swap backplane, AHCI in use, SATA2 disks), but it required me to issue "atacontrol detach" first (I am very curious to know what would've happened had I just yanked the disk). Upon inserting the new disk, one has to be *very* careful about the order of atacontrol commands given -- there are cases where "attach" will cause the system to panic or SATA bus to lock up, but it seems to depend upon what commands were executed previously (such as "reinit"). Sorry if this is off-topic, but I wanted to mention it. >> The system is already up and the filesystems mounted. If the error in >> question is of such severity that it would impact a user's ability to >> reliably use the filesystem, how do you expect constant screaming on >> the console will help? A user won't know what it means; there is >> already evidence of this happening (re: mysterious ATA DMA errors which >> still cannot be figured out[6]). >> >> IMHO, a dirty filesystem should not be mounted until it's been fully >> analysed/scanned by fsck. So again, people are putting faith into >> UFS2+SU despite actual evidence proving that it doesn't handle all >> scenarios. > > I'll ask, but it seems like the consensus here is that background fsck, > while the default, is best left disabled. The cases where it might make > sense are: > > -desktop systems > -servers that have incredibly huge filesystems (and even there being able > to selectively background fsck filesystems might be helpful) > > The first example is obvious, people want a fast-booting desktop. The > second is trading long fsck times in single-user for some uncertainty. The first item I agree with, and I believe the benefits there easily outweigh the risks/quirks. The 2nd item I can go either way on; for example, my home BSD box has 4x500GB disks in it (and about 1/3rd is used/filled). If that box crashes, I *most definitely* want data integrity preserved as best as possible. Of course, I'm using ZFS + raidz1 there, so maybe I'm arguing to hear myself talk -- but at one time, I wasn't using ZFS. I suppose it ultimately depends on what the administrator wants; I don't think we'll find a default that will please everyone, and I accept that reality. >> Filesystems have to be reliable; data integrity is focus #1, and cannot >> be sacrificed. Users and administrators *expect* a filesystem to be >> reliable. No one is going to keep using a filesystem if it has >> disadvantages which can result in data loss or "waste of administrative >> time" (which I believe is what's occurring here). > > The softupdates question seems tied quite closely to the write-caching > question. If write-caching "breaks" SU, that makes things tricky. So > another big question: > > If write-caching is enabled, should SU be disabled? This is an excellent question, one I too have been pondering. If the answer is "yes", then there's two options (pick one): a) Change the defaults during sysinstall; do NOT enable SU on all non-root filesystems, b) Set hw.ata.wc=0 during the installation startup, and upon a completed FreeBSD installation, set hw.ata.wc=0 in sysctl.conf (because the user sure won't know or remember to do this). (b) has risks involved, such as the scenario where someone has two or more disks, and only one disk is dedicated to FreeBSD; hw.ata.wc=0 disables write caching for **all** disks, so they'd possibly see degraded performance on the non-OS disks once mounted. If the answer is "no", then I guess we're fine. > And again, what kind of performance and/or reliability sacrifices are > being made? > > I'd love to hear some input from both admins dealing with this stuff in > production and from any developers who are making decisions about the > future direction of all of this. As would I. Good questions, Charles! (As usual! :-) ) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 20:31:47 2008 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 69DB6106570F for ; Sat, 27 Sep 2008 20:31:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 4EC3D8FC17 for ; Sat, 27 Sep 2008 20:31:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id Kocq1a00E0cQ2SLA5wXm8j; Sat, 27 Sep 2008 20:31:46 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id KwXl1a0024v8bD78WwXlMQ; Sat, 27 Sep 2008 20:31:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=EyyiAV7YKsM3hZp1AOEA:9 a=hAig4xVbVjInWf7ClX_Z5-ELBYEA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id D365EC9432; Sat, 27 Sep 2008 13:31:44 -0700 (PDT) Date: Sat, 27 Sep 2008 13:31:44 -0700 From: Jeremy Chadwick To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20080927203144.GB60980@icarus.home.lan> References: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> <20080927030204.GB40195@icarus.home.lan> <48DE9411.8010002@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48DE9411.8010002@quip.cz> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable Stable Subject: Re: sysctl maxfiles 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: Sat, 27 Sep 2008 20:31:47 -0000 On Sat, Sep 27, 2008 at 10:14:09PM +0200, Miroslav Lachman wrote: > Jeremy Chadwick wrote: >> On Sat, Sep 27, 2008 at 11:10:01AM +1000, Aristedes Maniatis wrote: >> >>> By default FreeBSD 7.0 shipped with the sysctls set to: >>> >>> kern.maxfiles: 12328 >>> kern.maxfilesperproc: 11095 > > [...] > >> Anyway, I'd like to know why you have so many fds open simultaneously in >> the first place. We're talking over 11,000 fds actively open at once -- >> this is not a small number. What exactly is this machine doing? Are >> you absolutely certain tuning this higher is justified? Have you looked >> into the possibility that you have a program which is exhausting fds by >> not closing them when finished? (Yes, this is quite common; I've seen >> bad Java code cause this problem on Solaris.) > > I can imagine some webhosting machine running Apache virtualhosts. Each > virtual host using 3 logfiles (access log, error log, IO log) so it is > "only" about 4000 domains (virtualhosts) which is not so uncommon in > these days ;) We're a web/shell hosting provider who used to do it that way. It became unreasonable/impossible to manage. Also, if said logfiles are being placed in directories where users of those virtualhosts can remove the files (and make symlinks to other places), that's a security hole (because Apache opens webserver logfiles as root). The way we do it is much more resource-friendly: log everything to a single logfile, then every night split the logfile up (based on the CustomLog %v parameter into per-vhost log files. Apache comes with a script to do this called split-logfile. > I don't know what files are "really" open in the meaning of > kern.maxfiles. I have webserver with about 100 hosted domains and there > is some numbers: > > root@roxy ~/# fstat -u www | wc -l > 9931 I don't think this is an accurate portrait of the number of open files. The number is going to be too high; I believe entries that contain FD=jail/mmap/root/text/tr/wd are not actual descriptors (are they?) > root@roxy ~/# fstat -u root | wc -l > 718 > root@roxy ~/# fstat | grep httpd | wc -l > 6379 > root@roxy ~/# fstat | grep httpd | wc -l > 6002 > root@roxy ~/# fstat -u www | wc -l > 4691 > root@roxy ~/# sysctl kern.openfiles > kern.openfiles: 846 > > All above taken within few seconds. > > Can somebody explain the difference between kern.openfiles and fstat? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 21:41:13 2008 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 E20CE106568B for ; Sat, 27 Sep 2008 21:41:13 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5E4438FC13 for ; Sat, 27 Sep 2008 21:41:13 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id m8RLfBp5085972; Sat, 27 Sep 2008 23:41:11 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id m8RLfALZ085971; Sat, 27 Sep 2008 23:41:10 +0200 (CEST) (envelope-from olli) Date: Sat, 27 Sep 2008 23:41:10 +0200 (CEST) Message-Id: <200809272141.m8RLfALZ085971@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, 000.fbsd@quip.cz In-Reply-To: <48DE9411.8010002@quip.cz> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sat, 27 Sep 2008 23:41:11 +0200 (CEST) Cc: Subject: Re: sysctl maxfiles X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, 000.fbsd@quip.cz List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2008 21:41:14 -0000 Miroslav Lachman wrote: > I don't know what files are "really" open in the meaning of > kern.maxfiles. I have webserver with about 100 hosted domains and there > is some numbers: > > root@roxy ~/# fstat -u www | wc -l > 9931 > root@roxy ~/# fstat -u root | wc -l > 718 > root@roxy ~/# fstat | grep httpd | wc -l > 6379 > root@roxy ~/# fstat | grep httpd | wc -l > 6002 > root@roxy ~/# fstat -u www | wc -l > 4691 > root@roxy ~/# sysctl kern.openfiles > kern.openfiles: 846 > > All above taken within few seconds. > > Can somebody explain the difference between kern.openfiles and fstat? Those are different things: fstat lists file descriptors, while kern.openfiles counts open file objects, which are often shared among processes. For example, when the apache master process forks its children, the children inherit the open file objects from the parent process. While every child has its own set of file descriptors (listed separately by fstat), they reference the same underlying open file objects, so they don't contribute separately to kern.openfiles. In the same way, fstat lists stdin + stdout + stderr for almost every process, but in most cases they are not separate file objects because they were inherited from the parent process. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 21:46:32 2008 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 3A4371065688; Sat, 27 Sep 2008 21:46:32 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by mx1.freebsd.org (Postfix) with ESMTP id BEE828FC08; Sat, 27 Sep 2008 21:46:31 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m8RLkSOY001942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Sep 2008 07:46:29 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m8RLkRnV010959; Sun, 28 Sep 2008 07:46:27 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m8RLkR2O010936; Sun, 28 Sep 2008 07:46:27 +1000 (EST) (envelope-from peter) Date: Sun, 28 Sep 2008 07:46:27 +1000 From: Peter Jeremy To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20080927214627.GQ15376@server.vk2pj.dyndns.org> References: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> <20080927030204.GB40195@icarus.home.lan> <48DE9411.8010002@quip.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="46ylB6ruXBJsCJK+" Content-Disposition: inline In-Reply-To: <48DE9411.8010002@quip.cz> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Jeremy Chadwick , freebsd-stable Stable Subject: Re: sysctl maxfiles 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: Sat, 27 Sep 2008 21:46:32 -0000 --46ylB6ruXBJsCJK+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Sep-27 22:14:09 +0200, Miroslav Lachman <000.fbsd@quip.cz> wrote: >root@roxy ~/# fstat -u www | wc -l > 9931 >root@roxy ~/# fstat -u root | wc -l > 718 >root@roxy ~/# fstat | grep httpd | wc -l > 6379 >root@roxy ~/# fstat | grep httpd | wc -l > 6002 >root@roxy ~/# fstat -u www | wc -l > 4691 >root@roxy ~/# sysctl kern.openfiles >kern.openfiles: 846 kern.openfiles reflects the total number of open file structures within the kernel, whereas fstat (and lsof) report both open files and vnodes associated with each process. The differences are 1) File structures are shared via fork() etc so the same file structure can be reported multiple times. 2) fstat reports executable name, working directory and root Open files in fstat can be detected because they have numeric values (possibly with a '*' appended) in the FD column. Unfortunately, there doesn't appear to be any easy way to detect shared file structures (for inode-based files) using either fstat or lsof. In the case of apache, there are at least 6 file structures shared by each httpd process (and it looks like it might be about 15). --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --46ylB6ruXBJsCJK+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEUEARECAAYFAkjeqbMACgkQ/opHv/APuIcg7gCVEDqu6jwZ0iXUXf6zFBbfK4rU AwCeI556Q8RLq7N+4qhEbf/+2J4E3Nk= =489V -----END PGP SIGNATURE----- --46ylB6ruXBJsCJK+-- From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 22:10:03 2008 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 B4CE91065689 for ; Sat, 27 Sep 2008 22:10:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 90EA28FC0A for ; Sat, 27 Sep 2008 22:10:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 29E7A46B39 for ; Sat, 27 Sep 2008 18:10:03 -0400 (EDT) Date: Sat, 27 Sep 2008 23:10:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: stable@FreeBSD.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: Warning: known instability using ipfw "uid" rules 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: Sat, 27 Sep 2008 22:10:03 -0000 An FYI: In the past couple of days, presumably as testing of 7.x becomes more widespread, I've seen several reports of instability resulting from ipfw credential rules. For those unfamiliar with them, these allow the matching of packets in ipfw rules based on the credentials of the socket that generated them, or the credentials of the socket that likely will receive them. These problems are a side effect of elimating support for lock recursion on inpcbinfo locks as part of the UDP performance optimization work for 7.1. There are two minor TCP fixes, and a more serious ipfw bug fix, in the queue to be MFC'd in the next couple of days. Once they're fixed, please make sure any further problems with deadlocks or panics involving ipfw rules are brought to my attention. Thanks, and apologies for any inconvenience -- this issue did not arise during testing in HEAD over the course of several months, but fortunately appears fairly straight forward to resolve now that it's a bit better understood. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 22:13:40 2008 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 E36AA1065689; Sat, 27 Sep 2008 22:13:40 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 336268FC12; Sat, 27 Sep 2008 22:13:40 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id m8RLL4Do046670 ; Sat, 27 Sep 2008 23:21:05 +0200 (CEST) X-Ids: 166 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id m8RLL3T5084603 ; Sat, 27 Sep 2008 23:21:03 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id m8RLL3lw084600; Sat, 27 Sep 2008 23:21:03 +0200 (MEST) (envelope-from arno) To: stable@freebsd.org From: "Arno J. Klaassen" Date: 27 Sep 2008 23:21:00 +0200 Message-ID: Lines: 248 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (shiva.jussieu.fr [134.157.0.166]); Sat, 27 Sep 2008 23:21:05 +0200 (CEST) X-Virus-Scanned: ClamAV 0.93.3/8346/Sat Sep 27 09:08:52 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 48DEA3C0.015 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 48DEA3C0.015/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 48DEA3C0.015 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.005 -> S=0.005 X-j-chkmail-Status: Ham Cc: net@freebsd.org Subject: 7.1-PRERELEASE : bad network performance (nfe0) 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: Sat, 27 Sep 2008 22:13:41 -0000 Hello, I've serious network performance problems on a HP Turion X2 based brand new notebook; I only used a 7-1Beta CD and 7-STABLE on this thing. Scp-ing ports.tgz from a rock-stable 7-STABLE server to it gives : # scp -p ports.tgz login@mv:/tmp/ ports.tgz 100% 98MB 88.7KB/s 18:49 (doing the same thing by copy from an nfs-mounted disk even takes mores than an hour ...) Doing a top(1) aside, just shows the box 100% idle : PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 171 ki31 0K 16K CPU0 0 38:55 100.00% idle: cpu0 11 root 171 ki31 0K 16K RUN 1 38:55 100.00% idle: cpu1 13 root -32 - 0K 16K WAIT 0 0:02 0.00% swi4: clock sio 29 root -68 - 0K 16K - 0 0:00 0.00% nfe0 taskq 34 root -64 - 0K 16K WAIT 1 0:00 0.00% irq23: atapci1 1853 root 8 0 7060K 1920K wait 0 0:00 0.00% sh 878 nono 44 0 8112K 2288K CPU1 1 0:00 0.00% top 884 root 8 - 0K 16K - 1 0:00 0.00% nfsiod 0 4 root -8 - 0K 16K - 1 0:00 0.00% g_down 16 root -16 - 0K 16K - 1 0:00 0.00% yarrow 46 root 20 - 0K 16K syncer 0 0:00 0.00% syncer 3 root -8 - 0K 16K - 0 0:00 0.00% g_up 30 root -68 - 0K 16K - 0 0:00 0.00% fw0_taskq I tested : Update Bios ULE /4BSD PREEMPTION on/off PREEMPTION + IPI_PREEMPTION hw.nfe.msi[x]_disable=1 All don't seem to matter to the problem. I put two tcpdumps (server and client during another scp(1) ) on http://bare.snv.jussieu.fr/temp/tcpdump-s1518.server http://bare.snv.jussieu.fr/temp/tcpdump-s1518.client I'm far from an expert on TCP/IP, but wireshark "expert info" shows lots of sequences like : TCP Previous segment lost TCP Duplicate ACK 1 TCP Window update TCP Duplicate ACK 2 TCP Duplicate ACK 3 TCP Duplicate ACK 4 TCP Duplicate ACK 5 TCP Fast retransmission (suspected) TCP ... TCP Out-of-Order segment TCP ... As usual, feel free to contact me for further info/tests. Thanx, Arno ##### uname -a FreeBSD mv 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Sep 26 15:06:07 CEST 2008 root@m39.scito.local:/usr/obj/usr/src/sys/PAVILLON amd64 ##### pciconf -lcv (bits) nfe0@pci0:0:6:0: class=0x020000 card=0x30cf103c chip=0x045010de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP65 Ethernet' class = network subclass = ethernet cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 ##### dmesg -a Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Fri Sep 26 15:06:07 CEST 2008 root@m39.scito.local:/usr/obj/usr/src/sys/PAVILLON Timecounter "i8254" frequency 1193250 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-62 (2109.70-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 3210813440 (3062 MB) avail memory = 3104542720 (2960 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) ACPI Error (dsopcode-0671): Field [I9MN] at 544 exceeds Buffer [IORT] size 464 (bits) [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node 0xffffff00011f50a0), AE_AML_BUFFER_LIMIT ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.PMIO._CRS] (Node 0xffffff00011f50a0), AE_AML_BUFFER_LIMIT can't fetch resources for \\_SB_.PCI0.LPC0.PMIO - AE_AML_BUFFER_LIMIT Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x1d00-0x1dff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.3 (no driver attached) ohci0: mem 0xf2486000-0xf2486fff irq 18 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xf2488000-0xf24880ff irq 17 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered ugen0: on uhub1 nfe0: port 0x30e0-0x30e7 mem 0xf2487000-0xf2487fff irq 20 at device 6.0 on pci0 miibus0: on nfe0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:1e:68:5a:d2:e1 nfe0: [FILTER] pci0: at device 7.0 (no driver attached) pcib1: at device 8.0 on pci0 pci_link0: BIOS IRQ 15 for 7.5.INTA is invalid pci_link1: BIOS IRQ 10 for 7.5.INTB is invalid pci7: on pcib1 fwohci0: <1394 Open Host Controller Interface> irq 9 at device 5.0 on pci7 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:24:1b:00:a1:b7:e8:00 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:24:1b:b7:e8:00 fwe0: Ethernet address: 02:24:1b:b7:e8:00 fwip0: on firewire0 fwip0: Firewire address: 00:24:1b:00:a1:b7:e8:00 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x2550000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pci7: at device 5.1 (no driver attached) pci7: at device 5.2 (no driver attached) pci7: at device 5.3 (no driver attached) pci7: at device 5.4 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30c0-0x30cf at device 9.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x30f8-0x30ff,0x30ec-0x30ef,0x30f0-0x30f7,0x30e8-0x30eb,0x30d0-0x30df mem 0xf2484000-0xf2485fff irq 23 at device 10.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pcib2: at device 11.0 on pci0 pci1: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 ath0: mem 0xf2000000-0xf200ffff irq 16 at device 0.0 on pci3 ath0: [ITHREAD] ath0: unable to attach hardware; HAL status 13 device_attach: ath0 attach returned 6 pcib4: at device 13.0 on pci0 pci5: on pcib4 vgapci0: port 0x4000-0x407f mem 0xce000000-0xceffffff,0xd0000000-0xdfffffff,0xcc000000-0xcdffffff irq 19 at device 0.0 on pci5 pcib5: at device 14.0 on pci0 pci9: on pcib5 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_tz0: _CRT value is absurd, ignored (-72.6C) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 powernow1: on cpu1 orm0: at iomem 0xcd800-0xcefff,0xdf000-0xdffff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acpi_tz0: _CRT value is absurd, ignored (-72.6C) acd0: DVDR at ata0-master PIO4 ad4: 305245MB at ata2-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/CDROM. SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider ad4s2 is ntfs/HP_RECOVERY. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 22:18:09 2008 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 C8E471065686 for ; Sat, 27 Sep 2008 22:18:09 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 886478FC20 for ; Sat, 27 Sep 2008 22:18:09 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1Kji75-000IPz-Pa; Sat, 27 Sep 2008 18:18:07 -0400 Date: Sat, 27 Sep 2008 18:18:07 -0400 From: Gary Palmer To: Aristedes Maniatis Message-ID: <20080927221807.GE60230@in-addr.com> References: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> <20080927030204.GB40195@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-stable Stable Subject: Re: sysctl maxfiles 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: Sat, 27 Sep 2008 22:18:09 -0000 On Sat, Sep 27, 2008 at 07:05:08PM +1000, Aristedes Maniatis wrote: > > On 27/09/2008, at 1:02 PM, Jeremy Chadwick wrote: > > >Anyway, I'd like to know why you have so many fds open > >simultaneously in > >the first place. We're talking over 11,000 fds actively open at > >once -- > >this is not a small number. What exactly is this machine doing? Are > >you absolutely certain tuning this higher is justified? Have you > >looked > >into the possibility that you have a program which is exhausting fds > >by > >not closing them when finished? (Yes, this is quite common; I've seen > >bad Java code cause this problem on Solaris.) > > > Well, there was a runaway process which looks like it is leaking fds. > We haven't solved it yet, but the fact that the maxfiles per machine > and the maxfiles per process were so close together was really causing > us grief for a while. > > > > >You're asking for trouble setting these values to the equivalent of > >unlimited. Instead of asking "what would happen", you should be > >asking > >"why would I need to do that". > > > >Regarding memory implications, the Handbook goes over it. > > Unfortunately I've been unable to find it. While we fix the fd leak > I'd like to know how high I can push these numbers and not cause other > problems. At least one port recommends you set kern.maxfiles="40000" in /boot/loader.conf. I think its one of the GNOME ports. I'm pretty confident you can run that without too many problems, and maybe go higher, but if you really want to know the limit its probably kernel memory and that will depend on your workload. Solving the fd leak is by far the safest path. Note that tracking that many files is probably affecting your application performance in addition to hurting the system. Regards, Gary From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 22:29:22 2008 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 57BB11065689 for ; Sat, 27 Sep 2008 22:29:22 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id D57CD8FC2F for ; Sat, 27 Sep 2008 22:29:21 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from [10.29.62.12] (port=65514) by fish.ish.com.au with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1KjicS-0003NH-2Y; Sun, 28 Sep 2008 08:50:32 +1000 Message-Id: <51E08B08-167D-4787-BC91-11FB20B6E118@ish.com.au> From: Aristedes Maniatis To: Gary Palmer In-Reply-To: <20080927221807.GE60230@in-addr.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 28 Sep 2008 08:29:20 +1000 References: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> <20080927030204.GB40195@icarus.home.lan> <20080927221807.GE60230@in-addr.com> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-stable Stable Subject: Re: sysctl maxfiles 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: Sat, 27 Sep 2008 22:29:22 -0000 On 28/09/2008, at 8:18 AM, Gary Palmer wrote: > At least one port recommends you set > > kern.maxfiles="40000" > > in /boot/loader.conf. I think its one of the GNOME ports. I'm pretty > confident you can run that without too many problems, and maybe go > higher, > but if you really want to know the limit its probably kernel memory > and > that will depend on your workload. I guess then I should ask the question a different way. How much memory does each fd use and which pool of memory does it come from? This is ZFS if that makes any difference. Or asked a different way, if I set the number to 200,000 and some rogue process used 190,000 fds, then what bad thing would happen to the system? If any. > Solving the fd leak is by far the safest path. Note that tracking > that many files is probably affecting your application performance > in addition to hurting the system. Absolutely. We are working on it. But general Unix principles are that a non-root user should not be able to get Unix to a non-functional state. It appears that this is a very simple path to DoS, particularly since with the default settings it is easy for one process to use up all available fds and leave no more for anyone to be able to log in. Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 22:44:32 2008 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 C3F331065686 for ; Sat, 27 Sep 2008 22:44:32 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7E4978FC21 for ; Sat, 27 Sep 2008 22:44:31 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 0803B19E02A; Sun, 28 Sep 2008 00:44:30 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 8E23019E027; Sun, 28 Sep 2008 00:44:27 +0200 (CEST) Message-ID: <48DEB76D.2020706@quip.cz> Date: Sun, 28 Sep 2008 00:45:01 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Peter Jeremy References: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> <20080927030204.GB40195@icarus.home.lan> <48DE9411.8010002@quip.cz> <20080927214627.GQ15376@server.vk2pj.dyndns.org> In-Reply-To: <20080927214627.GQ15376@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Stable Subject: Re: sysctl maxfiles 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: Sat, 27 Sep 2008 22:44:32 -0000 Peter Jeremy wrote: > On 2008-Sep-27 22:14:09 +0200, Miroslav Lachman <000.fbsd@quip.cz> wrote: > >>root@roxy ~/# fstat -u www | wc -l >> 9931 >>root@roxy ~/# fstat -u root | wc -l >> 718 >>root@roxy ~/# fstat | grep httpd | wc -l >> 6379 >>root@roxy ~/# fstat | grep httpd | wc -l >> 6002 >>root@roxy ~/# fstat -u www | wc -l >> 4691 >>root@roxy ~/# sysctl kern.openfiles >>kern.openfiles: 846 > > > kern.openfiles reflects the total number of open file structures > within the kernel, whereas fstat (and lsof) report both open files > and vnodes associated with each process. The differences are > 1) File structures are shared via fork() etc so the same file structure > can be reported multiple times. > 2) fstat reports executable name, working directory and root > > Open files in fstat can be detected because they have numeric values > (possibly with a '*' appended) in the FD column. Unfortunately, there > doesn't appear to be any easy way to detect shared file structures > (for inode-based files) using either fstat or lsof. > > In the case of apache, there are at least 6 file structures shared > by each httpd process (and it looks like it might be about 15). Thank you for your explanation. (Jeremy Chadwick, Oliver Fromme, Peter Jeremy. Now it makes sense to me. Miroslav Lachmanx