From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 00:23:32 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DB0F16A419 for ; Sun, 16 Sep 2007 00:23:32 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id D918713C478 for ; Sun, 16 Sep 2007 00:23:31 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: (qmail 29125 invoked from network); 16 Sep 2007 00:23:31 -0000 Received: from dsl081-173-150.sea1.dsl.speakeasy.net (HELO dv6000.tddhome) ([64.81.173.150]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Sep 2007 00:23:31 -0000 Received: from dv6000.tddhome (localhost [127.0.0.1]) by dv6000.tddhome (8.14.1/8.14.1) with ESMTP id l8G0NUAH001325; Sat, 15 Sep 2007 17:23:30 -0700 (PDT) (envelope-from tomdean@dv6000.tddhome) Received: (from tomdean@localhost) by dv6000.tddhome (8.14.1/8.14.1/Submit) id l8G0NUQu001322; Sat, 15 Sep 2007 17:23:30 -0700 (PDT) (envelope-from tomdean) Date: Sat, 15 Sep 2007 17:23:30 -0700 (PDT) Message-Id: <200709160023.l8G0NUQu001322@dv6000.tddhome> From: "Thomas D. Dean" To: sgk@troutmask.apl.washington.edu In-reply-to: <20070915235852.GB4998@troutmask.apl.washington.edu> (message from Steve Kargl on Sat, 15 Sep 2007 16:58:52 -0700) References: <200709152159.l8FLxfha008167@dv6000.tddhome> <20070915222422.GA4487@troutmask.apl.washington.edu> <200709152255.l8FMtMSD008381@dv6000.tddhome> <20070915231526.GA4788@troutmask.apl.washington.edu> <200709152339.l8FNdVK1008558@dv6000.tddhome> <20070915235852.GB4998@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: Compiler Problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 00:23:32 -0000 I am using tcsh. # tcsh --version tcsh 6.14.00 (Astron) 2005-03-25 (i386-intel-FreeBSD) \ options wide,nls,dl,al,kan,rh,color,filec I have tried scilab with and without pvm support. I now have pvm support. # cat /var/db/ports/scilab/options # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for scilab-4.1.1_1 _OPTIONS_READ=scilab-4.1.1_1 WITHOUT_GTK2=true WITH_PVM=true I am dual boot -current and -stable on an HP Pavillion dv6446 notebook. I have a desktop with 6.2-stable and xorg 7.2. I will look at scilab there. I believe it sometimes produces the BadWindow message. I will post later about that. tomdean From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 00:32:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0960316A421 for ; Sun, 16 Sep 2007 00:32:07 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id 9BBD313C47E for ; Sun, 16 Sep 2007 00:32:06 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so926397rvb for ; Sat, 15 Sep 2007 17:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=19fucfFO7BQkv+DYf9hwfjeB6BG/7RcJmCWElhXBE6c=; b=mMqanh4Qgy6k8YCFbIOXJrn70Vq8H36+Q6e0o/juSHHtYlkC7fn7Rs3i0Bh2BByE7W6CU6nCSkOoHx4A7DbS+qXuR/rMFiksEhxbXFBVbEjAEhqG1+M1L0txoZrckQ52acdlF1HHt1A51BqYLEucp3bLaVSjaU+U5lydq+9mFl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Lg2YskXW2S6t9I6CU9T+Wbop02oY5oADrMBFmx97Jqn5pHARDI21D1wvuJZVXTTUldDzIT4K9TVaOo4FrfQIVVTvsR7jfnEraIcbfH04Xpn+ZcAhAb3Gy2rVnJWEZn2AprgobicyZ+FY3b2vSb/1H1YZecqCdTOMYdGTlZzoC2s= Received: by 10.142.141.5 with SMTP id o5mr22355wfd.1189899245136; Sat, 15 Sep 2007 16:34:05 -0700 (PDT) Received: by 10.143.1.20 with HTTP; Sat, 15 Sep 2007 16:34:05 -0700 (PDT) Message-ID: <440b3e930709151634s30690c27h2bd40a6f0be18586@mail.gmail.com> Date: Sat, 15 Sep 2007 16:34:05 -0700 From: "Ali Mashtizadeh" To: w0lfie@clear.net.nz In-Reply-To: <46ec6701.2e5.579b.9680@clear.net.nz> MIME-Version: 1.0 References: <46ec6701.2e5.579b.9680@clear.net.nz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Bruce Cran , freebsd-current@freebsd.org, Stefan Ehmann Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 00:32:07 -0000 SSBmb3VuZCB0aGUgc2FtZSBwcm9ibGVtIG9uIGEgY291cGxlIG90aGVyIGtleWJvYXJkcyBpbmNs dWRpbmcgdGhlIFN1biBVU0IKa2V5Ym9hcmRzIGJ1dCBpbnNpZGUgWCB0aGV5IHNlZW0gb2theSBm b3IgbWUuCgpBbGkKCk9uIDkvMTUvMDcsIFNhbSBCYW5rcyA8dzBsZmllQGNsZWFyLm5ldC5uej4g d3JvdGU6Cj4KPiA+RnJvbSB0aGUgb3V0cHV0IHlvdSd2ZSBib3RoIHBhc3RlZCwgaXQgYXBwZWFy cyB0aGF0IGVhY2ggb2YKPiB0aGVzZSBrZXlib2FyZHMgaGF2ZSBhIGJ1aWx0IGluIHR3byBwb3J0 IGh1Yi4gSXMgdGhpcwo+IGNvcnJlY3Q/Cj4KPiBJIGhhdmUgYSBodWIgYnVpbHQgaW50byBteSBr ZXlib2FyZCBhbmQgYWxzbyBleHBlcmllbmNlIHRoZQo+IHNhbWUgaXNzdWVzIHdpdGggdGhlIGV4 Y2VwdGlvbiBvZiBubyBMRURzIGV2ZXIgbGlnaHRpbmcgdXAuCj4KPiBJZiB0aGlzIGlzIHRoZSBj YXNlLCBpdCB3b3VsZCBhcHBlYXIgdGhhdCBGcmVlQlNEIGhhcyBpc3N1ZXMKPiBkZWFsaW5nIHdp dGggY2hhbmdpbmcgdGhlIExFRHMgb24ga2V5Ym9hcmRzIHRoYXQgY29udGFpbgo+IGh1YnMuIEkg d2lsbCBoYXZlIGEgbG9vayBpbnRvIGl0IGJ1dCBjYW4ndCBndWFyYW50ZWUKPiBhbnl0aGluZyA6 KQo+Cj4gU2FtLgo+Cj4KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIEZvbGxvd3MgLS0tLS0KPiA+ IE9uIFNhdHVyZGF5IDE1IFNlcHRlbWJlciAyMDA3IDE4OjU4OjI2IEJydWNlIENyYW4gd3JvdGU6 Cj4gPiA+IEkgaGF2ZSBhIERlbGwgVVNCIGtleWJvYXJkIHRoYXQgSSdtIHVzaW5nIHdpdGggbXkg QXRobG9uCj4gPiA+IFhQIGRlc2t0b3AgbWFjaGluZS4gICBJdCB3b3JrcyBmaW5lIG9uIC1DVVJS RU5UIHdpdGggdGhlCj4gPiA+IGV4Y2VwdGlvbiB0aGF0IHRoZSBpbmRpY2F0b3IgbGlnaHRzIGRv bid0IHdvcmsgYXMKPiA+ID4gZXhwZWN0ZWQuICAgQXQgYm9vdHVwIG9ubHkgdGhlIG51bSBsb2Nr IGluZGljYXRvciBpcyBvbiwKPiA+ID4gYXMgZXhwZWN0ZWQ7IGhvd2V2ZXIsIGlmIEkgcHJlc3Mg dGhlIG51bSBsb2NrIGtleSB0aGUKPiA+IG90aGVyIHR3byBpbmRpY2F0b3JzIGNvbWUgb24sIGFu ZCBmdXJ0aGVyIHByZXNzZXMgb2YKPiA+ID4gZWl0aGVyIG51bSBsb2NrIG9yIGNhcHMgbG9jayBj aGFuZ2UgdGhlIHN0YXRlIHRoZQo+ID4gPiBrZXlib2FyZCdzIGluIGJ1dCB0aGUgaW5kaWNhdG9y IGxpZ2h0cyByZW1haW4gbGl0IGFsbAo+ID4gPiB0aGUgdGltZS4gICBQcmVzc2luZyBzY3JvbGwg bG9jayB0b2dnbGVzIGFsbCAzIGluZGljYXRvcgo+ID4gbGlnaHRzIG9uL29mZi4gICBIYXMgYW55 b25lIGVsc2Ugc2VlbiB0aGlzIHByb2JsZW0/Cj4gPgo+ID4gSSBoYXZlIHNpbWlsYXIgaXNzdWVz IGhlcmUuIEluIFgsIHRoZSBpbmRpY2F0b3JzIGRvbid0Cj4gPiBjaGFuZ2UgYXQgYWxsLCBpbiB0 aGUgIGNvbnNvbGUgYmVoYXZpb3VyIGlzbid0IHF1aXRlIHJpZ2h0Cj4gPiBlaXRoZXIuCj4gPgo+ ID4gQnV0IGl0IG5ldmVyIGJvdGhlcmVkIG1lIGVub3VnaCB0byBhY3R1YWxseSByZXBvcnQgaXQu Cj4gPgo+ID4gdWh1YjI6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsCj4gPiBhZGRyIDE+IG9uIHVzYjIgdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZgo+ID4gcG93ZXJlZCB1a2JkMDogPENoZXJyeSBHbWJIIHByb2R1Y3QgMHgwMDAxLCBj bGFzcyAwLzAsIHJldgo+ID4gMi4wMC8wLjI2LCBhZGRyIDI+IG9uIHVodWIyIGtiZDIgYXQgdWti ZDAKPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4g PiBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0Cj4gPiBodHRwOi8vbGlz dHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWN1cnJlbnQKPiA+IFRvIHVu c3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvCj4gPiAiZnJlZWJzZC1jdXJyZW50LXVuc3Vic2Ny aWJlQGZyZWVic2Qub3JnIgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCj4gZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdAo+IGh0 dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtY3VycmVudAo+ IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWN1cnJlbnQtdW5zdWJz Y3JpYmVAZnJlZWJzZC5vcmciCj4KCgoKLS0gCkFsaSBNYXNodGl6YWRlaArYudmE24wg2YXYtNiq 24wg2LLYp9iv2YcK From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 01:02:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE92816A46C for ; Sun, 16 Sep 2007 01:02:38 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id A6BB913C458 for ; Sun, 16 Sep 2007 01:02:38 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: (qmail 7225 invoked from network); 16 Sep 2007 01:02:38 -0000 Received: from dsl081-173-150.sea1.dsl.speakeasy.net (HELO dv6000.tddhome) ([64.81.173.150]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Sep 2007 01:02:38 -0000 Received: from dv6000.tddhome (localhost [127.0.0.1]) by dv6000.tddhome (8.14.1/8.14.1) with ESMTP id l8G12bFQ001484; Sat, 15 Sep 2007 18:02:37 -0700 (PDT) (envelope-from tomdean@dv6000.tddhome) Received: (from tomdean@localhost) by dv6000.tddhome (8.14.1/8.14.1/Submit) id l8G12bAl001481; Sat, 15 Sep 2007 18:02:37 -0700 (PDT) (envelope-from tomdean) Date: Sat, 15 Sep 2007 18:02:37 -0700 (PDT) Message-Id: <200709160102.l8G12bAl001481@dv6000.tddhome> From: "Thomas D. Dean" To: sgk@troutmask.apl.washington.edu In-reply-to: <20070915235852.GB4998@troutmask.apl.washington.edu> (message from Steve Kargl on Sat, 15 Sep 2007 16:58:52 -0700) References: <200709152159.l8FLxfha008167@dv6000.tddhome> <20070915222422.GA4487@troutmask.apl.washington.edu> <200709152255.l8FMtMSD008381@dv6000.tddhome> <20070915231526.GA4788@troutmask.apl.washington.edu> <200709152339.l8FNdVK1008558@dv6000.tddhome> <20070915235852.GB4998@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: Compiler Problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 01:02:39 -0000 I see the 'hang' problem on the desktop, FreeBSD asus.tddhome 6.2-STABLE FreeBSD 6.2-STABLE #3: \ Sun Sep 9 16:33:03 PDT 2007 \ root@asus.tddhome:/usr/src/sys/GENERIC i386 xorg 7.2 scilab -debug (gdb) r (menu bar -> demos -> signal processing - bode plot) After a few minutes, scilex is using 90% of the cpu. Here is the console output. # scilab -debug 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"...(no debugging symbols found)... (gdb) r Starting program: /usr/local/lib/scilab/bin/scilex Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) Scilab : X error trapped - error message follows: BadWindow (invalid Window parameter) top ^C Program received signal SIGINT, Interrupt. 0x082c6050 in slamc3_ () (gdb) bt #0 0x082c6050 in slamc3_ () #1 0x082c6b08 in slamc1_ () #2 0x082c6375 in slamc2_ () #3 0x082c6bb9 in slamch_ () #4 0x08249ac6 in rpoly_ () #5 0x0811db58 in introots_ () #6 0x0811e754 in polelm_ () #7 0x080825d1 in callinterf_ () #8 0x080a40a1 in scirun_ () #9 0x0844ff47 in VTRun () #10 0x08454656 in main_sci () #11 0x08454c91 in realmain_ () #12 0x0807eb7a in MAIN__ () #13 0x080866e8 in main () (gdb) quit The program is running. Exit anyway? (y or n) y From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 02:08:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0826816A417 for ; Sun, 16 Sep 2007 02:08:02 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id CF59D13C461 for ; Sun, 16 Sep 2007 02:08:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id l8G27UmZ006625; Sat, 15 Sep 2007 19:07:30 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id l8G27QJO006624; Sat, 15 Sep 2007 19:07:26 -0700 (PDT) (envelope-from sgk) Date: Sat, 15 Sep 2007 19:07:26 -0700 From: Steve Kargl To: "Thomas D. Dean" Message-ID: <20070916020726.GB6447@troutmask.apl.washington.edu> References: <200709152159.l8FLxfha008167@dv6000.tddhome> <20070915222422.GA4487@troutmask.apl.washington.edu> <200709152255.l8FMtMSD008381@dv6000.tddhome> <20070915231526.GA4788@troutmask.apl.washington.edu> <200709152339.l8FNdVK1008558@dv6000.tddhome> <20070915235852.GB4998@troutmask.apl.washington.edu> <200709160102.l8G12bAl001481@dv6000.tddhome> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709160102.l8G12bAl001481@dv6000.tddhome> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Compiler Problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 02:08:02 -0000 On Sat, Sep 15, 2007 at 06:02:37PM -0700, Thomas D. Dean wrote: > (gdb) bt > #0 0x082c6050 in slamc3_ () > #1 0x082c6b08 in slamc1_ () > #2 0x082c6375 in slamc2_ () > #3 0x082c6bb9 in slamch_ () Ugh. Make sure that slamch.f (which is part of BLAS/LAPACK) is compiled without optimization. This routine tries to use clever tricks to determine machine parameters (e.g., EPSILON), and it can get stuck in infinite loops with optimization. This is known issue with LAPACK. See http://www.netlib.org/lapack/faq.html#1.25 -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 04:56:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B563816A41A for ; Sun, 16 Sep 2007 04:56:43 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id 82E3D13C458 for ; Sun, 16 Sep 2007 04:56:41 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: (qmail 14066 invoked from network); 16 Sep 2007 04:56:41 -0000 Received: from dsl081-173-150.sea1.dsl.speakeasy.net (HELO dv6000.tddhome) ([64.81.173.150]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Sep 2007 04:56:41 -0000 Received: from dv6000.tddhome (localhost [127.0.0.1]) by dv6000.tddhome (8.14.1/8.14.1) with ESMTP id l8G4ueBl023644; Sat, 15 Sep 2007 21:56:40 -0700 (PDT) (envelope-from tomdean@dv6000.tddhome) Received: (from tomdean@localhost) by dv6000.tddhome (8.14.1/8.14.1/Submit) id l8G4udLl023614; Sat, 15 Sep 2007 21:56:39 -0700 (PDT) (envelope-from tomdean) Date: Sat, 15 Sep 2007 21:56:39 -0700 (PDT) Message-Id: <200709160456.l8G4udLl023614@dv6000.tddhome> From: "Thomas D. Dean" To: sgk@troutmask.apl.washington.edu In-reply-to: <20070916020726.GB6447@troutmask.apl.washington.edu> (message from Steve Kargl on Sat, 15 Sep 2007 19:07:26 -0700) References: <200709152159.l8FLxfha008167@dv6000.tddhome> <20070915222422.GA4487@troutmask.apl.washington.edu> <200709152255.l8FMtMSD008381@dv6000.tddhome> <20070915231526.GA4788@troutmask.apl.washington.edu> <200709152339.l8FNdVK1008558@dv6000.tddhome> <20070915235852.GB4998@troutmask.apl.washington.edu> <200709160102.l8G12bAl001481@dv6000.tddhome> <20070916020726.GB6447@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: Compiler Problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 04:56:43 -0000 Aha! The problem may be due to optimization. http://www.netlib.org/lapack/faq.html#1.25 1.25) Problems compiling dlamch.f? The routine dlamch.f (and its dependent subroutines dlamc1, dlamc2, dlamc3, dlamc4, dlamc5) MUST be compiled without optimization. If you downloaded the entire lapack distribution this will be taken care of by the LAPACK/SRC/Makefile. However, if you downloaded a specific LAPACK routine plus dependencies, you need to take care that slamch.f (if you downloaded a single precision real or single precision complex routine) or dlamch.f (if you downloaded a double precision real or double precision complex routine) has been included. # cd /usr/ports/math/lapack # make clean # script 200709152133.build # make # grep -n lamc 200709152133.build 18:( cd INSTALL; make; ./testlsame; ./testslamch; ./testdlamch; ./testsecond; ./testdsecnd; cp lsame.f ../BLAS/SRC/; cp lsame.f ../SRC; cp slamch.f ../SRC/; cp dlamch.f ../SRC/; cp second.f ../SRC/; cp dsecnd.f ../SRC/; cp etime_.c ../SRC/ ) 22:gfortran42 -c slamch.f 23:gfortran42 -O -c slamchtst.f 24:gfortran42 -o testslamch slamch.o lsame.o slamchtst.o 25:gfortran42 -c dlamch.f 26:gfortran42 -O -c dlamchtst.f 27:gfortran42 -o testdlamch dlamch.o lsame.o dlamchtst.o 370:gfortran42 -O -c slamch.f 1013:gfortran42 -O -c dlamch.f 1664:gfortran42 -pg -O -o slamch.po -c slamch.f 2307:gfortran42 -pg -O -o dlamch.po -c dlamch.f 2958:gfortran42 -fpic -DPIC -O -o slamch.So -c slamch.f 3601:gfortran42 -fpic -DPIC -O -o dlamch.So -c dlamch.f slamch.f and dlamch.f are compiled three times. One time without optimizaton and two times WITH optimization! From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 05:17:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59F8716A418 for ; Sun, 16 Sep 2007 05:17:38 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 306FB13C442 for ; Sun, 16 Sep 2007 05:17:38 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id l8G5H5S6007329; Sat, 15 Sep 2007 22:17:06 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id l8G5H5qQ007328; Sat, 15 Sep 2007 22:17:05 -0700 (PDT) (envelope-from sgk) Date: Sat, 15 Sep 2007 22:17:05 -0700 From: Steve Kargl To: "Thomas D. Dean" Message-ID: <20070916051705.GA7308@troutmask.apl.washington.edu> References: <200709152159.l8FLxfha008167@dv6000.tddhome> <20070915222422.GA4487@troutmask.apl.washington.edu> <200709152255.l8FMtMSD008381@dv6000.tddhome> <20070915231526.GA4788@troutmask.apl.washington.edu> <200709152339.l8FNdVK1008558@dv6000.tddhome> <20070915235852.GB4998@troutmask.apl.washington.edu> <200709160102.l8G12bAl001481@dv6000.tddhome> <20070916020726.GB6447@troutmask.apl.washington.edu> <200709160456.l8G4udLl023614@dv6000.tddhome> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709160456.l8G4udLl023614@dv6000.tddhome> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Compiler Problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 05:17:38 -0000 On Sat, Sep 15, 2007 at 09:56:39PM -0700, Thomas D. Dean wrote: > # cd /usr/ports/math/lapack > # make clean > # script 200709152133.build > # make > # grep -n lamc 200709152133.build > 18:( cd INSTALL; make; ./testlsame; ./testslamch; ./testdlamch; ./testsecond; ./testdsecnd; cp lsame.f ../BLAS/SRC/; cp lsame.f ../SRC; cp slamch.f ../SRC/; cp dlamch.f ../SRC/; cp second.f ../SRC/; cp dsecnd.f ../SRC/; cp etime_.c ../SRC/ ) > 22:gfortran42 -c slamch.f > 23:gfortran42 -O -c slamchtst.f > 24:gfortran42 -o testslamch slamch.o lsame.o slamchtst.o > 25:gfortran42 -c dlamch.f > 26:gfortran42 -O -c dlamchtst.f > 27:gfortran42 -o testdlamch dlamch.o lsame.o dlamchtst.o > 370:gfortran42 -O -c slamch.f > 1013:gfortran42 -O -c dlamch.f > 1664:gfortran42 -pg -O -o slamch.po -c slamch.f > 2307:gfortran42 -pg -O -o dlamch.po -c dlamch.f > 2958:gfortran42 -fpic -DPIC -O -o slamch.So -c slamch.f > 3601:gfortran42 -fpic -DPIC -O -o dlamch.So -c dlamch.f > > slamch.f and dlamch.f are compiled three times. One time without > optimizaton and two times WITH optimization! Yep. The LAPACK port maintainer needs to add appropriate targets for *.po and *.So. You're probably picking up the version from the shared library. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 06:34:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D548D16A417 for ; Sun, 16 Sep 2007 06:34:45 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from viefep14-int.chello.at (viefep18-int.chello.at [213.46.255.22]) by mx1.freebsd.org (Postfix) with ESMTP id 18DDD13C45E for ; Sun, 16 Sep 2007 06:34:44 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from novel.renet.ru ([82.116.33.234]) by viefep23-int.chello.at (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20070916061813.CHTJ7338.viefep23-int.chello.at@novel.renet.ru> for ; Sun, 16 Sep 2007 08:18:13 +0200 Date: Sun, 16 Sep 2007 10:19:32 +0400 From: Roman Bogorodskiy To: freebsd-current@freebsd.org Message-ID: <20070916061932.GA93480@underworld.novel.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline X-PGP: http://people.freebsd.org/~novel/novel.key.asc Subject: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 06:34:45 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I'm curious if SCHED_ULE is designed to be used on a desktop system. I'm running -CURRENT at home and tried to use SCHED_ULE for some time. It works alright while the load is not very high. But once I start compiling something (running 'make buildworld' or 'portupgrade -a' for example), the machine comes almost unusable - X11's windows takes a lot of time to redraw, changing virtual desktop in window manager may take a several seconds. And it's nearly impossible to watch some movie with mplayer.=20 However, when I switch to SCHED_4BSD, system's reaction time gets lower and I even can watch a movie with mplayer when compiling something. Is SHCED_ULE designed to behave that way or I spotted some bug? PS I run UP system. Roman Bogorodskiy --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQCVAwUBRuzK9IB0WzgdqspGAQIQygP/Q3JMylxBMirU8PRsPDs1Em4tF/s74Set p5yBTtcn2xtUuNSKfCVChuw9wrjWv9NkN5p4JoBI7nGJmjUvoudYaRJGtK1jLjcy 5bR4NOURlDX8JgYQLIjxAjitML4t4N582WBR9Gp3xjC5dn05s3KpVjllSikDpVDo GEi90L0XJWE= =H3OT -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 06:47:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 406EF16A419; Sun, 16 Sep 2007 06:47:23 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id E52BD13C457; Sun, 16 Sep 2007 06:47:22 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8G6lK1H023713 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 16 Sep 2007 02:47:21 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sat, 15 Sep 2007 23:49:56 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Roman Bogorodskiy In-Reply-To: <20070916061932.GA93480@underworld.novel.ru> Message-ID: <20070915234855.G531@10.0.0.1> References: <20070916061932.GA93480@underworld.novel.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 06:47:23 -0000 On Sun, 16 Sep 2007, Roman Bogorodskiy wrote: > Hello, > > I'm curious if SCHED_ULE is designed to be used on a desktop system. I'm > running -CURRENT at home and tried to use SCHED_ULE for some time. It > works alright while the load is not very high. But once I start > compiling something (running 'make buildworld' or 'portupgrade -a' for > example), the machine comes almost unusable - X11's windows takes a lot > of time to redraw, changing virtual desktop in window manager may take > a several seconds. And it's nearly impossible to watch some movie with > mplayer. Roman, This is contrary to the experiences of many others. Can you send me your dmesg? There may be something about your particular hardware that is triggering a bug. ULE is definitely designed to be responsive on the desktop. Thanks, Jeff > > However, when I switch to SCHED_4BSD, system's reaction time gets lower > and I even can watch a movie with mplayer when compiling something. > > Is SHCED_ULE designed to behave that way or I spotted some bug? > > PS I run UP system. > > Roman Bogorodskiy > From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 07:23:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ED0416A419 for ; Sun, 16 Sep 2007 07:23:29 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 9F75F13C46E for ; Sun, 16 Sep 2007 07:23:28 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so1574878fka for ; Sun, 16 Sep 2007 00:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=rNaWGwY+MFgxyYUa8DhzB1L65jz8/FnTHivGtd05R/c=; b=f0dooMP/sckHD/L3mWxSxESmA7Bl9YbriZMlnZgmrmCQUvfjCulrbo1/1DcWbHbHqUecNranyd5lC/AUniNpKDDuz7xB3NTMBBi9ngc4qunkmwNW0HnvUUV69PKnKCpEKuUZ7nwJVQK7Kho/axTskQJFqtwAoePa9zvNCsZCmrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RZyJZJaWj9HmxHS9A23CJ6HS4ZKx3tVTBQ2PCU9LmVdt7HveHbWsSQ9GsOeVp1cCGKHOXMIwnJ3cXH1qT2BZk34Nro/VhshVKXjmCxW20UYpOQXAbFCnVpb97yIQ96NNWLBuM72C0v2LhNsCOH1y68iFhU5Re5MijLTiU82k7Ew= Received: by 10.86.65.11 with SMTP id n11mr2658270fga.1189927405412; Sun, 16 Sep 2007 00:23:25 -0700 (PDT) Received: by 10.86.52.6 with HTTP; Sun, 16 Sep 2007 00:23:25 -0700 (PDT) Message-ID: <11167f520709160023y107bbac2ya4f3ce5e37859574@mail.gmail.com> Date: Sun, 16 Sep 2007 02:23:25 -0500 From: "Sam Fourman Jr." To: "Ali Mashtizadeh" In-Reply-To: <440b3e930709151634s30690c27h2bd40a6f0be18586@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <46ec6701.2e5.579b.9680@clear.net.nz> <440b3e930709151634s30690c27h2bd40a6f0be18586@mail.gmail.com> Cc: Bruce Cran , w0lfie@clear.net.nz, freebsd-current@freebsd.org, Stefan Ehmann Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 07:23:29 -0000 T24gOS8xNS8wNywgQWxpIE1hc2h0aXphZGVoIDxtYXNodGl6YWRlaEBnbWFpbC5jb20+IHdyb3Rl Ogo+IEkgZm91bmQgdGhlIHNhbWUgcHJvYmxlbSBvbiBhIGNvdXBsZSBvdGhlciBrZXlib2FyZHMg aW5jbHVkaW5nIHRoZSBTdW4gVVNCCj4ga2V5Ym9hcmRzIGJ1dCBpbnNpZGUgWCB0aGV5IHNlZW0g b2theSBmb3IgbWUuCj4KPiBBbGkKPgo+IE9uIDkvMTUvMDcsIFNhbSBCYW5rcyA8dzBsZmllQGNs ZWFyLm5ldC5uej4gd3JvdGU6Cj4gPgo+ID4gPkZyb20gdGhlIG91dHB1dCB5b3UndmUgYm90aCBw YXN0ZWQsIGl0IGFwcGVhcnMgdGhhdCBlYWNoIG9mCj4gPiB0aGVzZSBrZXlib2FyZHMgaGF2ZSBh IGJ1aWx0IGluIHR3byBwb3J0IGh1Yi4gSXMgdGhpcwo+ID4gY29ycmVjdD8KPiA+Cj4gPiBJIGhh dmUgYSBodWIgYnVpbHQgaW50byBteSBrZXlib2FyZCBhbmQgYWxzbyBleHBlcmllbmNlIHRoZQo+ ID4gc2FtZSBpc3N1ZXMgd2l0aCB0aGUgZXhjZXB0aW9uIG9mIG5vIExFRHMgZXZlciBsaWdodGlu ZyB1cC4KPiA+Cj4gPiBJZiB0aGlzIGlzIHRoZSBjYXNlLCBpdCB3b3VsZCBhcHBlYXIgdGhhdCBG cmVlQlNEIGhhcyBpc3N1ZXMKPiA+IGRlYWxpbmcgd2l0aCBjaGFuZ2luZyB0aGUgTEVEcyBvbiBr ZXlib2FyZHMgdGhhdCBjb250YWluCj4gPiBodWJzLiBJIHdpbGwgaGF2ZSBhIGxvb2sgaW50byBp dCBidXQgY2FuJ3QgZ3VhcmFudGVlCj4gPiBhbnl0aGluZyA6KQo+ID4KPiA+IFNhbS4KPiA+Cj4g Pgo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSBGb2xsb3dzIC0tLS0tCj4gPiA+IE9uIFNhdHVy ZGF5IDE1IFNlcHRlbWJlciAyMDA3IDE4OjU4OjI2IEJydWNlIENyYW4gd3JvdGU6Cj4gPiA+ID4g SSBoYXZlIGEgRGVsbCBVU0Iga2V5Ym9hcmQgdGhhdCBJJ20gdXNpbmcgd2l0aCBteSBBdGhsb24K PiA+ID4gPiBYUCBkZXNrdG9wIG1hY2hpbmUuICAgSXQgd29ya3MgZmluZSBvbiAtQ1VSUkVOVCB3 aXRoIHRoZQo+ID4gPiA+IGV4Y2VwdGlvbiB0aGF0IHRoZSBpbmRpY2F0b3IgbGlnaHRzIGRvbid0 IHdvcmsgYXMKPiA+ID4gPiBleHBlY3RlZC4gICBBdCBib290dXAgb25seSB0aGUgbnVtIGxvY2sg aW5kaWNhdG9yIGlzIG9uLAo+ID4gPiA+IGFzIGV4cGVjdGVkOyBob3dldmVyLCBpZiBJIHByZXNz IHRoZSBudW0gbG9jayBrZXkgdGhlCj4gPiA+IG90aGVyIHR3byBpbmRpY2F0b3JzIGNvbWUgb24s IGFuZCBmdXJ0aGVyIHByZXNzZXMgb2YKPiA+ID4gPiBlaXRoZXIgbnVtIGxvY2sgb3IgY2FwcyBs b2NrIGNoYW5nZSB0aGUgc3RhdGUgdGhlCj4gPiA+ID4ga2V5Ym9hcmQncyBpbiBidXQgdGhlIGlu ZGljYXRvciBsaWdodHMgcmVtYWluIGxpdCBhbGwKPiA+ID4gPiB0aGUgdGltZS4gICBQcmVzc2lu ZyBzY3JvbGwgbG9jayB0b2dnbGVzIGFsbCAzIGluZGljYXRvcgo+ID4gPiBsaWdodHMgb24vb2Zm LiAgIEhhcyBhbnlvbmUgZWxzZSBzZWVuIHRoaXMgcHJvYmxlbT8KPiA+ID4KPiA+ID4gSSBoYXZl IHNpbWlsYXIgaXNzdWVzIGhlcmUuIEluIFgsIHRoZSBpbmRpY2F0b3JzIGRvbid0Cj4gPiA+IGNo YW5nZSBhdCBhbGwsIGluIHRoZSAgY29uc29sZSBiZWhhdmlvdXIgaXNuJ3QgcXVpdGUgcmlnaHQK PiA+ID4gZWl0aGVyLgo+ID4gPgo+ID4gPiBCdXQgaXQgbmV2ZXIgYm90aGVyZWQgbWUgZW5vdWdo IHRvIGFjdHVhbGx5IHJlcG9ydCBpdC4KPiA+ID4KPiA+ID4gdWh1YjI6IDxJbnRlbCBVSENJIHJv b3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsCj4gPiA+IGFkZHIgMT4gb24gdXNiMiB1 aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmCj4gPiA+IHBvd2VyZWQgdWtiZDA6 IDxDaGVycnkgR21iSCBwcm9kdWN0IDB4MDAwMSwgY2xhc3MgMC8wLCByZXYKPiA+ID4gMi4wMC8w LjI2LCBhZGRyIDI+IG9uIHVodWIyIGtiZDIgYXQgdWtiZDAKPiA+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+ID4gZnJlZWJzZC1jdXJyZW50QGZy ZWVic2Qub3JnIG1haWxpbmcgbGlzdAo+ID4gPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFp bG1hbi9saXN0aW5mby9mcmVlYnNkLWN1cnJlbnQKPiA+ID4gVG8gdW5zdWJzY3JpYmUsIHNlbmQg YW55IG1haWwgdG8KPiA+ID4gImZyZWVic2QtY3VycmVudC11bnN1YnNjcmliZUBmcmVlYnNkLm9y ZyIKPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4g PiBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0Cj4gPiBodHRwOi8vbGlz dHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWN1cnJlbnQKPiA+IFRvIHVu c3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWN1cnJlbnQtdW5zdWJzY3JpYmVA ZnJlZWJzZC5vcmciCj4gPgo+Cj4KPgo+IC0tCj4gQWxpIE1hc2h0aXphZGVoCj4g2LnZhNuMINmF 2LTYqtuMINiy2KfYr9mHCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKPiBo dHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWN1cnJlbnQK PiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1jdXJyZW50LXVuc3Vi c2NyaWJlQGZyZWVic2Qub3JnIgoKSSBoYXZlIHRoZSBTYW1lIFRyb3VibGUgd2l0aCBteSBMb2dp dGVjaCBHMTUgS2V5Ym9hcmQgaXQgdG9vIGhhcyBhIFVTQiBodWIKSSBhbSB1c2luZyAtY3VycmVu dCBmcm9tIHRoZSBhdWcgc25hcHNob3QKClNhbSBGb3VybWFuIEpyLgo+Cg== From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 07:31:12 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2538016A418; Sun, 16 Sep 2007 07:31:12 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id BC5B913C442; Sun, 16 Sep 2007 07:31:11 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8G7V7lF026836 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 16 Sep 2007 03:31:10 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sun, 16 Sep 2007 00:34:03 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Roman Bogorodskiy In-Reply-To: <20070916071421.GA1320@underworld.novel.ru> Message-ID: <20070916003323.U4507@10.0.0.1> References: <20070916061932.GA93480@underworld.novel.ru> <20070915234855.G531@10.0.0.1> <20070916071421.GA1320@underworld.novel.ru> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2052532215-1189928043=:4507" Cc: freebsd-current@FreeBSD.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 07:31:12 -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. --0-2052532215-1189928043=:4507 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sun, 16 Sep 2007, Roman Bogorodskiy wrote: > Jeff Roberson wrote: > >> This is contrary to the experiences of many others. Can you send me your >> dmesg? There may be something about your particular hardware that is >> triggering a bug. ULE is definitely designed to be responsive on the >> desktop. > > Thanks for the quick answer! > > Here's my dmesg: http://people.freebsd.org/~novel/misc/dmesg.txt Roman, The enclosed patch helps things on my system, however, there are still some delays due to IO issues. Let me know if this helps. Thanks, Jeff > > Roman Bogorodskiy > --0-2052532215-1189928043=:4507 Content-Type: TEXT/x-diff; charset=US-ASCII; name=ule.diff Content-Transfer-Encoding: BASE64 Content-ID: <20070916003403.V4507@10.0.0.1> Content-Description: Content-Disposition: attachment; filename=ule.diff SW5kZXg6IHNjaGVkX3VsZS5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpS Q1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmMs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjIwNQ0KZGlmZiAtdSAtcjEuMjA1 IHNjaGVkX3VsZS5jDQotLS0gc2NoZWRfdWxlLmMJMjAgQXVnIDIwMDcgMDY6 MzQ6MjAgLTAwMDAJMS4yMDUNCisrKyBzY2hlZF91bGUuYwkxNiBTZXAgMjAw NyAwNzowMjo1MiAtMDAwMA0KQEAgLTM5NCw3ICszOTQsNyBAQA0KIAkJICog VGhpcyBxdWV1ZSBjb250YWlucyBvbmx5IHByaW9yaXRpZXMgYmV0d2VlbiBN SU4gYW5kIE1BWA0KIAkJICogcmVhbHRpbWUuICBVc2UgdGhlIHdob2xlIHF1 ZXVlIHRvIHJlcHJlc2VudCB0aGVzZSB2YWx1ZXMuDQogCQkgKi8NCi0JCWlm ICgoZmxhZ3MgJiAoU1JRX0JPUlJPV0lOR3xTUlFfUFJFRU1QVEVEKSkgPT0g MCkgew0KKwkJaWYgKChmbGFncyAmIFNSUV9CT1JST1dJTkcpID09IDApIHsN CiAJCQlwcmkgPSAocHJpIC0gUFJJX01JTl9USU1FU0hBUkUpIC8gVFNfUlFf UFBROw0KIAkJCXByaSA9IChwcmkgKyB0ZHEtPnRkcV9pZHgpICUgUlFfTlFT Ow0KIAkJCS8qDQo= --0-2052532215-1189928043=:4507-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 07:43:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C23516A418 for ; Sun, 16 Sep 2007 07:43:46 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from mail.renet.ru (mail-local.renet.ru [82.116.32.21]) by mx1.freebsd.org (Postfix) with ESMTP id 71FFD13C459 for ; Sun, 16 Sep 2007 07:43:45 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from localhost (dcss-08.dialup.virtual.int [172.19.101.8]) by mail.renet.ru (8.14.0/8.14.0) with ESMTP id l8G7DlwI086155; Sun, 16 Sep 2007 11:13:49 +0400 (MSD) (envelope-from novel@FreeBSD.org) Date: Sun, 16 Sep 2007 11:14:21 +0400 From: Roman Bogorodskiy To: Jeff Roberson Message-ID: <20070916071421.GA1320@underworld.novel.ru> References: <20070916061932.GA93480@underworld.novel.ru> <20070915234855.G531@10.0.0.1> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <20070915234855.G531@10.0.0.1> X-PGP: http://people.freebsd.org/~novel/novel.key.asc Cc: freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 07:43:46 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jeff Roberson wrote: > This is contrary to the experiences of many others. Can you send me your= =20 > dmesg? There may be something about your particular hardware that is=20 > triggering a bug. ULE is definitely designed to be responsive on the=20 > desktop. Thanks for the quick answer! Here's my dmesg: http://people.freebsd.org/~novel/misc/dmesg.txt Roman Bogorodskiy --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iQCVAwUBRuzXzYB0WzgdqspGAQK2NwQAlZUlzCqIXpmML/4ifvG+X6F51R/iH+mX 10nn0e3CCwUKA8dnIGR6M1oCDVWXjMP0cEzdzl+0QKgE75ZSZIfWwR0cLMDDVz5A ENsZqenZorNwvwZpBXrpVV8fT0diF2Z7czTn4XgHRi86S4RKZkPuy9O+XW1sYT7w UHs5KbtV+SY= =OsEA -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 07:59:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9CBA16A419 for ; Sun, 16 Sep 2007 07:59:19 +0000 (UTC) (envelope-from vehemens@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.freebsd.org (Postfix) with ESMTP id A5B8913C442 for ; Sun, 16 Sep 2007 07:59:19 +0000 (UTC) (envelope-from vehemens@verizon.net) Received: from susy.dsl-verizon.net ([71.106.229.26]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JOG00B59BHI8SF1@vms046.mailsrvcs.net> for freebsd-current@freebsd.org; Sun, 16 Sep 2007 02:58:31 -0500 (CDT) Date: Sun, 16 Sep 2007 00:58:33 -0700 From: vehemens In-reply-to: <20070916061932.GA93480@underworld.novel.ru> To: freebsd-current@freebsd.org Message-id: <200709160058.33475.vehemens@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline References: <20070916061932.GA93480@underworld.novel.ru> User-Agent: KMail/1.9.6 Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 07:59:19 -0000 On Saturday 15 September 2007 11:19:32 pm Roman Bogorodskiy wrote: >I'm curious if SCHED_ULE is designed to be used on a desktop system. I'm >running -CURRENT at home and tried to use SCHED_ULE for some time. It >works alright while the load is not very high. But once I start >compiling something (running 'make buildworld' or 'portupgrade -a' for >example), the machine comes almost unusable - X11's windows takes a lot >of time to redraw, changing virtual desktop in window manager may take >a several seconds. And it's nearly impossible to watch some movie with >mplayer. I also see something similar running -CURRENT with SCHED_4BSD, but it shows up with X/gnome. Remote logins are still responsive and running X/twm works fine. From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 08:40:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD17D16A418 for ; Sun, 16 Sep 2007 08:40:38 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by mx1.freebsd.org (Postfix) with ESMTP id 8DC0F13C45A for ; Sun, 16 Sep 2007 08:40:38 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 4ADD011401F for ; Sun, 16 Sep 2007 08:40:37 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from tardis-plosh-net.local (tardis.vpn.isc.org [149.20.66.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 02802E6058; Sun, 16 Sep 2007 08:40:36 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Message-ID: <46ECEBF7.8070804@isc.org> Date: Sun, 16 Sep 2007 01:40:23 -0700 From: Peter Losher User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEF0342819F6957260431579E" Subject: BIND performance under FreeBSD 7-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 08:40:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEF0342819F6957260431579E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As some of you know back at BSDcan 2007, I made it known that we had seen BIND9 performance suffer under FreeBSD and that under threaded build on SMP systems, Linux had blown FreeBSD out of the water in terms of performance. As it's now (well was) EuroBSDcon, one of our engineers re-ran the query test I mentioned back at BSDcan and it looks like the work kris@ has spearheaded has paid dividends. Re: -=3D- Last night I built a disk with the August snapshot and re-ran the test. FreeBSD performance is indeed much improved -- almost as good as Linux. fbsd-7-current (200704) 44K queries/sec fbsd-7-current (200708) 84K queries/sec Gentoo Linux (2.6.20.7) 93K queries/sec Fedora Linux (2.6.20.7) 87K queries/sec Disk-to-disk copy speed is 90 MB/s for Linux and 20 MB/s for the April snapshot of FreeBSD; it is unchanged for the August FreeBSD snapshot. This is reassuring because the zone files should be in memory and disk performance shouldn't be an issue. In any case, FreeBSD-current has greatly improved between April and August. -=3D- (FYI - the disk controller on these boxes are mpt Serial SCSI) Not quite there, but a significant improvement nonetheless. If anyone needs more information about the test, let me know. Best Wishes - Peter --=20 Peter_Losher@isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow" --------------enigEF0342819F6957260431579E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFG7OwAPtVx9OgEjQgRAodJAJ4qDp72posnpnnmqujd24YrMP43IACgzzzs 3uBQOTiAXM8Bsv+ChBLvuyo= =yfUk -----END PGP SIGNATURE----- --------------enigEF0342819F6957260431579E-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 10:35:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0960916A420 for ; Sun, 16 Sep 2007 10:35:02 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from virtual.micronet.sk (smtp.micronet.sk [84.16.32.237]) by mx1.freebsd.org (Postfix) with ESMTP id B4DE113C46A for ; Sun, 16 Sep 2007 10:35:01 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by virtual.micronet.sk (Postfix) with ESMTP id 3393610E752; Sun, 16 Sep 2007 12:03:51 +0200 (CEST) X-Virus-Scanned: by amavisd-new at virtual.micronet.sk Received: from virtual.micronet.sk ([127.0.0.1]) by localhost (virtual.micronet.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noTqZ8Woxkym; Sun, 16 Sep 2007 12:03:49 +0200 (CEST) Received: from DANGER-PC (danger.mcrn.sk [84.16.37.254]) by virtual.micronet.sk (Postfix) with ESMTP id B7F0C10E528; Sun, 16 Sep 2007 12:03:49 +0200 (CEST) Date: Sun, 16 Sep 2007 12:05:52 +0200 From: Daniel Gerzo Organization: The FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1053107288.20070916120552@rulez.sk> To: Peter Losher In-Reply-To: <46ECEBF7.8070804@isc.org> References: <46ECEBF7.8070804@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: BIND performance under FreeBSD 7-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 10:35:02 -0000 Hello Peter, Sunday, September 16, 2007, 10:40:23 AM, you wrote: > As some of you know back at BSDcan 2007, I made it known that we had > seen BIND9 performance suffer under FreeBSD and that under threaded > build on SMP systems, Linux had blown FreeBSD out of the water in terms > of performance. > As it's now (well was) EuroBSDcon, one of our engineers re-ran the query > test I mentioned back at BSDcan and it looks like the work kris@ has > spearheaded has paid dividends. Re: > -=- > Last night I built a disk with the August snapshot and re-ran the test. > FreeBSD performance is indeed much improved -- almost as good as Linux. > fbsd-7-current (200704) 44K queries/sec > fbsd-7-current (200708) 84K queries/sec I'm almost certainly sure, that the 7.0 monthly snapshots are shipped with the debugging kernels, would it be maybe possible to re-run test with non-debugging kernels? -- Best regards, Daniel mailto:danger@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 11:54:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A358C16A41A for ; Sun, 16 Sep 2007 11:54:39 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 2108313C4B4 for ; Sun, 16 Sep 2007 11:54:38 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so930114nfb for ; Sun, 16 Sep 2007 04:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=7jt5EMNeDiLTsMeliJuwoUCndXf5PYRoooC6utzTGlI=; b=b9/sS/huvuu46E8K8hnqq4HrKSpOLrfV5GRCavTOmVL+jrS+mknoxczP3lTch1KLnilgD3NVCumTqt96JY7k80Bq5bqfKgf17dxR61NelNf/j6vfQ0R+vcBIk2eiqZtf2ESnF/DIMeggf6JkuJ7WmGLdJkhPsUXYXtV+hCTr/Lc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=WpIHnHhGn+0gsjHVrGe/jpBZX+mXKqtQm1ZP4GLVpdVdMKDGZOWJcGbPper+cLcgIeSZVk/ngDFbu7SpSaQKq+MgasyvulmjtdNEMh9GzZ0d1DtielX8vRIt7Ltk2YBR27vmdfA8UjB/Z7jf4oLE9Mvk5fP6TGZS97UQE2SQ27k= Received: by 10.78.168.1 with SMTP id q1mr1983352hue.1189943674468; Sun, 16 Sep 2007 04:54:34 -0700 (PDT) Received: from roadrunner.spoerlein.net ( [85.180.170.233]) by mx.google.com with ESMTPS id 39sm2847866hug.2007.09.16.04.54.33 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Sep 2007 04:54:33 -0700 (PDT) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id l8GBsSI1001627; Sun, 16 Sep 2007 13:54:28 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id l8GBsSS5001626; Sun, 16 Sep 2007 13:54:28 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Sun, 16 Sep 2007 13:54:27 +0200 From: Ulrich Spoerlein To: Scott Long Message-ID: <20070916115427.GA1427@roadrunner.spoerlein.net> Mail-Followup-To: Scott Long , freebsd-scsi@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, njl@FreeBSD.ORG References: <46E615C4.1010605@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E615C4.1010605@samsco.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-scsi@FreeBSD.ORG, njl@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 11:54:39 -0000 On Mon, 10.09.2007 at 22:12:52 -0600, Scott Long wrote: > All, > > The attached patch should make CAM behave properly with regard to > probing device serial numbers only when the device advertises that > it supports it. It will hopefully eliminate the need for the > CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated > legacy problem that may or may not be possible to fix). This should > especially benefit USB-UMASS devices, where the console output should > be less noisy. It might even make more devices work out-of-the-box. While this patch is working fine with my USB/FW HDD enclosure, it breaks my MP3 USB stick kernel: umass0: on uhub5 kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: (da0:umass-sim0:0:0:0): got CAM status 0x4 kernel: (da0:umass-sim0:0:0:0): fatal error, failed to attach to device kernel: (da0:umass-sim0:0:0:0): lost device kernel: cam_debug: queuing for immediate ccb kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: umass0: BBB reset failed, IOERROR kernel: umass0: BBB bulk-in clear stall failed, IOERROR kernel: umass0: BBB bulk-out clear stall failed, IOERROR kernel: (da0:umass-sim0:0:0:0): removing device entry This stick needs the SHUTTLE_INIT | NO_GETMAXLUN quirk. Perhaps there is some interdependencies? The patch also, does not magically allow me to read retail DVDs through my Plextor drive when attached via cd(4), but that is not the goal of the patch anyway. It's funny, though. If I quirk this Plextor DVD to NO_INQUIRY, it will attach via da(4) (sic!) and suddenly all kinds of DVD media start working! umass0: on uhub5 da0 at umass-sim0 bus 0 target 0 lun 0 da0: < > Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 3001MB (1536688 2048 byte sectors: 255H 63S/T 95C) Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 12:00:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BE6716A419 for ; Sun, 16 Sep 2007 12:00:06 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 88EA013C458 for ; Sun, 16 Sep 2007 12:00:05 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from akima.flintsbach.schmalzbauer.de (akima.flintsbach.schmalzbauer.de [172.21.1.35]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l8GBxs9w034337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Sep 2007 13:59:54 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Sun, 16 Sep 2007 13:59:48 +0200 User-Agent: KMail/1.9.7 References: <20070916061932.GA93480@underworld.novel.ru> <20070915234855.G531@10.0.0.1> In-Reply-To: <20070915234855.G531@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709161359.50560.h.schmalzbauer@omnisec.de> Cc: Jeff Roberson , Roman Bogorodskiy Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 12:00:06 -0000 Am Sonntag, 16. September 2007 08:49:56 schrieb Jeff Roberson: > On Sun, 16 Sep 2007, Roman Bogorodskiy wrote: > > Hello, > > > > I'm curious if SCHED_ULE is designed to be used on a desktop system. I'm > > running -CURRENT at home and tried to use SCHED_ULE for some time. It > > works alright while the load is not very high. But once I start > > compiling something (running 'make buildworld' or 'portupgrade -a' for > > example), the machine comes almost unusable - X11's windows takes a lot > > of time to redraw, changing virtual desktop in window manager may take > > a several seconds. And it's nearly impossible to watch some movie with > > mplayer. > > Roman, > > This is contrary to the experiences of many others. Can you send me your Not in the UP case. My i386-core2duo with SMP kernel gives _wonderful_ responsiveness, even, with buildworld -j5, I absolutely don't feel any slowdown! But when I once accidantially installed a UP kernel,the machine was very "laggy", I want to say had short "freezes" I'm also wondering that inserting a CF card in my card reader stops all io for a second. HALd is probably the culprit, but why can the system be stopped by userland? Maybe unrelated to ULE though. Thanks From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 12:37:17 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3622C16A419; Sun, 16 Sep 2007 12:37:17 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by mx1.freebsd.org (Postfix) with ESMTP id D61AD13C45E; Sun, 16 Sep 2007 12:37:16 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.3.58]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JOG005JOOE3AG20@mta-2.ms.rz.RWTH-Aachen.de>; Sun, 16 Sep 2007 14:37:15 +0200 (CEST) Received: from talos.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.3.22]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Sun, 16 Sep 2007 14:37:15 +0200 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8/8.13.8/1) with ESMTP id l8GCbEM5024246; Sun, 16 Sep 2007 14:37:14 +0200 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IWtND-00036m-54; Sun, 16 Sep 2007 14:37:15 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id C02693F41E; Sun, 16 Sep 2007 14:37:09 +0200 (CEST) Date: Sun, 16 Sep 2007 14:37:09 +0200 From: Christian Brueffer In-reply-to: <20070914164117.GC1872@haakonia.hitnet.RWTH-Aachen.DE> To: Nate Lawson Message-id: <20070916123709.GC1823@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=z6Eq5LdranGa6ru8 Content-disposition: inline X-IronPort-AV: E=Sophos;i="4.20,260,1186351200"; d="scan'208";a="22876266" X-Operating-System: FreeBSD 6.2-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <46E0777A.8070901@root.org> <20070914164117.GC1872@haakonia.hitnet.RWTH-Aachen.DE> User-Agent: Mutt/1.5.11 Cc: acpi@FreeBSD.ORG, current@FreeBSD.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 12:37:17 -0000 --z6Eq5LdranGa6ru8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 14, 2007 at 06:41:17PM +0200, Christian Brueffer wrote: > On Thu, Sep 06, 2007 at 02:56:10PM -0700, Nate Lawson wrote: > > I've done some major rework on the EC driver. This should help with > > various problems, including timeouts while checking battery status or > > temperature. The attached patches are for 6.x and 7.x. Please test and > > let me know if you get any new errors on dmesg or if it fixes things for > > you (especially HP/Compaq laptop owners). > >=20 >=20 > Tested version c on a Thinkpad T41p, everything worked before, everything > works now. >=20 I'm afraid I have to retract that statement. When I close the lid and open it again later, the display come back on. The output of `sysctl -a|grep acpi` is available here: http://people.freebsd.org/~brueffer/acpi What can I do to help debugging this? - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --z6Eq5LdranGa6ru8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFG7SN1bHYXjKDtmC0RAoSRAJsEg+rZC2IyEISZMBU+JNoO2Hw7QQCgt7GC lanz1x6wAbPS6nrFul4C/E0= =72TR -----END PGP SIGNATURE----- --z6Eq5LdranGa6ru8-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 13:21:54 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 589E616A417 for ; Sun, 16 Sep 2007 13:21:54 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id F0FE313C46A for ; Sun, 16 Sep 2007 13:21:53 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (cran1.demon.co.uk [80.177.26.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id 6F23830122; Sun, 16 Sep 2007 14:21:52 +0100 (BST) Message-ID: <46ED2D71.30608@cran.org.uk> Date: Sun, 16 Sep 2007 14:19:45 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: "Christian S.J. Peron" References: <46DA0C5E.1050506@barafranca.com> <20070903034754.GA79704@sub.vaned.net> In-Reply-To: <20070903034754.GA79704@sub.vaned.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG, Hugo Subject: Re: rtfree: 0xc3e377f8 has 1 refs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 13:21:54 -0000 Christian S.J. Peron wrote: > Basically, this looks like a side effect of calling rtfree() on a route > when we dont hold the last reference. In reality we should be using the > RTFREE()/REFREE_LOCKED() helper macros which manage reference counts > in this case. > > I have attached a patch, please let me know if this helps. BTW, nice > hostname :) I was also seeing this message after setting up an IPv6 tunnel on a recent -CURRENT build - after applying the patch the messages have gone. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 13:55:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A16216A418 for ; Sun, 16 Sep 2007 13:55:36 +0000 (UTC) (envelope-from ss.alert@online.no) Received: from mail48.e.nsc.no (mail48.e.nsc.no [193.213.115.48]) by mx1.freebsd.org (Postfix) with ESMTP id 8603913C442 for ; Sun, 16 Sep 2007 13:55:35 +0000 (UTC) (envelope-from ss.alert@online.no) Received: from [192.168.1.222] (ti0034a340-0734.bb.online.no [88.90.2.222]) by mail48.nsc.no (8.13.8/8.13.5) with ESMTP id l8GDtXBr018867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 16 Sep 2007 15:55:34 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070824184411.GA29878@twoflower.idi.ntnu.no> References: <46BFE620.8070906@fusiongol.com> <20070813091802.GB3078@stud.ntnu.no> <20070823071056.GA50852@obiwan.tataz.chchile.org> <20070824184411.GA29878@twoflower.idi.ntnu.no> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sverre Svenningsen Date: Sun, 16 Sep 2007 15:55:31 +0200 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.3) Subject: Re: Promise SATA 300 TX4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 13:55:36 -0000 On Aug 24, 2007, at 20:44 , Ulf Lilleengen wrote: > On tor, aug 23, 2007 at 09:10:56am +0200, Jeremie Le Hen wrote: >> Hi Ulf, >> >> On Mon, Aug 13, 2007 at 11:18:02AM +0200, Ulf Lilleengen wrote: >>> I have problems with this card in -CURRENT too. Details can be found >>> here: >>> http://lists.freebsd.org/pipermail/freebsd-current/2007-July/ >>> 074960.html >>> >>> I never bothered trying with earlier versions of -CURRENT, but it >>> works good in 6.2. >> >> I'm planning to switch my own server from 6.2 to -CURRENT soon. >> Are you still experiencing such problems? > I have not tried since then, but I'm planning to try again when I > come back home > next week. AFAIK, 'it' has not been fixed. > -- > Ulf Lilleengen > _______________________________________________ Okay, i just did a complete installworld + installkernel after updating my cvs sources today, and the behavior is unchanged. If this is going to stay unfixed for 7.0-release there needs to be a big warning somewhere that the sata300 tx4 card is broken and should not be used. Myself, i'm still saving up for that Areca card... regards, -Sverre From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 16:19:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 684BB16A418; Sun, 16 Sep 2007 16:19:17 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id 46A2513C458; Sun, 16 Sep 2007 16:19:17 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l8GGJ9M6015240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Sep 2007 09:19:09 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l8GGJ8U9009558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Sep 2007 09:19:09 -0700 Message-ID: <46ED577B.4020607@u.washington.edu> Date: Sun, 16 Sep 2007 09:19:07 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Harald Schmalzbauer References: <20070916061932.GA93480@underworld.novel.ru> <20070915234855.G531@10.0.0.1> <200709161359.50560.h.schmalzbauer@omnisec.de> In-Reply-To: <200709161359.50560.h.schmalzbauer@omnisec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.9.16.90227 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='ECARD_WORD 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: Jeff Roberson , freebsd-current@freebsd.org, Roman Bogorodskiy Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 16:19:17 -0000 Harald Schmalzbauer wrote: > Am Sonntag, 16. September 2007 08:49:56 schrieb Jeff Roberson: > >> On Sun, 16 Sep 2007, Roman Bogorodskiy wrote: >> >>> Hello, >>> >>> I'm curious if SCHED_ULE is designed to be used on a desktop system. I'm >>> running -CURRENT at home and tried to use SCHED_ULE for some time. It >>> works alright while the load is not very high. But once I start >>> compiling something (running 'make buildworld' or 'portupgrade -a' for >>> example), the machine comes almost unusable - X11's windows takes a lot >>> of time to redraw, changing virtual desktop in window manager may take >>> a several seconds. And it's nearly impossible to watch some movie with >>> mplayer. >>> >> Roman, >> >> This is contrary to the experiences of many others. Can you send me your >> > > Not in the UP case. > My i386-core2duo with SMP kernel gives _wonderful_ responsiveness, even, with > buildworld -j5, I absolutely don't feel any slowdown! > But when I once accidantially installed a UP kernel,the machine was > very "laggy", I want to say had short "freezes" > > I'm also wondering that inserting a CF card in my card reader stops all io for > a second. HALd is probably the culprit, but why can the system be stopped by > userland? Maybe unrelated to ULE though. > > Thanks 1. Giant lock? 2. Using pthread instead of libthread? -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 17:48:04 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE45916A419; Sun, 16 Sep 2007 17:48:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 573E813C458; Sun, 16 Sep 2007 17:48:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from [192.168.254.15] (ydesk.samsco.home [192.168.254.15]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l8GHm0N0080646; Sun, 16 Sep 2007 11:48:00 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46ED6C50.4040104@samsco.org> Date: Sun, 16 Sep 2007 11:48:00 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Spoerlein References: <46E615C4.1010605@samsco.org> <20070916115427.GA1427@roadrunner.spoerlein.net> In-Reply-To: <20070916115427.GA1427@roadrunner.spoerlein.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [192.168.254.1]); Sun, 16 Sep 2007 11:48:01 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@FreeBSD.ORG, njl@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 17:48:04 -0000 Ulrich Spoerlein wrote: > On Mon, 10.09.2007 at 22:12:52 -0600, Scott Long wrote: > >>All, >> >>The attached patch should make CAM behave properly with regard to >>probing device serial numbers only when the device advertises that >>it supports it. It will hopefully eliminate the need for the >>CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated >>legacy problem that may or may not be possible to fix). This should >>especially benefit USB-UMASS devices, where the console output should >>be less noisy. It might even make more devices work out-of-the-box. > > > While this patch is working fine with my USB/FW HDD enclosure, it breaks > my MP3 USB stick > > kernel: umass0: on uhub5 > kernel: umass0: BBB reset failed, IOERROR > kernel: umass0: BBB bulk-in clear stall failed, IOERROR > kernel: umass0: BBB bulk-out clear stall failed, IOERROR Is this a regression of something that works without the patch, or is it something that has never worked? What happens if you use the NO_INQUIRY_EVPD quirk instead? > > This stick needs the SHUTTLE_INIT | NO_GETMAXLUN quirk. Perhaps there is some > interdependencies? Likely only to the extent that this is a pretty difficult device to deal with. > > The patch also, does not magically allow me to read retail DVDs through my > Plextor drive when attached via cd(4), but that is not the goal of the patch > anyway. Actually, I was hoping that it would =-) > > It's funny, though. If I quirk this Plextor DVD to NO_INQUIRY, it will attach > via da(4) (sic!) and suddenly all kinds of DVD media start working! > > umass0: on uhub5 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: < > Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: 3001MB (1536688 2048 byte sectors: 255H 63S/T 95C) > I'm honestly having a really hard time believing that a device could claim to support "SCSI" but not support a basic INQUIRY command. That's the one command that is absolutely essential to any SCSI device. What if you try the NO_INQUIRY_EVPD or FORCE_SHORT_INQUIRY quirks? Scott From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 19:40:05 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C216616A41B for ; Sun, 16 Sep 2007 19:40:05 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id D2D2013C465 for ; Sun, 16 Sep 2007 19:40:04 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l8GJTPZa013006; Sun, 16 Sep 2007 23:29:25 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1189970965; bh=xuhy8++5NY6qoZt8MIxebItAWrZBnE7mFCv2Rka on1g=; l=10963; h=Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:MIME-Version:Content-Type:Content-Disposition: User-Agent; b=qaNBqyFWQDZ8EJq15uj0yVc1T3hZ3Z4QfqeySKzoJe/TqTeDy6J/ a8tzhTCfrGFiQqSP+fL3E/nYCuA1WJ4Cl8CXYQ3lk3M8FRtVJDLA21coK7m7h7Ervdc CqnOUlJTpt8JtWuXGATshJreMEoa6im//AghpjzW0jJb83ZzCzAs= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l8GJTOF9013005; Sun, 16 Sep 2007 23:29:24 +0400 (MSD) (envelope-from ache) Date: Sun, 16 Sep 2007 23:29:24 +0400 From: Andrey Chernov To: current@freebsd.org, i18n@freebsd.org Message-ID: <20070916192924.GA12678@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org, i18n@freebsd.org, perky@FreeBSD.org, petr.hroudny@gmail.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: perky@freebsd.org, petr.hroudny@gmail.com Subject: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 19:40:05 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The problem is: currently our single byte ctype functions are broken for wide characters locales in the argument range >= 0x80 - they may return false positives. For example, for UTF-8 locale we currently have: iswspace(0xA0)==1 and isspace(0xA0)==1 (because iswspace() and isspace() are the same code) but must have isspace(0xA0)==0 (because there is no such character and all others in the range 0x80..0xff for the wide locales, they keep ASCII only in the single byte range because our internal wchar_t representation is UCS-4). Attached patch address this issue and also fix iswascii() (currently iswascii() is broken for arguments > 0xFF). This patch is 100% binary compatible with old binaries, their (broken) behaviour is not changed. I want to hear some comments. -- http://ache.pp.ru/ --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ctype.patch" --- _ctype.h.old 2007-09-16 21:13:59.000000000 +0400 +++ _ctype.h 2007-09-16 23:00:38.000000000 +0400 @@ -63,6 +63,7 @@ #define _CTYPE_I 0x00080000L /* Ideogram */ #define _CTYPE_T 0x00100000L /* Special */ #define _CTYPE_Q 0x00200000L /* Phonogram */ +#define _CTYPE_WID 0x10000000L /* wide character function */ #define _CTYPE_SW0 0x20000000L /* 0 width character */ #define _CTYPE_SW1 0x40000000L /* 1 width character */ #define _CTYPE_SW2 0x80000000L /* 2 width character */ @@ -87,6 +88,8 @@ #define __inline #endif +extern int __mb_cur_max; + /* * Use inline functions if we are allowed to and the compiler supports them. */ @@ -98,8 +101,11 @@ static __inline int __maskrune(__ct_rune_t _c, unsigned long _f) { - return ((_c < 0 || _c >= _CACHED_RUNES) ? ___runetype(_c) : + return __mb_cur_max > 1 && !(_f & _CTYPE_WID) && (_c >= 0x80) ? 0 : + ((_c < 0 || _c >= _CACHED_RUNES) ? ___runetype(_c) : _CurrentRuneLocale->__runetype[_c]) & _f; + /* We never set _CTYPE_WID in the locale data, */ + /* so can skip ... & (_f & ~_CTYPE_WID). */ } static __inline int @@ -111,8 +117,11 @@ static __inline int __isctype(__ct_rune_t _c, unsigned long _f) { - return (_c < 0 || _c >= _CACHED_RUNES) ? 0 : + return __mb_cur_max > 1 && !(_f & _CTYPE_WID) && (_c >= 0x80) ? 0 : + (_c < 0 || _c >= _CACHED_RUNES) ? 0 : !!(_DefaultRuneLocale.__runetype[_c] & _f); + /* We never set _CTYPE_WID in the locale data, */ + /* so can skip ... & (_f & ~_CTYPE_WID). */ } static __inline __ct_rune_t @@ -129,6 +138,22 @@ _CurrentRuneLocale->__maplower[_c]; } +static __inline __ct_rune_t +__tosupper(__ct_rune_t _c) +{ + return __mb_cur_max > 1 && (_c >= 0x80) ? _c : + (_c < 0 || _c >= _CACHED_RUNES) ? ___toupper(_c) : + _CurrentRuneLocale->__mapupper[_c]; +} + +static __inline __ct_rune_t +__toslower(__ct_rune_t _c) +{ + return __mb_cur_max > 1 && (_c >= 0x80) ? _c : + (_c < 0 || _c >= _CACHED_RUNES) ? ___tolower(_c) : + _CurrentRuneLocale->__maplower[_c]; +} + static __inline int __wcwidth(__ct_rune_t _c) { @@ -150,6 +175,8 @@ int __isctype(__ct_rune_t, unsigned long); __ct_rune_t __toupper(__ct_rune_t); __ct_rune_t __tolower(__ct_rune_t); +__ct_rune_t __tosupper(__ct_rune_t); +__ct_rune_t __toslower(__ct_rune_t); int __wcwidth(__ct_rune_t); __END_DECLS #endif /* using inlines */ --- ctype.h.old 2007-09-16 22:03:55.000000000 +0400 +++ ctype.h 2007-09-16 22:56:10.000000000 +0400 @@ -97,8 +97,8 @@ #define isspace(c) __istype((c), _CTYPE_S) #define isupper(c) __istype((c), _CTYPE_U) #define isxdigit(c) __isctype((c), _CTYPE_X) /* ANSI -- locale independent */ -#define tolower(c) __tolower(c) -#define toupper(c) __toupper(c) +#define tolower(c) __toslower(c) +#define toupper(c) __tosupper(c) #if __XSI_VISIBLE /* @@ -112,8 +112,8 @@ * * XXX isascii() and toascii() should similarly be undocumented. */ -#define _tolower(c) __tolower(c) -#define _toupper(c) __toupper(c) +#define _tolower(c) __toslower(c) +#define _toupper(c) __tosupper(c) #define isascii(c) (((c) & ~0x7F) == 0) #define toascii(c) ((c) & 0x7F) #endif @@ -128,7 +128,7 @@ #define isideogram(c) __istype((c), _CTYPE_I) #define isnumber(c) __istype((c), _CTYPE_D) #define isphonogram(c) __istype((c), _CTYPE_Q) -#define isrune(c) __istype((c), 0xFFFFFF00L) +#define isrune(c) __istype((c), 0xFFFFFF00L & ~_CTYPE_WID) #define isspecial(c) __istype((c), _CTYPE_T) #endif --- wctype.h.old 2007-09-16 21:59:37.000000000 +0400 +++ wctype.h 2007-09-16 22:56:44.000000000 +0400 @@ -89,30 +89,30 @@ #endif __END_DECLS -#define iswalnum(wc) __istype((wc), _CTYPE_A|_CTYPE_D) -#define iswalpha(wc) __istype((wc), _CTYPE_A) -#define iswblank(wc) __istype((wc), _CTYPE_B) -#define iswcntrl(wc) __istype((wc), _CTYPE_C) -#define iswctype(wc, charclass) __istype((wc), (charclass)) -#define iswdigit(wc) __isctype((wc), _CTYPE_D) -#define iswgraph(wc) __istype((wc), _CTYPE_G) -#define iswlower(wc) __istype((wc), _CTYPE_L) -#define iswprint(wc) __istype((wc), _CTYPE_R) -#define iswpunct(wc) __istype((wc), _CTYPE_P) -#define iswspace(wc) __istype((wc), _CTYPE_S) -#define iswupper(wc) __istype((wc), _CTYPE_U) -#define iswxdigit(wc) __isctype((wc), _CTYPE_X) +#define iswalnum(wc) __istype((wc), _CTYPE_A|_CTYPE_D|_CTYPE_WID) +#define iswalpha(wc) __istype((wc), _CTYPE_A|_CTYPE_WID) +#define iswblank(wc) __istype((wc), _CTYPE_B|_CTYPE_WID) +#define iswcntrl(wc) __istype((wc), _CTYPE_C|_CTYPE_WID) +#define iswctype(wc, charclass) __istype((wc), (charclass)|_CTYPE_WID) +#define iswdigit(wc) __isctype((wc), _CTYPE_D|_CTYPE_WID) +#define iswgraph(wc) __istype((wc), _CTYPE_G|_CTYPE_WID) +#define iswlower(wc) __istype((wc), _CTYPE_L|_CTYPE_WID) +#define iswprint(wc) __istype((wc), _CTYPE_R|_CTYPE_WID) +#define iswpunct(wc) __istype((wc), _CTYPE_P|_CTYPE_WID) +#define iswspace(wc) __istype((wc), _CTYPE_S|_CTYPE_WID) +#define iswupper(wc) __istype((wc), _CTYPE_U|_CTYPE_WID) +#define iswxdigit(wc) __isctype((wc), _CTYPE_X|_CTYPE_WID) #define towlower(wc) __tolower(wc) #define towupper(wc) __toupper(wc) #if __BSD_VISIBLE -#define iswascii(wc) (((wc) & ~0x7F) == 0) -#define iswhexnumber(wc) __istype((wc), _CTYPE_X) -#define iswideogram(wc) __istype((wc), _CTYPE_I) -#define iswnumber(wc) __istype((wc), _CTYPE_D) -#define iswphonogram(wc) __istype((wc), _CTYPE_Q) -#define iswrune(wc) __istype((wc), 0xFFFFFF00L) -#define iswspecial(wc) __istype((wc), _CTYPE_T) +#define iswascii(wc) ((wc) < 0x80) +#define iswhexnumber(wc) __istype((wc), _CTYPE_X|_CTYPE_WID) +#define iswideogram(wc) __istype((wc), _CTYPE_I|_CTYPE_WID) +#define iswnumber(wc) __istype((wc), _CTYPE_D|_CTYPE_WID) +#define iswphonogram(wc) __istype((wc), _CTYPE_Q|_CTYPE_WID) +#define iswrune(wc) __istype((wc), 0xFFFFFF00L) /* already have _CTYPE_WID */ +#define iswspecial(wc) __istype((wc), _CTYPE_T|_CTYPE_WID) #endif #endif /* _WCTYPE_H_ */ --- isctype.c.old 2007-09-16 22:31:26.000000000 +0400 +++ isctype.c 2007-09-16 22:37:54.000000000 +0400 @@ -168,7 +168,7 @@ isrune(c) int c; { - return (__istype(c, 0xFFFFFF00L)); + return (__istype(c, 0xFFFFFF00L & ~_CTYPE_WID)); } #undef isspace @@ -216,7 +216,7 @@ tolower(c) int c; { - return (__tolower(c)); + return (__toslower(c)); } #undef toupper @@ -224,6 +224,6 @@ toupper(c) int c; { - return (__toupper(c)); + return (__tosupper(c)); } --- iswctype.c.old 2007-09-16 22:31:30.000000000 +0400 +++ iswctype.c 2007-09-16 22:41:39.000000000 +0400 @@ -45,7 +45,7 @@ iswalnum(wc) wint_t wc; { - return (__istype(wc, _CTYPE_A|_CTYPE_D)); + return (__istype(wc, _CTYPE_A|_CTYPE_D|_CTYPE_WID)); } #undef iswalpha @@ -53,7 +53,7 @@ iswalpha(wc) wint_t wc; { - return (__istype(wc, _CTYPE_A)); + return (__istype(wc, _CTYPE_A|_CTYPE_WID))); } #undef iswascii @@ -61,7 +61,7 @@ iswascii(wc) wint_t wc; { - return ((wc & ~0x7F) == 0); + return (wc < 0x80); } #undef iswblank @@ -69,7 +69,7 @@ iswblank(wc) wint_t wc; { - return (__istype(wc, _CTYPE_B)); + return (__istype(wc, _CTYPE_B|_CTYPE_WID))); } #undef iswcntrl @@ -77,7 +77,7 @@ iswcntrl(wc) wint_t wc; { - return (__istype(wc, _CTYPE_C)); + return (__istype(wc, _CTYPE_C|_CTYPE_WID))); } #undef iswdigit @@ -85,7 +85,7 @@ iswdigit(wc) wint_t wc; { - return (__isctype(wc, _CTYPE_D)); + return (__isctype(wc, _CTYPE_D|_CTYPE_WID))); } #undef iswgraph @@ -93,7 +93,7 @@ iswgraph(wc) wint_t wc; { - return (__istype(wc, _CTYPE_G)); + return (__istype(wc, _CTYPE_G|_CTYPE_WID))); } #undef iswhexnumber @@ -101,7 +101,7 @@ iswhexnumber(wc) wint_t wc; { - return (__istype(wc, _CTYPE_X)); + return (__istype(wc, _CTYPE_X|_CTYPE_WID))); } #undef iswideogram @@ -109,7 +109,7 @@ iswideogram(wc) wint_t wc; { - return (__istype(wc, _CTYPE_I)); + return (__istype(wc, _CTYPE_I|_CTYPE_WID))); } #undef iswlower @@ -117,7 +117,7 @@ iswlower(wc) wint_t wc; { - return (__istype(wc, _CTYPE_L)); + return (__istype(wc, _CTYPE_L|_CTYPE_WID))); } #undef iswnumber @@ -125,7 +125,7 @@ iswnumber(wc) wint_t wc; { - return (__istype(wc, _CTYPE_D)); + return (__istype(wc, _CTYPE_D|_CTYPE_WID))); } #undef iswphonogram @@ -133,7 +133,7 @@ iswphonogram(wc) wint_t wc; { - return (__istype(wc, _CTYPE_Q)); + return (__istype(wc, _CTYPE_Q|_CTYPE_WID))); } #undef iswprint @@ -141,7 +141,7 @@ iswprint(wc) wint_t wc; { - return (__istype(wc, _CTYPE_R)); + return (__istype(wc, _CTYPE_R|_CTYPE_WID))); } #undef iswpunct @@ -149,7 +149,7 @@ iswpunct(wc) wint_t wc; { - return (__istype(wc, _CTYPE_P)); + return (__istype(wc, _CTYPE_P|_CTYPE_WID))); } #undef iswrune @@ -157,7 +157,7 @@ iswrune(wc) wint_t wc; { - return (__istype(wc, 0xFFFFFF00L)); + return (__istype(wc, 0xFFFFFF00L)); /* already have _CTYPE_WID */ } #undef iswspace @@ -165,7 +165,7 @@ iswspace(wc) wint_t wc; { - return (__istype(wc, _CTYPE_S)); + return (__istype(wc, _CTYPE_S|_CTYPE_WID))); } #undef iswspecial @@ -173,7 +173,7 @@ iswspecial(wc) wint_t wc; { - return (__istype(wc, _CTYPE_T)); + return (__istype(wc, _CTYPE_T|_CTYPE_WID))); } #undef iswupper @@ -181,7 +181,7 @@ iswupper(wc) wint_t wc; { - return (__istype(wc, _CTYPE_U)); + return (__istype(wc, _CTYPE_U|_CTYPE_WID))); } #undef iswxdigit @@ -189,7 +189,7 @@ iswxdigit(wc) wint_t wc; { - return (__isctype(wc, _CTYPE_X)); + return (__isctype(wc, _CTYPE_X|_CTYPE_WID))); } #undef towlower --fdj2RfSjLxBAspz7-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 20:12:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F1E716A417 for ; Sun, 16 Sep 2007 20:12:45 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 5373513C46B for ; Sun, 16 Sep 2007 20:12:45 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l8GK24M8047663; Sun, 16 Sep 2007 13:02:05 -0700 (PDT) Date: Sun, 16 Sep 2007 22:01:18 +0200 Message-ID: From: gnn@freebsd.org To: Peter Losher In-Reply-To: <46ECEBF7.8070804@isc.org> References: <46ECEBF7.8070804@isc.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: BIND performance under FreeBSD 7-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 20:12:45 -0000 At Sun, 16 Sep 2007 01:40:23 -0700, Peter Losher wrote: > > [1 ] > As some of you know back at BSDcan 2007, I made it known that we had > seen BIND9 performance suffer under FreeBSD and that under threaded > build on SMP systems, Linux had blown FreeBSD out of the water in terms > of performance. > > As it's now (well was) EuroBSDcon, one of our engineers re-ran the query > test I mentioned back at BSDcan and it looks like the work kris@ has > spearheaded has paid dividends. Re: > > -=- > Last night I built a disk with the August snapshot and re-ran the test. > FreeBSD performance is indeed much improved -- almost as good as Linux. > > fbsd-7-current (200704) 44K queries/sec > fbsd-7-current (200708) 84K queries/sec > > Gentoo Linux (2.6.20.7) 93K queries/sec > Fedora Linux (2.6.20.7) 87K queries/sec > > Disk-to-disk copy speed is 90 MB/s for Linux and 20 MB/s for the > April snapshot of FreeBSD; it is unchanged for the August FreeBSD > snapshot. This is reassuring because the zone files should be > in memory and disk performance shouldn't be an issue. > > In any case, FreeBSD-current has greatly improved between April > and August. > -=- > > (FYI - the disk controller on these boxes are mpt Serial SCSI) > > Not quite there, but a significant improvement nonetheless. If anyone > needs more information about the test, let me know. > Hi Peter, Thanks for running this stuff and reporting the results. Any way we can get you to run these nightly or in a script? :-) Best, George From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 20:19:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BB8616A41B for ; Sun, 16 Sep 2007 20:19:11 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id A396C13C459 for ; Sun, 16 Sep 2007 20:19:09 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP for id l8GKJ8at004529 (8.13.4/1.4); Sun, 16 Sep 2007 22:19:08 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP for id l8GKJ8HK004525 (8.13.4/2.02); Sun, 16 Sep 2007 22:19:08 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Sun, 16 Sep 2007 22:19:08 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: PREEMPTION on UP systems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 20:19:11 -0000 -CURRENT UP systems with options PREEMPTION exhibit some very 'jerky' and annoying behaviour. In particular, if you have, say, a buildkernel running somewhere, interactive behaviour in all alther applications goes down the toilet. You can very easily reproduce this by opening some file and vi and just moving the cursor back and forth (press and hold 'l' and 'h'). You will see the cursors miss beats and genereally just behave very jumpy. It appears to be disk-io related. Sorry I can't be more specific. It's just that someone else also mentioned something about strange perormance issues on UP boxen. So my suggestion would be to take out the PREEMPTION option and see how that goes. (Obviously, you can't have SCHED_ULE then also.) Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 20:31:22 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3C0016A417 for ; Sun, 16 Sep 2007 20:31:22 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from aaron.protected-networks.net (aaron.protected-networks.net [202.12.127.66]) by mx1.freebsd.org (Postfix) with ESMTP id B0C0413C442 for ; Sun, 16 Sep 2007 20:31:22 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from localhost (localhost [127.0.0.1]) by aaron.protected-networks.net (Postfix) with ESMTP id 6218AC66F for ; Sun, 16 Sep 2007 16:31:21 -0400 (EDT) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by aaron.protected-networks.net (Postfix) with ESMTP id 720E7C63E for ; Sun, 16 Sep 2007 16:31:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1189974671; bh=vncyE7V27Vm1Sf CIElpEC11zJWVgMsNU1F5qP4mFOvE=; h=DomainKey-Signature:Message-ID: Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version: OpenPGP:Content-Type:Content-Transfer-Encoding; b=JUKLWoWGCwpAWpsb VS73dhGw3YVbL2mfV7/SY3lVLPCQ6N/ZS9GR2Z8tyoaD2unA4h0jO4n9ucHoQyCX8Tv /Ot2xCwEXWs3ZPCR9jXe81eHL09rYnJh40mQWhJmHq+8i DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=d+VDmxYYxAs5j4tjDNau1EIP1yjYTrMiSImamVRXRx6epp0iXA4Ws8BGwp709MEYs fJF0a52ZtnrV72V597QmzMTaQQBryAmxmv/AftSCPLr8bz49QdqFQhvaP+PsZ7F Message-ID: <46ED928C.8050405@protected-networks.net> Date: Sun, 16 Sep 2007 16:31:08 -0400 From: Michael Butler User-Agent: Thunderbird 2.0.0.6 (X11/20070903) MIME-Version: 1.0 To: current@freebsd.org X-Enigmail-Version: 0.95.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: zone allocation failures? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 20:31:23 -0000 Any thoughts as to what causes this? ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 128, 0, 76, 14, 76, 0 UMA Zones: 480, 0, 76, 4, 76, 0 UMA Slabs: 64, 0, 1250, 48, 9814, 0 UMA RCntSlabs: 104, 0, 246, 13, 246, 0 UMA Hash: 128, 0, 4, 26, 7, 0 16 Bucket: 76, 0, 51, 49, 69, 0 32 Bucket: 140, 0, 62, 22, 82, 0 64 Bucket: 268, 0, 65, 5, 114, 11 <---- 128 Bucket: 524, 0, 85, 6, 810, 69 <---- Michael From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 21:12:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E44F16A41B for ; Sun, 16 Sep 2007 21:12:09 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id 1A40413C46C for ; Sun, 16 Sep 2007 21:12:08 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1720796mue for ; Sun, 16 Sep 2007 14:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=aB/4Fa3E4IC6q0mp+6ihejY/LET9sEL++iQXr/M9oyc=; b=hSb5C23heywC95l+q9+MpQX6rUDutBPQYSHe7frudIe2pp9wBXbmHtr+T4TeGUTpzfGii2cS1JbBLFuXSpB6bJRYhUh4zeTUfjJC46Ts/FPCtchpyWv6d668UtvOvKC78Oz/CNe6tmEp8Y5qFUzhZ1DQuBQmRoroCLZ0fw4WlbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=VmxP81sm+e2xxU/sZD2xZdvpPyt5DsRI3C3NLeG1OlxBc2SA6sWGvngD1gs+EfSoLVr2iS3A6dZPmZSEAR2+0ih//s3z1M2JeR/d6F0RQ/J4iClfN04QQGAn0dV0Dl9DrOBlH+gT/3eKlsliJAfa3vqg/8fZxdlYqfCnpXqYEVY= Received: by 10.86.28.5 with SMTP id b5mr3146485fgb.1189977127489; Sun, 16 Sep 2007 14:12:07 -0700 (PDT) Received: from roadrunner.spoerlein.net ( [85.180.170.233]) by mx.google.com with ESMTPS id e32sm6838078fke.2007.09.16.14.12.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Sep 2007 14:12:06 -0700 (PDT) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id l8GLBrjX002521; Sun, 16 Sep 2007 23:11:53 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id l8GLBmaU002520; Sun, 16 Sep 2007 23:11:48 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Sun, 16 Sep 2007 23:11:48 +0200 From: Ulrich Spoerlein To: Scott Long Message-ID: <20070916211148.GB1574@roadrunner.spoerlein.net> Mail-Followup-To: Scott Long , freebsd-scsi@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, njl@FreeBSD.ORG References: <46E615C4.1010605@samsco.org> <20070916115427.GA1427@roadrunner.spoerlein.net> <46ED6C50.4040104@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46ED6C50.4040104@samsco.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-scsi@FreeBSD.ORG, njl@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 21:12:09 -0000 On Sun, 16.09.2007 at 11:48:00 -0600, Scott Long wrote: > Ulrich Spoerlein wrote: > > While this patch is working fine with my USB/FW HDD enclosure, it breaks > > my MP3 USB stick > > kernel: umass0: on uhub5 > > kernel: umass0: BBB reset failed, IOERROR > > kernel: umass0: BBB bulk-in clear stall failed, IOERROR > > kernel: umass0: BBB bulk-out clear stall failed, IOERROR > > Is this a regression of something that works without the patch, or is > it something that has never worked? What happens if you use the > NO_INQUIRY_EVPD quirk instead? This is a regression, I will test the EVPD quirk tomorrow ... > > It's funny, though. If I quirk this Plextor DVD to NO_INQUIRY, it will > > attach > > via da(4) (sic!) and suddenly all kinds of DVD media start working! > > umass0: on uhub5 > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: < > Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers > > da0: 3001MB (1536688 2048 byte sectors: 255H 63S/T 95C) > > I'm honestly having a really hard time believing that a device could > claim to support "SCSI" but not support a basic INQUIRY command. That's > the one command that is absolutely essential to any SCSI device. What > if you try the NO_INQUIRY_EVPD or FORCE_SHORT_INQUIRY quirks? Sorry for not making myself clear. The device has always attached via cd(4) and worked for CD and self-burned DVD, but not retail DVD. If I quirk it, it will attach via da(4) *instead* of cd(4), and retail DVD magically start working. If I use atausb(4)/acd(4) some of the retail DVDs work and if I extract the drive from the case and attach it via atapi(4)/acd(4) everything is working fine, too. It is only cd(4) that is not grokking retail DVDs, be it via umass(4) or sbp(4). I doubt your patch is intended to change the runtime behaviour of cd(4) with respect to handling inserted media, right? I'll give those quirks you mentioned a try, but that will only fix the umass(4)/cd(4) issue, not the sbp(4)/cd(4) one. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 22:14:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 932CC16A417 for ; Sun, 16 Sep 2007 22:14:12 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: from redundancy.redundancy.org (redundancy.redundancy.org [64.147.160.152]) by mx1.freebsd.org (Postfix) with SMTP id 6F66813C491 for ; Sun, 16 Sep 2007 22:14:12 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: (qmail 18981 invoked by uid 1001); 16 Sep 2007 21:47:54 -0000 Date: Sun, 16 Sep 2007 14:47:54 -0700 From: "David E. Thiel" To: freebsd-current@freebsd.org Message-ID: <20070916214753.GJ1051@redundancy.redundancy.org> Mail-Followup-To: freebsd-current@freebsd.org References: <20070916061932.GA93480@underworld.novel.ru> <200709160058.33475.vehemens@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709160058.33475.vehemens@verizon.net> X-OpenPGP-Key-fingerprint: 482A 8C46 C844 7E7C 8CBC 2313 96EE BEE5 1F4B CA13 X-OpenPGP-Key-available: http://redundancy.redundancy.org/lx.gpg User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 22:14:12 -0000 On Sun, Sep 16, 2007 at 12:58:33AM -0700, vehemens wrote: > On Saturday 15 September 2007 11:19:32 pm Roman Bogorodskiy wrote: > >I'm curious if SCHED_ULE is designed to be used on a desktop system. I'm > >running -CURRENT at home and tried to use SCHED_ULE for some time. It > >works alright while the load is not very high. But once I start > >compiling something (running 'make buildworld' or 'portupgrade -a' for > >example), the machine comes almost unusable - X11's windows takes a lot > >of time to redraw, changing virtual desktop in window manager may take > >a several seconds. And it's nearly impossible to watch some movie with > >mplayer. > > I also see something similar running -CURRENT with SCHED_4BSD, > but it shows up with X/gnome. Remote logins are still responsive > and running X/twm works fine. In my experience, both 4BSD and ULE are unresponsive on the desktop in -CURRENT, with ULE being somewhat worse. Compiling an application causes the mouse to be jerky, windows to draw slowly, audio to start skipping, and occasionally the whole desktop freezes for a minute at a time (with ULE only). This is with INVARIANTS and all the debugging kernel options disabled and malloc debugging turned off. I'll give running without PREEMPTION with 4BSD and the ULE patch a shot, but in its stock form, -CURRENT is definitely worse than -STABLE on the desktop for me in a UP configuration. Up till now, I've been working around it manually by juggling with rtprio. If it's of any use, dmesg is at: http://redundancy.redundancy.org/dmesg.txt From owner-freebsd-current@FreeBSD.ORG Sun Sep 16 22:50:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8941216A41A for ; Sun, 16 Sep 2007 22:50:25 +0000 (UTC) (envelope-from SRS0=163e54530948b97ece1206ed8f937213c7d8e60c=460=es.net=oberman@es.net) Received: from postal1.es.net (postal4.es.net [IPv6:2001:400:6000:1::66]) by mx1.freebsd.org (Postfix) with ESMTP id B20EC13C46B for ; Sun, 16 Sep 2007 22:50:22 +0000 (UTC) (envelope-from SRS0=163e54530948b97ece1206ed8f937213c7d8e60c=460=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id VFO76620; Sun, 16 Sep 2007 15:50:20 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id B921C4500C; Sun, 16 Sep 2007 15:50:19 -0700 (PDT) To: "David E. Thiel" In-Reply-To: Your message of "Sun, 16 Sep 2007 14:47:54 PDT." <20070916214753.GJ1051@redundancy.redundancy.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1189983019_46694P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 16 Sep 2007 15:50:19 -0700 From: "Kevin Oberman" Message-Id: <20070916225019.B921C4500C@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ;; X-Sender: X-To_Name: David E. Thiel X-To_Domain: freebsd.org X-To: "David E. Thiel" X-To_Email: lx@FreeBSD.org X-To_Alias: lx Cc: freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 22:50:25 -0000 --==_Exmh_1189983019_46694P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sun, 16 Sep 2007 14:47:54 -0700 > From: "David E. Thiel" > Sender: owner-freebsd-current@freebsd.org > > On Sun, Sep 16, 2007 at 12:58:33AM -0700, vehemens wrote: > > On Saturday 15 September 2007 11:19:32 pm Roman Bogorodskiy wrote: > > >I'm curious if SCHED_ULE is designed to be used on a desktop system. I'm > > >running -CURRENT at home and tried to use SCHED_ULE for some time. It > > >works alright while the load is not very high. But once I start > > >compiling something (running 'make buildworld' or 'portupgrade -a' for > > >example), the machine comes almost unusable - X11's windows takes a lot > > >of time to redraw, changing virtual desktop in window manager may take > > >a several seconds. And it's nearly impossible to watch some movie with > > >mplayer. > > > > I also see something similar running -CURRENT with SCHED_4BSD, > > but it shows up with X/gnome. Remote logins are still responsive > > and running X/twm works fine. > > In my experience, both 4BSD and ULE are unresponsive on the desktop > in -CURRENT, with ULE being somewhat worse. Compiling an application > causes the mouse to be jerky, windows to draw slowly, audio to start > skipping, and occasionally the whole desktop freezes for a minute at > a time (with ULE only). This is with INVARIANTS and all the debugging > kernel options disabled and malloc debugging turned off. > > I'll give running without PREEMPTION with 4BSD and the ULE patch a shot, > but in its stock form, -CURRENT is definitely worse than -STABLE on the > desktop for me in a UP configuration. Up till now, I've been working > around it manually by juggling with rtprio. > > If it's of any use, dmesg is at: > > http://redundancy.redundancy.org/dmesg.txt I have been seeing this for quite some time and, while the scheduler may make a bit of difference, I suspect pager issues. As long as I have available memory, interactivity is fine. If I run a big build and I see swap file use, things slow to a crawl. I see very slow re-draws of the screen and general lack of responsiveness. I run gkrellm and can tell at a glance when swap usage starts to increase. The linkage is clear and not terribly surprising. It may be that you need to add a bit more RAM. -- 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_1189983019_46694P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG7bMrkn3rs5h7N1ERArsVAJ4xvvIKe6VkFLvKmx8hRGMh848x8wCdEZQH g1gjMSzi6eaU61PFl6/T2oU= =nZiX -----END PGP SIGNATURE----- --==_Exmh_1189983019_46694P-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 00:37:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78B3F16A41A; Mon, 17 Sep 2007 00:37:31 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 365EB13C46C; Mon, 17 Sep 2007 00:37:29 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46EDCC48.2090405@FreeBSD.org> Date: Mon, 17 Sep 2007 02:37:28 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kevin Oberman References: <20070916225019.B921C4500C@ptavv.es.net> In-Reply-To: <20070916225019.B921C4500C@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "David E. Thiel" , freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 00:37:31 -0000 Kevin Oberman wrote: >> Date: Sun, 16 Sep 2007 14:47:54 -0700 >> From: "David E. Thiel" >> Sender: owner-freebsd-current@freebsd.org >> >> On Sun, Sep 16, 2007 at 12:58:33AM -0700, vehemens wrote: >>> On Saturday 15 September 2007 11:19:32 pm Roman Bogorodskiy wrote: >>>> I'm curious if SCHED_ULE is designed to be used on a desktop system. I'm >>>> running -CURRENT at home and tried to use SCHED_ULE for some time. It >>>> works alright while the load is not very high. But once I start >>>> compiling something (running 'make buildworld' or 'portupgrade -a' for >>>> example), the machine comes almost unusable - X11's windows takes a lot >>>> of time to redraw, changing virtual desktop in window manager may take >>>> a several seconds. And it's nearly impossible to watch some movie with >>>> mplayer. >>> I also see something similar running -CURRENT with SCHED_4BSD, >>> but it shows up with X/gnome. Remote logins are still responsive >>> and running X/twm works fine. >> In my experience, both 4BSD and ULE are unresponsive on the desktop >> in -CURRENT, with ULE being somewhat worse. Compiling an application >> causes the mouse to be jerky, windows to draw slowly, audio to start >> skipping, and occasionally the whole desktop freezes for a minute at >> a time (with ULE only). This is with INVARIANTS and all the debugging >> kernel options disabled and malloc debugging turned off. >> >> I'll give running without PREEMPTION with 4BSD and the ULE patch a shot, >> but in its stock form, -CURRENT is definitely worse than -STABLE on the >> desktop for me in a UP configuration. Up till now, I've been working >> around it manually by juggling with rtprio. >> >> If it's of any use, dmesg is at: >> >> http://redundancy.redundancy.org/dmesg.txt > > I have been seeing this for quite some time and, while the scheduler may > make a bit of difference, I suspect pager issues. As long as I have > available memory, interactivity is fine. If I run a big build and I see > swap file use, things slow to a crawl. I see very slow re-draws of the > screen and general lack of responsiveness. > > I run gkrellm and can tell at a glance when swap usage starts to > increase. The linkage is clear and not terribly surprising. It may be > that you need to add a bit more RAM. Yes, not surprising in the least. When your system touches swap, performance will drop to a tiny fraction of its normal performance. Depending on your disk this could be 1% or lower. Anyone who is seeing poor interactive performance needs to rule this out as the cause. Kris From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 00:56:11 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A9A616A41A for ; Mon, 17 Sep 2007 00:56:11 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from aaron.protected-networks.net (aaron.protected-networks.net [202.12.127.66]) by mx1.freebsd.org (Postfix) with ESMTP id CF8C413C442 for ; Mon, 17 Sep 2007 00:56:10 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from localhost (localhost [127.0.0.1]) by aaron.protected-networks.net (Postfix) with ESMTP id 182FDC596; Sun, 16 Sep 2007 20:56:10 -0400 (EDT) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by aaron.protected-networks.net (Postfix) with ESMTP id 84FB9C346; Sun, 16 Sep 2007 20:55:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1189990554; bh=KD5W9z2UNfdltG SDFCT/2bylbKl6eEE+Rc8K9jotso8=; h=DomainKey-Signature:Message-ID: Date:From:User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:OpenPGP:Content-Type: Content-Transfer-Encoding; b=HKzOSNDlLuIabHh3SgwtdZdhnl5U0c6v0jLe9 pDRkbEpW+iMc9B6lhg0MgEKtif0esP6AfsFojETRVE1J2P6bd3uOJJzoNjJiH2/kQs2 KbfqScjDXArC2d+QqCAok1II DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=RC6RVIuJYfBZhaah0JE8RgHcff3UKA6VlwdB9LbUrB2hSh8uP8dp/9k91uWBt1f/P H9BWRF+esk6IY3CtIg+6lN5Z5gXxMD9w8vTRb5hlQFxF3e6Jkz3Py/NU30P6ADI Message-ID: <46EDD099.3070306@protected-networks.net> Date: Sun, 16 Sep 2007 20:55:53 -0400 From: Michael Butler User-Agent: Thunderbird 2.0.0.6 (X11/20070903) MIME-Version: 1.0 To: pluknet References: <46E993C2.7020700@protected-networks.net> In-Reply-To: X-Enigmail-Version: 0.95.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: apache start-up issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 00:56:11 -0000 pluknet wrote: > On 13/09/2007, Michael Butler wrote: >> This is weird .. any ideas? >> >> imb@mail:/home/imb> sudo /usr/local/etc/rc.d/apache.sh restart >> apache not running? (check /var/run/httpd.pid). >> Starting apache. >> Syntax error on line 205 of /usr/local/etc/apache/httpd.conf: >> Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: >> /usr/local/libexec/apache/mod_mmap_static.so: Undefined symbol >> "ap_null_cleanup" >> >> .. yet .. >> >> imb@mail:/home/imb> nm /usr/local/sbin/httpd | grep ap_null_cleanup >> 0804b290 T ap_null_cleanup >> > > Hello. > > An --export-dynamic flag passed to the linker helped me to avoid this issue. The fix is even more simple than this .. create small shell script and place it in /usr/bin/objformat. It should read something like this .. #!/bin/sh echo elf Which tells the src/Configure script to apply the appropriate linker flags ;-) Michael From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 03:24:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A976016A417; Mon, 17 Sep 2007 03:24:16 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0AB13C465; Mon, 17 Sep 2007 03:24:16 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8H3NZbu099904 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 16 Sep 2007 23:23:36 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sun, 16 Sep 2007 20:26:28 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Kris Kennaway In-Reply-To: <46EDCC48.2090405@FreeBSD.org> Message-ID: <20070916202402.X4507@10.0.0.1> References: <20070916225019.B921C4500C@ptavv.es.net> <46EDCC48.2090405@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "David E. Thiel" , freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 03:24:16 -0000 On Mon, 17 Sep 2007, Kris Kennaway wrote: > Kevin Oberman wrote: >>> Date: Sun, 16 Sep 2007 14:47:54 -0700 >>> From: "David E. Thiel" >>> Sender: owner-freebsd-current@freebsd.org >>> >>> On Sun, Sep 16, 2007 at 12:58:33AM -0700, vehemens wrote: >>>> On Saturday 15 September 2007 11:19:32 pm Roman Bogorodskiy wrote: >>>>> I'm curious if SCHED_ULE is designed to be used on a desktop system. I'm >>>>> running -CURRENT at home and tried to use SCHED_ULE for some time. It >>>>> works alright while the load is not very high. But once I start >>>>> compiling something (running 'make buildworld' or 'portupgrade -a' for >>>>> example), the machine comes almost unusable - X11's windows takes a lot >>>>> of time to redraw, changing virtual desktop in window manager may take >>>>> a several seconds. And it's nearly impossible to watch some movie with >>>>> mplayer. >>>> I also see something similar running -CURRENT with SCHED_4BSD, >>>> but it shows up with X/gnome. Remote logins are still responsive >>>> and running X/twm works fine. >>> In my experience, both 4BSD and ULE are unresponsive on the desktop >>> in -CURRENT, with ULE being somewhat worse. Compiling an application >>> causes the mouse to be jerky, windows to draw slowly, audio to start >>> skipping, and occasionally the whole desktop freezes for a minute at >>> a time (with ULE only). This is with INVARIANTS and all the debugging >>> kernel options disabled and malloc debugging turned off. >>> I'll give running without PREEMPTION with 4BSD and the ULE patch a shot, >>> but in its stock form, -CURRENT is definitely worse than -STABLE on the >>> desktop for me in a UP configuration. Up till now, I've been working >>> around it manually by juggling with rtprio. >>> >>> If it's of any use, dmesg is at: >>> >>> http://redundancy.redundancy.org/dmesg.txt >> >> I have been seeing this for quite some time and, while the scheduler may >> make a bit of difference, I suspect pager issues. As long as I have >> available memory, interactivity is fine. If I run a big build and I see >> swap file use, things slow to a crawl. I see very slow re-draws of the >> screen and general lack of responsiveness. >> >> I run gkrellm and can tell at a glance when swap usage starts to >> increase. The linkage is clear and not terribly surprising. It may be >> that you need to add a bit more RAM. > > Yes, not surprising in the least. When your system touches swap, performance > will drop to a tiny fraction of its normal performance. Depending on your > disk this could be 1% or lower. Anyone who is seeing poor interactive > performance needs to rule this out as the cause. Ah, I think I know why people are reporting worse problems with ULE. ULE is not properly accounting swtime so different threads are being chosen for swapout with ULE and 4BSD. My test systems all have more than enough memory to do parallel buildworlds without swapping. This is likely why I haven't run into this. I really need to fix p_swtime with ULE. Could the people reporting bad behavior please verify whether or not you're seeing swapping activity? Even just looking for swap used in top will help me verify that this is the problem. Thanks, Jeff > > Kris > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 03:39:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 680CF16A46B for ; Mon, 17 Sep 2007 03:39:26 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: from redundancy.redundancy.org (redundancy.redundancy.org [64.147.160.152]) by mx1.freebsd.org (Postfix) with SMTP id 39DE113C46E for ; Mon, 17 Sep 2007 03:39:26 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: (qmail 25824 invoked by uid 1001); 17 Sep 2007 03:39:48 -0000 Date: Sun, 16 Sep 2007 20:39:48 -0700 From: "David E. Thiel" To: freebsd-current@freebsd.org Message-ID: <20070917033948.GK1051@redundancy.redundancy.org> Mail-Followup-To: freebsd-current@freebsd.org References: <20070916214753.GJ1051@redundancy.redundancy.org> <20070916225019.B921C4500C@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070916225019.B921C4500C@ptavv.es.net> X-OpenPGP-Key-fingerprint: 482A 8C46 C844 7E7C 8CBC 2313 96EE BEE5 1F4B CA13 X-OpenPGP-Key-available: http://redundancy.redundancy.org/lx.gpg User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 03:39:26 -0000 On Sun, Sep 16, 2007 at 03:50:19PM -0700, Kevin Oberman wrote: > I have been seeing this for quite some time and, while the scheduler may > make a bit of difference, I suspect pager issues. As long as I have > available memory, interactivity is fine. If I run a big build and I see > swap file use, things slow to a crawl. I see very slow re-draws of the > screen and general lack of responsiveness. > > I run gkrellm and can tell at a glance when swap usage starts to > increase. The linkage is clear and not terribly surprising. It may be > that you need to add a bit more RAM. While I wouldn't mind adding more RAM, this happens with about 60% memory utilization, and top verifies no swap is being used. I'll believe that it may not be all the scheduler's fault (since I see it to some degree regardless of scheduler), but in my case, it's not paging. I did actually just switch to 4BSD without PREEMPTION, and the audio skipping and jerkiness that I was getting before is no longer happening. Maybe something in PREEMPTION is causing problems with both schedulers? Thanks, David From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 03:52:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD69B16A41B for ; Mon, 17 Sep 2007 03:52:33 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id ACF4213C461 for ; Mon, 17 Sep 2007 03:52:33 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1873733waf for ; Sun, 16 Sep 2007 20:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=MTquC2dn3aqZ1B6rxBR+u1y9OMvPFQZ7DI2dwark03k=; b=N8VQTIb/Boj08wREHIKFt6KNyimWLx524492RYdp2bF3IVW+aeU5Z50oi1/ixi1JA1fX2nTC3zgvgit4vbcjeoyi0X4w+VGK7Q5fyHP4hXXJ7+3MCv3zxlljsBhOFQ2P7LmUjCce/5aGIVbnWvbhQS/NtF43oyNZqkZLrhS61Vc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oZzidRl8UhXM4nIgi/bUEbBExdoJP9VCfcicsyohk5/BYG4+cyJeNV+Z3RLBC80n+13OGRSweqVI16nQjfCNdKZkxjZhkvtT9/27ZcELAGcCj8LXW72Zj0vqzIRVNxL+YnnJw+nY+LxWeFMOHwAuhxzHhU7kb3qJZn7wDvOeXO8= Received: by 10.114.66.2 with SMTP id o2mr2576387waa.1190001152978; Sun, 16 Sep 2007 20:52:32 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Sun, 16 Sep 2007 20:52:32 -0700 (PDT) Message-ID: Date: Sun, 16 Sep 2007 20:52:32 -0700 From: "Kip Macy" To: freebsd-current@freebsd.org In-Reply-To: <20070917033948.GK1051@redundancy.redundancy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070916214753.GJ1051@redundancy.redundancy.org> <20070916225019.B921C4500C@ptavv.es.net> <20070917033948.GK1051@redundancy.redundancy.org> Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 03:52:33 -0000 On 9/16/07, David E. Thiel wrote: > On Sun, Sep 16, 2007 at 03:50:19PM -0700, Kevin Oberman wrote: > > I have been seeing this for quite some time and, while the scheduler may > > make a bit of difference, I suspect pager issues. As long as I have > > available memory, interactivity is fine. If I run a big build and I see > > swap file use, things slow to a crawl. I see very slow re-draws of the > > screen and general lack of responsiveness. > > > > I run gkrellm and can tell at a glance when swap usage starts to > > increase. The linkage is clear and not terribly surprising. It may be > > that you need to add a bit more RAM. > > While I wouldn't mind adding more RAM, this happens with about 60% > memory utilization, and top verifies no swap is being used. I'll believe > that it may not be all the scheduler's fault (since I see it to some > degree regardless of scheduler), but in my case, it's not paging. > > I did actually just switch to 4BSD without PREEMPTION, and the audio > skipping and jerkiness that I was getting before is no longer happening. > Maybe something in PREEMPTION is causing problems with both schedulers? > Could you try setting kern.hz="100" Thanks. -Kip From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 04:43:15 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C97CB16A417 for ; Mon, 17 Sep 2007 04:43:15 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from mail.renet.ru (mail-local.renet.ru [82.116.32.21]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE0713C469 for ; Mon, 17 Sep 2007 04:43:14 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from localhost (d-ed.dialup.renet.ru [82.116.38.237]) by mail.renet.ru (8.14.0/8.14.0) with ESMTP id l8H4hO9m088856; Mon, 17 Sep 2007 08:43:26 +0400 (MSD) (envelope-from novel@FreeBSD.org) Date: Mon, 17 Sep 2007 08:43:51 +0400 From: Roman Bogorodskiy To: Jeff Roberson Message-ID: <20070917044351.GA17565@underworld.novel.ru> References: <20070916061932.GA93480@underworld.novel.ru> <20070915234855.G531@10.0.0.1> <20070916071421.GA1320@underworld.novel.ru> <20070916003323.U4507@10.0.0.1> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <20070916003323.U4507@10.0.0.1> X-PGP: http://people.freebsd.org/~novel/novel.key.asc Cc: freebsd-current@FreeBSD.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 04:43:15 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jeff Roberson wrote: > On Sun, 16 Sep 2007, Roman Bogorodskiy wrote: >=20 >> Jeff Roberson wrote: >>=20 >>> This is contrary to the experiences of many others. Can you send me yo= ur >>> dmesg? There may be something about your particular hardware that is >>> triggering a bug. ULE is definitely designed to be responsive on the >>> desktop. >>=20 >> Thanks for the quick answer! >>=20 >> Here's my dmesg: http://people.freebsd.org/~novel/misc/dmesg.txt >=20 > Roman, >=20 > The enclosed patch helps things on my system, however, there are still so= me=20 > delays due to IO issues. Let me know if this helps. This patch seems to make my system react faster. However I need some time to test it more carefully. > Thanks, > Jeff >=20 >>=20 >> Roman Bogorodskiy >>=20 Roman Bogorodskiy --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iQCVAwUBRu4GB4B0WzgdqspGAQKpEQQAlVF8KzVzGsjfBqcS8eHmGVIJ4vxpZwhR rvWSCi6NsjH7MuCKYxXBMeZ2sAt3QSQ8qXNKn+v/BXChSGe3/ZVtWxnZ4Qy1Uu4D ywRVPlE9N+qNmmIZtr/bpljgctBKH/rqx45aGvOqzqXTIDZCZyo4FVqyT0OYtLlk IxpLr5x9fdA= =QXsN -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 06:59:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0E2316A474 for ; Mon, 17 Sep 2007 06:59:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 8A59013C4D5 for ; Mon, 17 Sep 2007 06:59:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l8H6x0FY084852; Mon, 17 Sep 2007 00:59:01 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46EE25B4.8050306@samsco.org> Date: Mon, 17 Sep 2007 00:59:00 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Peter Losher References: <46ECEBF7.8070804@isc.org> In-Reply-To: <46ECEBF7.8070804@isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Mon, 17 Sep 2007 00:59:01 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: BIND performance under FreeBSD 7-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 06:59:05 -0000 Peter Losher wrote: > As some of you know back at BSDcan 2007, I made it known that we had > seen BIND9 performance suffer under FreeBSD and that under threaded > build on SMP systems, Linux had blown FreeBSD out of the water in terms > of performance. > > As it's now (well was) EuroBSDcon, one of our engineers re-ran the query > test I mentioned back at BSDcan and it looks like the work kris@ has > spearheaded has paid dividends. Re: > > -=- > Last night I built a disk with the August snapshot and re-ran the test. > FreeBSD performance is indeed much improved -- almost as good as Linux. > > fbsd-7-current (200704) 44K queries/sec > fbsd-7-current (200708) 84K queries/sec > > Gentoo Linux (2.6.20.7) 93K queries/sec > Fedora Linux (2.6.20.7) 87K queries/sec > > Disk-to-disk copy speed is 90 MB/s for Linux and 20 MB/s for the > April snapshot of FreeBSD; it is unchanged for the August FreeBSD > snapshot. This is reassuring because the zone files should be > in memory and disk performance shouldn't be an issue. > > In any case, FreeBSD-current has greatly improved between April > and August. > -=- > > (FYI - the disk controller on these boxes are mpt Serial SCSI) > > Not quite there, but a significant improvement nonetheless. If anyone > needs more information about the test, let me know. > > Best Wishes - Peter Please send me a test case for your disk-to-disk issue. Scott From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 07:19:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E57DA16A41A for ; Mon, 17 Sep 2007 07:19:12 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5805713C428 for ; Mon, 17 Sep 2007 07:19:12 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from tek.flintsbach.schmalzbauer.de (tek.flintsbach.schmalzbauer.de [172.21.2.3]) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l8H7J6Za047251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Sep 2007 09:19:11 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [IPv6:fec0::1:0:0:1:1]) by tek.flintsbach.schmalzbauer.de (8.13.8/8.13.8) with ESMTP id l8H7J6lG058043 for ; Mon, 17 Sep 2007 09:19:06 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) Received: from localhost (localhost [[UNIX: localhost]]) by titan.flintsbach.schmalzbauer.de (8.14.1/8.14.1/Submit) id l8H7KMGd007927 for freebsd-current@freebsd.org; Mon, 17 Sep 2007 09:20:22 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: titan.flintsbach.schmalzbauer.de: harry set sender to h.schmalzbauer@omnisec.de using -f From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Mon, 17 Sep 2007 09:20:22 +0200 User-Agent: KMail/1.9.7 References: <20070916225019.B921C4500C@ptavv.es.net> <46EDCC48.2090405@FreeBSD.org> <20070916202402.X4507@10.0.0.1> In-Reply-To: <20070916202402.X4507@10.0.0.1> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1548833.otytbA23j6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709170920.22477.h.schmalzbauer@omnisec.de> Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 07:19:13 -0000 --nextPart1548833.otytbA23j6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag, 17. September 2007 05:26:28 schrieb Jeff Roberson: [snip] > >> I run gkrellm and can tell at a glance when swap usage starts to > >> increase. The linkage is clear and not terribly surprising. It may be > >> that you need to add a bit more RAM. > > > > Yes, not surprising in the least. When your system touches swap, > > performance will drop to a tiny fraction of its normal performance. > > Depending on your disk this could be 1% or lower. Anyone who is seeing > > poor interactive performance needs to rule this out as the cause. > > Ah, I think I know why people are reporting worse problems with ULE. ULE > is not properly accounting swtime so different threads are being chosen > for swapout with ULE and 4BSD. My test systems all have more than enough > memory to do parallel buildworlds without swapping. This is likely why I > haven't run into this. > > I really need to fix p_swtime with ULE. Could the people reporting bad > behavior please verify whether or not you're seeing swapping activity? > Even just looking for swap used in top will help me verify that this is > the problem. In my case swap wasn't used. Of course do I have to expect overall performance loss if I don't have enou= gh=20 RAM, but even a heavily swapping machine shouldn't stop the mouse. I can remember old FreeBSD 3.1 times when it was very common for all of my= =20 machines to use at least the size of RAM additionally for SWAP (about 16MB)= =20 and the machine was feeling smooth nevertheless. I haven't tested if PREEMPTION makes any difference yet. I just remember I = was=20 really suprised that the difference between UP and SMP kernels on that=20 machine is so extremely big. Thanks for all your work! =2DHarry --nextPart1548833.otytbA23j6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG7iq2LDqVQ9VXb8gRAvjqAJ9wU2iroEZ/iKAVa51WfVdvdZpXIwCdG6tW 9T1T2j6LxFYun8sYVChtqnI= =HDMI -----END PGP SIGNATURE----- --nextPart1548833.otytbA23j6-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 07:27:35 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ACBD16A418 for ; Mon, 17 Sep 2007 07:27:35 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id A0CA513C442 for ; Mon, 17 Sep 2007 07:27:34 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from doc.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IXB13-000CRg-4R for freebsd-current@FreeBSD.org; Mon, 17 Sep 2007 11:27:33 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IXB2Q-000ACx-7r for freebsd-current@FreeBSD.org; Mon, 17 Sep 2007 11:28:58 +0400 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Mon, 17 Sep 2007 11:28:58 +0400 Message-ID: <96972293@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: twa + dump = sbwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 07:27:35 -0000 Hi! I can't use dump at -CURRENT with twa. The process goes to sbwait state forever. Here are the details. $ uname -a FreeBSD test.ipt.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Sep 15 19:37:17 MSD 2007 bsam@test.ipt.ru:/usr/obj/usr/src/sys/TEST amd64 The controller: twa0: <3ware 9000 series Storage Controller> port 0x3000-0x30ff mem 0xd8000000-0xd9ffffff,0xda300000-0xda300fff irq 16 at device 0.0 on pci8 twa0: [GIANT-LOCKED] twa0: [ITHREAD] twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 ports, Firmware FE9X 3.06.00.005, BIOS BE9X 3.06.00.002 Two disks at stripe: da1 at twa0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 100.000MB/s transfers da1: 476816MB (976519168 512 byte sectors: 255H 63S/T 60785C) Mounted as: /dev/da1 /s ufs rw 2 2 The command: $ dump -0Luan -f s.dump /s DUMP: Date of this level 0 dump: Mon Sep 17 10:26:21 2007 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/da1 (/s) to s.dump DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 432054 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] [wait here forever] The relevant part of iostat -w 10 and top: ----- tty da0 da1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 231 16.00 0 0.01 16.00 152 2.37 0 0 1 0 99 0 257 16.00 1 0.02 16.00 147 2.29 0 0 1 0 99 0 310 16.00 1 0.01 16.00 146 2.28 0 0 1 0 99 0 265 16.00 0 0.01 16.00 152 2.38 0 0 1 0 99 0 442 16.00 0 0.00 15.98 299 4.66 0 0 1 0 99 0 620 15.54 3 0.04 3.46 1999 6.76 0 0 2 1 96 0 363 16.00 0 0.01 2.77 5141 13.90 0 0 5 2 93 0 309 0.00 0 0.00 3.22 114 0.36 0 0 0 0 100 0 260 16.00 1 0.01 0.00 0 0.00 0 0 0 0 100 0 263 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 last pid: 74610; load averages: 0.01, 0.06, 0.01 up 1+09:53:34 10:32:34 98 processes: 98 sleeping CPU states: 0.0% user, 0.0% nice, 0.3% system, 0.0% interrupt, 99.6% idle Mem: 113M Active, 2374M Inact, 337M Wired, 480K Cache, 214M Buf, 4935M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 74595 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump 74596 duser 1 20 0 28248K 26000K pause 2 0:01 0.00% dump 74594 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump 74593 duser 1 4 0 28248K 26020K sbwait 7 0:01 0.00% dump 74530 duser 1 8 0 28248K 26000K wait 6 0:01 0.00% dump 74443 duser 1 8 0 6216K 1904K wait 5 0:00 0.00% sh ----- Gdb shows nothing interesting: # gdb dump 74593 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 "amd64-marcel-freebsd"...(no debugging symbols found)... Attaching to program: /sbin/dump, process 74593 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 0x000000080071b34a in read () from /lib/libc.so.7 Shall I do some more debugging? Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 07:29:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB25016A41B for ; Mon, 17 Sep 2007 07:29:58 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id A83D213C457 for ; Mon, 17 Sep 2007 07:29:56 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.21.141] (helo=devil.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IXB34-0000xx-H1; Mon, 17 Sep 2007 16:29:38 +0900 Message-ID: <46EE2C98.90802@micom.mng.net> Date: Mon, 17 Sep 2007 15:28:24 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.4 (X11/20070705) MIME-Version: 1.0 To: Jeff Roberson References: <20070916225019.B921C4500C@ptavv.es.net> <46EDCC48.2090405@FreeBSD.org> <20070916202402.X4507@10.0.0.1> In-Reply-To: <20070916202402.X4507@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "David E. Thiel" , freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 07:29:58 -0000 Jeff Roberson wrote: > On Mon, 17 Sep 2007, Kris Kennaway wrote: > >> Kevin Oberman wrote: >>>> Date: Sun, 16 Sep 2007 14:47:54 -0700 >>>> From: "David E. Thiel" >>>> Sender: owner-freebsd-current@freebsd.org >>>> >>>> On Sun, Sep 16, 2007 at 12:58:33AM -0700, vehemens wrote: >>>>> On Saturday 15 September 2007 11:19:32 pm Roman Bogorodskiy wrote: >>>>>> I'm curious if SCHED_ULE is designed to be used on a desktop >>>>>> system. I'm >>>>>> running -CURRENT at home and tried to use SCHED_ULE for some >>>>>> time. It >>>>>> works alright while the load is not very high. But once I start >>>>>> compiling something (running 'make buildworld' or 'portupgrade >>>>>> -a' for >>>>>> example), the machine comes almost unusable - X11's windows takes >>>>>> a lot >>>>>> of time to redraw, changing virtual desktop in window manager may >>>>>> take >>>>>> a several seconds. And it's nearly impossible to watch some movie >>>>>> with >>>>>> mplayer. >>>>> I also see something similar running -CURRENT with SCHED_4BSD, >>>>> but it shows up with X/gnome. Remote logins are still responsive >>>>> and running X/twm works fine. >>>> In my experience, both 4BSD and ULE are unresponsive on the desktop >>>> in -CURRENT, with ULE being somewhat worse. Compiling an application >>>> causes the mouse to be jerky, windows to draw slowly, audio to start >>>> skipping, and occasionally the whole desktop freezes for a minute at >>>> a time (with ULE only). This is with INVARIANTS and all the debugging >>>> kernel options disabled and malloc debugging turned off. I'll give >>>> running without PREEMPTION with 4BSD and the ULE patch a shot, >>>> but in its stock form, -CURRENT is definitely worse than -STABLE on >>>> the >>>> desktop for me in a UP configuration. Up till now, I've been working >>>> around it manually by juggling with rtprio. >>>> >>>> If it's of any use, dmesg is at: >>>> >>>> http://redundancy.redundancy.org/dmesg.txt >>> >>> I have been seeing this for quite some time and, while the scheduler >>> may >>> make a bit of difference, I suspect pager issues. As long as I have >>> available memory, interactivity is fine. If I run a big build and I see >>> swap file use, things slow to a crawl. I see very slow re-draws of the >>> screen and general lack of responsiveness. >>> >>> I run gkrellm and can tell at a glance when swap usage starts to >>> increase. The linkage is clear and not terribly surprising. It may be >>> that you need to add a bit more RAM. >> >> Yes, not surprising in the least. When your system touches swap, >> performance will drop to a tiny fraction of its normal performance. >> Depending on your disk this could be 1% or lower. Anyone who is >> seeing poor interactive performance needs to rule this out as the cause. > > Ah, I think I know why people are reporting worse problems with ULE. > ULE is not properly accounting swtime so different threads are being > chosen for swapout with ULE and 4BSD. My test systems all have more > than enough memory to do parallel buildworlds without swapping. This > is likely why I haven't run into this. > > I really need to fix p_swtime with ULE. Could the people reporting > bad behavior please verify whether or not you're seeing swapping > activity? Even just looking for swap used in top will help me verify > that this is the problem. I explained my problem in http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076450.html. This is a UP system and I have 1GB RAM and top results are shown there. Ganbold > > Thanks, > Jeff > > >> >> Kris >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > > From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 08:04:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D724816A421 for ; Mon, 17 Sep 2007 08:04:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 65ED713C45D for ; Mon, 17 Sep 2007 08:04:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IXBad-0005Xs-0g for freebsd-current@freebsd.org; Mon, 17 Sep 2007 11:04:27 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l8H84FwO041495; Mon, 17 Sep 2007 11:04:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l8H84Fll041494; Mon, 17 Sep 2007 11:04:15 +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: Mon, 17 Sep 2007 11:04:15 +0300 From: Kostik Belousov To: Boris Samorodov Message-ID: <20070917080415.GL79542@deviant.kiev.zoral.com.ua> References: <96972293@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dfmC41YZQlborXoK" Content-Disposition: inline In-Reply-To: <96972293@srv.sem.ipt.ru> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: e96c530ffe2851dcaf18cfd7e0b7e933 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1482 [September 17 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-current@freebsd.org Subject: Re: twa + dump = sbwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 08:04:29 -0000 --dfmC41YZQlborXoK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 17, 2007 at 11:28:58AM +0400, Boris Samorodov wrote: > Hi! >=20 >=20 > I can't use dump at -CURRENT with twa. The process goes to sbwait > state forever. Here are the details. >=20 > $ uname -a > FreeBSD test.ipt.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Sep 15 19:37:= 17 MSD 2007 bsam@test.ipt.ru:/usr/obj/usr/src/sys/TEST amd64 >=20 > The controller: > twa0: <3ware 9000 series Storage Controller> port 0x3000-0x30ff mem 0xd80= 00000-0xd9ffffff,0xda300000-0xda300fff irq 16 at device 0.0 on pci8 > twa0: [GIANT-LOCKED] > twa0: [ITHREAD] > twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue:=20 > twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 po= rts, Firmware FE9X 3.06.00.005, BIOS BE9X 3.06.00.002 >=20 > Two disks at stripe: > da1 at twa0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-5 device=20 > da1: 100.000MB/s transfers > da1: 476816MB (976519168 512 byte sectors: 255H 63S/T 60785C) >=20 > Mounted as: > /dev/da1 /s ufs rw 2 2 >=20 > The command: > $ dump -0Luan -f s.dump /s > DUMP: Date of this level 0 dump: Mon Sep 17 10:26:21 2007 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping snapshot of /dev/da1 (/s) to s.dump > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 432054 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > [wait here forever] >=20 > The relevant part of iostat -w 10 and top: > ----- > tty da0 da1 cpu > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > 0 231 16.00 0 0.01 16.00 152 2.37 0 0 1 0 99 > 0 257 16.00 1 0.02 16.00 147 2.29 0 0 1 0 99 > 0 310 16.00 1 0.01 16.00 146 2.28 0 0 1 0 99 > 0 265 16.00 0 0.01 16.00 152 2.38 0 0 1 0 99 > 0 442 16.00 0 0.00 15.98 299 4.66 0 0 1 0 99 > 0 620 15.54 3 0.04 3.46 1999 6.76 0 0 2 1 96 > 0 363 16.00 0 0.01 2.77 5141 13.90 0 0 5 2 93 > 0 309 0.00 0 0.00 3.22 114 0.36 0 0 0 0 100 > 0 260 16.00 1 0.01 0.00 0 0.00 0 0 0 0 100 > 0 263 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 >=20 > last pid: 74610; load averages: 0.01, 0.06, 0.01 up 1+09:53:34 10= :32:34 > 98 processes: 98 sleeping > CPU states: 0.0% user, 0.0% nice, 0.3% system, 0.0% interrupt, 99.6% = idle > Mem: 113M Active, 2374M Inact, 337M Wired, 480K Cache, 214M Buf, 4935M Fr= ee > Swap: 4096M Total, 4096M Free >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 74595 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump > 74596 duser 1 20 0 28248K 26000K pause 2 0:01 0.00% dump > 74594 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump > 74593 duser 1 4 0 28248K 26020K sbwait 7 0:01 0.00% dump > 74530 duser 1 8 0 28248K 26000K wait 6 0:01 0.00% dump > 74443 duser 1 8 0 6216K 1904K wait 5 0:00 0.00% sh > ----- >=20 > Gdb shows nothing interesting: > # gdb dump 74593 > 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 conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols= found)... > Attaching to program: /sbin/dump, process 74593 > Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found).= ..done. > Loaded symbols for /libexec/ld-elf.so.1 > 0x000000080071b34a in read () from /lib/libc.so.7 >=20 > Shall I do some more debugging? Thanks! Please, verify that you have rev. 1.39 of sys/kern/subr_sleepqueue.c. --dfmC41YZQlborXoK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG7jT+C3+MBN1Mb4gRAvtuAKDDocoWrpFel6rNwQLwYOHhO+QzegCbBC+B OmMOX4VYDvdOwDq2G/HEK7g= =n2dX -----END PGP SIGNATURE----- --dfmC41YZQlborXoK-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 08:08:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D66516A417 for ; Mon, 17 Sep 2007 08:08:06 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id F376413C442 for ; Mon, 17 Sep 2007 08:08:05 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from admin.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IXBeG-000Cdl-JX; Mon, 17 Sep 2007 12:08:04 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IXBfd-000AEj-Q1; Mon, 17 Sep 2007 12:09:29 +0400 To: Kostik Belousov References: <96972293@srv.sem.ipt.ru> <20070917080415.GL79542@deviant.kiev.zoral.com.ua> From: Boris Samorodov Date: Mon, 17 Sep 2007 12:09:29 +0400 In-Reply-To: <20070917080415.GL79542@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Mon\, 17 Sep 2007 11\:04\:15 +0300") Message-ID: <30899862@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: twa + dump = sbwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 08:08:06 -0000 On Mon, 17 Sep 2007 11:04:15 +0300 Kostik Belousov wrote: > On Mon, Sep 17, 2007 at 11:28:58AM +0400, Boris Samorodov wrote: > > Hi! > > > > > > I can't use dump at -CURRENT with twa. The process goes to sbwait > > state forever. Here are the details. > > > > $ uname -a > > FreeBSD test.ipt.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Sep 15 19:37:17 MSD 2007 bsam@test.ipt.ru:/usr/obj/usr/src/sys/TEST amd64 > > > > The controller: > > twa0: <3ware 9000 series Storage Controller> port 0x3000-0x30ff mem 0xd8000000-0xd9ffffff,0xda300000-0xda300fff irq 16 at device 0.0 on pci8 > > twa0: [GIANT-LOCKED] > > twa0: [ITHREAD] > > twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: > > twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 ports, Firmware FE9X 3.06.00.005, BIOS BE9X 3.06.00.002 > > > > Two disks at stripe: > > da1 at twa0 bus 0 target 1 lun 0 > > da1: Fixed Direct Access SCSI-5 device > > da1: 100.000MB/s transfers > > da1: 476816MB (976519168 512 byte sectors: 255H 63S/T 60785C) > > > > Mounted as: > > /dev/da1 /s ufs rw 2 2 > > > > The command: > > $ dump -0Luan -f s.dump /s > > DUMP: Date of this level 0 dump: Mon Sep 17 10:26:21 2007 > > DUMP: Date of last level 0 dump: the epoch > > DUMP: Dumping snapshot of /dev/da1 (/s) to s.dump > > DUMP: mapping (Pass I) [regular files] > > DUMP: mapping (Pass II) [directories] > > DUMP: estimated 432054 tape blocks. > > DUMP: dumping (Pass III) [directories] > > DUMP: dumping (Pass IV) [regular files] > > [wait here forever] > > > > The relevant part of iostat -w 10 and top: > > ----- > > tty da0 da1 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 0 231 16.00 0 0.01 16.00 152 2.37 0 0 1 0 99 > > 0 257 16.00 1 0.02 16.00 147 2.29 0 0 1 0 99 > > 0 310 16.00 1 0.01 16.00 146 2.28 0 0 1 0 99 > > 0 265 16.00 0 0.01 16.00 152 2.38 0 0 1 0 99 > > 0 442 16.00 0 0.00 15.98 299 4.66 0 0 1 0 99 > > 0 620 15.54 3 0.04 3.46 1999 6.76 0 0 2 1 96 > > 0 363 16.00 0 0.01 2.77 5141 13.90 0 0 5 2 93 > > 0 309 0.00 0 0.00 3.22 114 0.36 0 0 0 0 100 > > 0 260 16.00 1 0.01 0.00 0 0.00 0 0 0 0 100 > > 0 263 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 > > > > last pid: 74610; load averages: 0.01, 0.06, 0.01 up 1+09:53:34 10:32:34 > > 98 processes: 98 sleeping > > CPU states: 0.0% user, 0.0% nice, 0.3% system, 0.0% interrupt, 99.6% idle > > Mem: 113M Active, 2374M Inact, 337M Wired, 480K Cache, 214M Buf, 4935M Free > > Swap: 4096M Total, 4096M Free > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 74595 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump > > 74596 duser 1 20 0 28248K 26000K pause 2 0:01 0.00% dump > > 74594 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump > > 74593 duser 1 4 0 28248K 26020K sbwait 7 0:01 0.00% dump > > 74530 duser 1 8 0 28248K 26000K wait 6 0:01 0.00% dump > > 74443 duser 1 8 0 6216K 1904K wait 5 0:00 0.00% sh > > ----- > > > > Gdb shows nothing interesting: > > # gdb dump 74593 > > 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 "amd64-marcel-freebsd"...(no debugging symbols found)... > > Attaching to program: /sbin/dump, process 74593 > > Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. > > Loaded symbols for /lib/libc.so.7 > > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. > > Loaded symbols for /libexec/ld-elf.so.1 > > 0x000000080071b34a in read () from /lib/libc.so.7 > > > > Shall I do some more debugging? Thanks! > Please, verify that you have rev. 1.39 of sys/kern/subr_sleepqueue.c. % grep FBSDID /sys/kern/subr_sleepqueue.c __FBSDID("$FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39 2007/09/13 09:12:36 attilio Exp $"); WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 08:32:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF2AA16A420 for ; Mon, 17 Sep 2007 08:32:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 41ABD13C469 for ; Mon, 17 Sep 2007 08:32:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IXC1p-00005d-Jc for freebsd-current@freebsd.org; Mon, 17 Sep 2007 11:32:34 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l8H8WEpc042785; Mon, 17 Sep 2007 11:32:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l8H8WD7k042784; Mon, 17 Sep 2007 11:32:13 +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: Mon, 17 Sep 2007 11:32:13 +0300 From: Kostik Belousov To: Boris Samorodov Message-ID: <20070917083213.GM79542@deviant.kiev.zoral.com.ua> References: <96972293@srv.sem.ipt.ru> <20070917080415.GL79542@deviant.kiev.zoral.com.ua> <30899862@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sMkrXc3gAYLRVOjR" Content-Disposition: inline In-Reply-To: <30899862@srv.sem.ipt.ru> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: cd91eefa7e6da97c48661c56a607d3ec X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1482 [September 17 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-current@freebsd.org Subject: Re: twa + dump = sbwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 08:32:35 -0000 --sMkrXc3gAYLRVOjR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 17, 2007 at 12:09:29PM +0400, Boris Samorodov wrote: > On Mon, 17 Sep 2007 11:04:15 +0300 Kostik Belousov wrote: > > On Mon, Sep 17, 2007 at 11:28:58AM +0400, Boris Samorodov wrote: > > > Hi! > > >=20 > > >=20 > > > I can't use dump at -CURRENT with twa. The process goes to sbwait > > > state forever. Here are the details. > > >=20 > > > $ uname -a > > > FreeBSD test.ipt.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Sep 15 19= :37:17 MSD 2007 bsam@test.ipt.ru:/usr/obj/usr/src/sys/TEST amd64 > > >=20 > > > The controller: > > > twa0: <3ware 9000 series Storage Controller> port 0x3000-0x30ff mem 0= xd8000000-0xd9ffffff,0xda300000-0xda300fff irq 16 at device 0.0 on pci8 > > > twa0: [GIANT-LOCKED] > > > twa0: [ITHREAD] > > > twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue:=20 > > > twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, = 8 ports, Firmware FE9X 3.06.00.005, BIOS BE9X 3.06.00.002 > > >=20 > > > Two disks at stripe: > > > da1 at twa0 bus 0 target 1 lun 0 > > > da1: Fixed Direct Access SCSI-5 device=20 > > > da1: 100.000MB/s transfers > > > da1: 476816MB (976519168 512 byte sectors: 255H 63S/T 60785C) > > >=20 > > > Mounted as: > > > /dev/da1 /s ufs rw 2 2 > > >=20 > > > The command: > > > $ dump -0Luan -f s.dump /s > > > DUMP: Date of this level 0 dump: Mon Sep 17 10:26:21 2007 > > > DUMP: Date of last level 0 dump: the epoch > > > DUMP: Dumping snapshot of /dev/da1 (/s) to s.dump > > > DUMP: mapping (Pass I) [regular files] > > > DUMP: mapping (Pass II) [directories] > > > DUMP: estimated 432054 tape blocks. > > > DUMP: dumping (Pass III) [directories] > > > DUMP: dumping (Pass IV) [regular files] > > > [wait here forever] > > >=20 > > > The relevant part of iostat -w 10 and top: > > > ----- > > > tty da0 da1 cpu > > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > > 0 231 16.00 0 0.01 16.00 152 2.37 0 0 1 0 99 > > > 0 257 16.00 1 0.02 16.00 147 2.29 0 0 1 0 99 > > > 0 310 16.00 1 0.01 16.00 146 2.28 0 0 1 0 99 > > > 0 265 16.00 0 0.01 16.00 152 2.38 0 0 1 0 99 > > > 0 442 16.00 0 0.00 15.98 299 4.66 0 0 1 0 99 > > > 0 620 15.54 3 0.04 3.46 1999 6.76 0 0 2 1 96 > > > 0 363 16.00 0 0.01 2.77 5141 13.90 0 0 5 2 93 > > > 0 309 0.00 0 0.00 3.22 114 0.36 0 0 0 0 100 > > > 0 260 16.00 1 0.01 0.00 0 0.00 0 0 0 0 100 > > > 0 263 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 > > >=20 > > > last pid: 74610; load averages: 0.01, 0.06, 0.01 up 1+09:53:34= 10:32:34 > > > 98 processes: 98 sleeping > > > CPU states: 0.0% user, 0.0% nice, 0.3% system, 0.0% interrupt, 99= .6% idle > > > Mem: 113M Active, 2374M Inact, 337M Wired, 480K Cache, 214M Buf, 4935= M Free > > > Swap: 4096M Total, 4096M Free > > >=20 > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COM= MAND > > > 74595 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump > > > 74596 duser 1 20 0 28248K 26000K pause 2 0:01 0.00% dump > > > 74594 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump > > > 74593 duser 1 4 0 28248K 26020K sbwait 7 0:01 0.00% dump > > > 74530 duser 1 8 0 28248K 26000K wait 6 0:01 0.00% dump > > > 74443 duser 1 8 0 6216K 1904K wait 5 0:00 0.00% sh > > > ----- > > >=20 > > > Gdb shows nothing interesting: > > > # gdb dump 74593 > > > 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 con= ditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for de= tails. > > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging sym= bols found)... > > > Attaching to program: /sbin/dump, process 74593 > > > Reading symbols from /lib/libc.so.7...(no debugging symbols found)...= done. > > > Loaded symbols for /lib/libc.so.7 > > > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols fou= nd)...done. > > > Loaded symbols for /libexec/ld-elf.so.1 > > > 0x000000080071b34a in read () from /lib/libc.so.7 > > >=20 > > > Shall I do some more debugging? Thanks! >=20 > > Please, verify that you have rev. 1.39 of sys/kern/subr_sleepqueue.c. >=20 > % grep FBSDID /sys/kern/subr_sleepqueue.c > __FBSDID("$FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39 2007/09/13 09:1= 2:36 attilio Exp $"); Most likely, this is a different bug then. Just to make sure, please, show the output of ps axl | grep dump. The dump processes shall sleep, and be killable (check that, please). --sMkrXc3gAYLRVOjR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG7juMC3+MBN1Mb4gRAtHAAJ9DvOLr7zYejpv7UOVdtYm554bzZQCbBP5C xWCVRQlR8S1SitRYJYxNaaQ= =daOl -----END PGP SIGNATURE----- --sMkrXc3gAYLRVOjR-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 08:40:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCCFE16A417 for ; Mon, 17 Sep 2007 08:40:46 +0000 (UTC) (envelope-from dengxf@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 865F413C458 for ; Mon, 17 Sep 2007 08:40:46 +0000 (UTC) (envelope-from dengxf@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1942346waf for ; Mon, 17 Sep 2007 01:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:subject:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; bh=ekUUM1SmOPbYJG1bLUIkZtLSPfMwOMvltD62QLomcbY=; b=qHuZspHk8GnjObNPZiYaCgib5VqdiuO3eSg3rq/9Avpgo33GtiypodhAGYtoryEgzFUsrpCR7MQCiIl3a36aOqDuwVh/NsEYJIRYCEYcu8EiQRAoAkvnC4xUIxFGTBVZfWZ8I7NyVXhK3ffLc5aXwYQeueX7bDIbSVsg19XZaJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; b=TPdyCMkM2C0ks1hxrBafgk4h1Ve9w6AZt5xLqmE17ZZABVXmAzHiFIhs2fGcCAOWLu7HferAFgh7iOAE6ZEEnuUk+SgKVOeHz7WSWZvTOO9YOlwvvreWyvq0b3/41fYXylu+CrDlopPWxMAbhToTkDgpMTgXUwsTy5XlbEQaaP0= Received: by 10.114.178.1 with SMTP id a1mr43910waf.1190016762956; Mon, 17 Sep 2007 01:12:42 -0700 (PDT) Received: from ?127.0.0.1? ( [218.94.128.114]) by mx.google.com with ESMTPS id v32sm4391813wah.2007.09.17.01.12.40 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Sep 2007 01:12:41 -0700 (PDT) Date: Mon, 17 Sep 2007 16:12:41 +0800 From: Deng XueFeng To: freebsd-current@freebsd.org Message-Id: <20070917160248.003B.DENGXF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.31 [CN] Subject: using unix domain socket get ENOTCONN in both 6.2 and 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 08:40:46 -0000 today, when I trace some performance issue about my streaming server. I found a strange thing in domain socket. when read from a domain socket(created by socketpair,and write/read some times). read return -1, and errno = ENOTCONN (Socket is not connected.) then I write a test program, and can reproduce in 6.2 and 7.0 but not each time will get ENOTCONN. thanks. #./ud_test child recv len [4992] failed: Unknown error: 0 main send len [-1] failed: Socket is not connected /* * * gcc -Wall -Werror -o ud_test ud_test.c * */ #include #include #include #include #include #include #include #include int ud[2]; int child(void) { int fd; char buf[8193]; int ret; int flag; int err; fd = ud[1]; flag = fcntl(fd, F_GETFL); fcntl(fd, flag | O_NONBLOCK); while (1) { ret = read(fd, buf, sizeof(buf)); if (ret == 0) { usleep(100*1000); continue; } if (ret != sizeof(buf)) { err = errno; close(fd); printf("child recv len [%d] failed: %s\n", ret, strerror(err)); exit(1); } memset(buf, 'B', sizeof(buf)); ret = write(fd, buf, sizeof(buf)); if (ret != sizeof(buf)) { err = errno; close(fd); printf("child send len [%d] failed: %s\n", ret, strerror(err)); exit(1); } } return 0; } int start_child(void) { pid_t pid; pid = fork(); if (pid == -1) { perror("fork failed"); return (-1); } else if (pid == 0) { close(ud[0]); child(); exit(1); } else { close(ud[1]); return (0); } } int test_main(void) { int fd = ud[0]; int ret; char buf[8193]; int flag; int err; flag = fcntl(fd, F_GETFL); fcntl(fd, flag | O_NONBLOCK); while (1) { memset(buf, 'A', sizeof(buf)); ret = write(fd, buf, sizeof(buf)); if (ret != sizeof(buf)) { err = errno; close(fd); printf("main send len [%d] failed: %s\n", ret, strerror(err)); exit(1); } ret = read(fd, buf, sizeof(buf)); if (ret != sizeof(buf)) { err = errno; close(fd); printf("main recv len [%d] failed: %s\n", ret, strerror(err)); exit(1); } } return (0); } int main(void) { int ret; ret = socketpair(AF_UNIX, SOCK_STREAM, 0, &ud[0]); if (ret < 0) { printf("socketpair failed: %s\n", strerror(errno)); exit(1); } if (start_child() != 0) { return 1; } /* Let the child process get the socket established */ sleep(2); test_main(); puts("Parent process finished."); return 0; } -- Deng XueFeng From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 08:44:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEDCE16A418 for ; Mon, 17 Sep 2007 08:44:33 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8223113C458 for ; Mon, 17 Sep 2007 08:44:33 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from srv.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IXCDX-000Cpe-SL; Mon, 17 Sep 2007 12:44:32 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IXCEv-000AGm-5X; Mon, 17 Sep 2007 12:45:57 +0400 To: Kostik Belousov References: <96972293@srv.sem.ipt.ru> <20070917080415.GL79542@deviant.kiev.zoral.com.ua> <30899862@srv.sem.ipt.ru> <20070917083213.GM79542@deviant.kiev.zoral.com.ua> From: Boris Samorodov Date: Mon, 17 Sep 2007 12:45:57 +0400 In-Reply-To: <20070917083213.GM79542@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Mon\, 17 Sep 2007 11\:32\:13 +0300") Message-ID: <98737674@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: twa + dump = sbwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 08:44:34 -0000 On Mon, 17 Sep 2007 11:32:13 +0300 Kostik Belousov wrote: > On Mon, Sep 17, 2007 at 12:09:29PM +0400, Boris Samorodov wrote: > > On Mon, 17 Sep 2007 11:04:15 +0300 Kostik Belousov wrote: > > > On Mon, Sep 17, 2007 at 11:28:58AM +0400, Boris Samorodov wrote: > > > > Hi! > > > > > > > > > > > > I can't use dump at -CURRENT with twa. The process goes to sbwait > > > > state forever. Here are the details. > > > > > > > > $ uname -a > > > > FreeBSD test.ipt.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Sep 15 19:37:17 MSD 2007 bsam@test.ipt.ru:/usr/obj/usr/src/sys/TEST amd64 > > > > > > > > The controller: > > > > twa0: <3ware 9000 series Storage Controller> port 0x3000-0x30ff mem 0xd8000000-0xd9ffffff,0xda300000-0xda300fff irq 16 at device 0.0 on pci8 > > > > twa0: [GIANT-LOCKED] > > > > twa0: [ITHREAD] > > > > twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: > > > > twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 ports, Firmware FE9X 3.06.00.005, BIOS BE9X 3.06.00.002 > > > > > > > > Two disks at stripe: > > > > da1 at twa0 bus 0 target 1 lun 0 > > > > da1: Fixed Direct Access SCSI-5 device > > > > da1: 100.000MB/s transfers > > > > da1: 476816MB (976519168 512 byte sectors: 255H 63S/T 60785C) > > > > > > > > Mounted as: > > > > /dev/da1 /s ufs rw 2 2 > > > > > > > > The command: > > > > $ dump -0Luan -f s.dump /s > > > > DUMP: Date of this level 0 dump: Mon Sep 17 10:26:21 2007 > > > > DUMP: Date of last level 0 dump: the epoch > > > > DUMP: Dumping snapshot of /dev/da1 (/s) to s.dump > > > > DUMP: mapping (Pass I) [regular files] > > > > DUMP: mapping (Pass II) [directories] > > > > DUMP: estimated 432054 tape blocks. > > > > DUMP: dumping (Pass III) [directories] > > > > DUMP: dumping (Pass IV) [regular files] > > > > [wait here forever] > > > > > > > > The relevant part of iostat -w 10 and top: > > > > ----- > > > > tty da0 da1 cpu > > > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > > > 0 231 16.00 0 0.01 16.00 152 2.37 0 0 1 0 99 > > > > 0 257 16.00 1 0.02 16.00 147 2.29 0 0 1 0 99 > > > > 0 310 16.00 1 0.01 16.00 146 2.28 0 0 1 0 99 > > > > 0 265 16.00 0 0.01 16.00 152 2.38 0 0 1 0 99 > > > > 0 442 16.00 0 0.00 15.98 299 4.66 0 0 1 0 99 > > > > 0 620 15.54 3 0.04 3.46 1999 6.76 0 0 2 1 96 > > > > 0 363 16.00 0 0.01 2.77 5141 13.90 0 0 5 2 93 > > > > 0 309 0.00 0 0.00 3.22 114 0.36 0 0 0 0 100 > > > > 0 260 16.00 1 0.01 0.00 0 0.00 0 0 0 0 100 > > > > 0 263 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 > > > > > > > > last pid: 74610; load averages: 0.01, 0.06, 0.01 up 1+09:53:34 10:32:34 > > > > 98 processes: 98 sleeping > > > > CPU states: 0.0% user, 0.0% nice, 0.3% system, 0.0% interrupt, 99.6% idle > > > > Mem: 113M Active, 2374M Inact, 337M Wired, 480K Cache, 214M Buf, 4935M Free > > > > Swap: 4096M Total, 4096M Free > > > > > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > > > 74595 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump > > > > 74596 duser 1 20 0 28248K 26000K pause 2 0:01 0.00% dump > > > > 74594 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump > > > > 74593 duser 1 4 0 28248K 26020K sbwait 7 0:01 0.00% dump > > > > 74530 duser 1 8 0 28248K 26000K wait 6 0:01 0.00% dump > > > > 74443 duser 1 8 0 6216K 1904K wait 5 0:00 0.00% sh > > > > ----- > > > > > > > > Gdb shows nothing interesting: > > > > # gdb dump 74593 > > > > 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 "amd64-marcel-freebsd"...(no debugging symbols found)... > > > > Attaching to program: /sbin/dump, process 74593 > > > > Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. > > > > Loaded symbols for /lib/libc.so.7 > > > > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. > > > > Loaded symbols for /libexec/ld-elf.so.1 > > > > 0x000000080071b34a in read () from /lib/libc.so.7 > > > > > > > > Shall I do some more debugging? Thanks! > > > > > Please, verify that you have rev. 1.39 of sys/kern/subr_sleepqueue.c. > > > > % grep FBSDID /sys/kern/subr_sleepqueue.c > > __FBSDID("$FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39 2007/09/13 09:12:36 attilio Exp $"); > Most likely, this is a different bug then. Just to make sure, please, show > the output of ps axl | grep dump. The dump processes shall sleep, and be > killable (check that, please). % ps axwwl | grep dump | grep -v grep 9900 74530 74443 0 8 0 28248 26000 wait I+ p1 0:00.88 dump -0Luan -f s.dump /s (dump) 9900 74593 74530 0 4 0 28248 26020 sbwait I+ p1 0:01.05 dump: /dev/da1: pass 4: 44.73% done, finished in 0:00 at Mon Sep 17 10:27:03 2007 (dump) 9900 74594 74593 1 20 0 28248 26000 pause I+ p1 0:01.06 dump -0Luan -f s.dump /s (dump) 9900 74595 74593 0 20 0 28248 26000 pause I+ p1 0:01.06 dump -0Luan -f s.dump /s (dump) 9900 74596 74593 0 20 0 28248 26000 pause I+ p1 0:01.06 dump -0Luan -f s.dump /s (dump) The process is killable: # killall dump [...] DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") DUMP: "Yes" or "No"? DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") no DUMP: Do you want to abort?: ("yes" or "no") yes DUMP: The ENTIRE dump is aborted. # WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 08:58:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8C4416A419 for ; Mon, 17 Sep 2007 08:58:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7EC13C480 for ; Mon, 17 Sep 2007 08:58:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IXCQa-000IDA-IF for freebsd-current@freebsd.org; Mon, 17 Sep 2007 11:58:10 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l8H8vqNV057676; Mon, 17 Sep 2007 11:57:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l8H8vple057675; Mon, 17 Sep 2007 11:57:51 +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: Mon, 17 Sep 2007 11:57:51 +0300 From: Kostik Belousov To: Boris Samorodov Message-ID: <20070917085751.GN79542@deviant.kiev.zoral.com.ua> References: <96972293@srv.sem.ipt.ru> <20070917080415.GL79542@deviant.kiev.zoral.com.ua> <30899862@srv.sem.ipt.ru> <20070917083213.GM79542@deviant.kiev.zoral.com.ua> <98737674@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EqVOK5mkaJAMmtSx" Content-Disposition: inline In-Reply-To: <98737674@srv.sem.ipt.ru> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: b80252922cd4db18d8ff55d8d8614881 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1482 [September 17 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-current@freebsd.org Subject: Re: twa + dump = sbwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 08:58:11 -0000 --EqVOK5mkaJAMmtSx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 17, 2007 at 12:45:57PM +0400, Boris Samorodov wrote: > On Mon, 17 Sep 2007 11:32:13 +0300 Kostik Belousov wrote: > > On Mon, Sep 17, 2007 at 12:09:29PM +0400, Boris Samorodov wrote: > > > On Mon, 17 Sep 2007 11:04:15 +0300 Kostik Belousov wrote: > > > > On Mon, Sep 17, 2007 at 11:28:58AM +0400, Boris Samorodov wrote: > > > > > Hi! > > > > >=20 > > > > >=20 > > > > > I can't use dump at -CURRENT with twa. The process goes to sbwait > > > > > state forever. Here are the details. > > > > >=20 > > > > > $ uname -a > > > > > FreeBSD test.ipt.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Sep 1= 5 19:37:17 MSD 2007 bsam@test.ipt.ru:/usr/obj/usr/src/sys/TEST amd64 > > > > >=20 > > > > > The controller: > > > > > twa0: <3ware 9000 series Storage Controller> port 0x3000-0x30ff m= em 0xd8000000-0xd9ffffff,0xda300000-0xda300fff irq 16 at device 0.0 on pci8 > > > > > twa0: [GIANT-LOCKED] > > > > > twa0: [ITHREAD] > > > > > twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue:=20 > > > > > twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LP= ML, 8 ports, Firmware FE9X 3.06.00.005, BIOS BE9X 3.06.00.002 > > > > >=20 > > > > > Two disks at stripe: > > > > > da1 at twa0 bus 0 target 1 lun 0 > > > > > da1: Fixed Direct Access SCSI-5 devic= e=20 > > > > > da1: 100.000MB/s transfers > > > > > da1: 476816MB (976519168 512 byte sectors: 255H 63S/T 60785C) > > > > >=20 > > > > > Mounted as: > > > > > /dev/da1 /s ufs rw 2 2 > > > > >=20 > > > > > The command: > > > > > $ dump -0Luan -f s.dump /s > > > > > DUMP: Date of this level 0 dump: Mon Sep 17 10:26:21 2007 > > > > > DUMP: Date of last level 0 dump: the epoch > > > > > DUMP: Dumping snapshot of /dev/da1 (/s) to s.dump > > > > > DUMP: mapping (Pass I) [regular files] > > > > > DUMP: mapping (Pass II) [directories] > > > > > DUMP: estimated 432054 tape blocks. > > > > > DUMP: dumping (Pass III) [directories] > > > > > DUMP: dumping (Pass IV) [regular files] > > > > > [wait here forever] > > > > >=20 > > > > > The relevant part of iostat -w 10 and top: > > > > > ----- > > > > > tty da0 da1 cpu > > > > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > > > > 0 231 16.00 0 0.01 16.00 152 2.37 0 0 1 0 99 > > > > > 0 257 16.00 1 0.02 16.00 147 2.29 0 0 1 0 99 > > > > > 0 310 16.00 1 0.01 16.00 146 2.28 0 0 1 0 99 > > > > > 0 265 16.00 0 0.01 16.00 152 2.38 0 0 1 0 99 > > > > > 0 442 16.00 0 0.00 15.98 299 4.66 0 0 1 0 99 > > > > > 0 620 15.54 3 0.04 3.46 1999 6.76 0 0 2 1 96 > > > > > 0 363 16.00 0 0.01 2.77 5141 13.90 0 0 5 2 93 > > > > > 0 309 0.00 0 0.00 3.22 114 0.36 0 0 0 0 100 > > > > > 0 260 16.00 1 0.01 0.00 0 0.00 0 0 0 0 100 > > > > > 0 263 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 > > > > >=20 > > > > > last pid: 74610; load averages: 0.01, 0.06, 0.01 up 1+09:5= 3:34 10:32:34 > > > > > 98 processes: 98 sleeping > > > > > CPU states: 0.0% user, 0.0% nice, 0.3% system, 0.0% interrupt= , 99.6% idle > > > > > Mem: 113M Active, 2374M Inact, 337M Wired, 480K Cache, 214M Buf, = 4935M Free > > > > > Swap: 4096M Total, 4096M Free > > > > >=20 > > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU= COMMAND > > > > > 74595 duser 1 20 0 28248K 26000K pause 5 0:01 0.00%= dump > > > > > 74596 duser 1 20 0 28248K 26000K pause 2 0:01 0.00%= dump > > > > > 74594 duser 1 20 0 28248K 26000K pause 5 0:01 0.00%= dump > > > > > 74593 duser 1 4 0 28248K 26020K sbwait 7 0:01 0.00%= dump > > > > > 74530 duser 1 8 0 28248K 26000K wait 6 0:01 0.00%= dump > > > > > 74443 duser 1 8 0 6216K 1904K wait 5 0:00 0.00%= sh > > > > > ----- > > > > >=20 > > > > > Gdb shows nothing interesting: > > > > > # gdb dump 74593 > > > > > 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" fo= r details. > > > > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging= symbols found)... > > > > > Attaching to program: /sbin/dump, process 74593 > > > > > Reading symbols from /lib/libc.so.7...(no debugging symbols found= )...done. > > > > > Loaded symbols for /lib/libc.so.7 > > > > > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols= found)...done. > > > > > Loaded symbols for /libexec/ld-elf.so.1 > > > > > 0x000000080071b34a in read () from /lib/libc.so.7 > > > > >=20 > > > > > Shall I do some more debugging? Thanks! > > >=20 > > > > Please, verify that you have rev. 1.39 of sys/kern/subr_sleepqueue.= c. > > >=20 > > > % grep FBSDID /sys/kern/subr_sleepqueue.c > > > __FBSDID("$FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39 2007/09/13 = 09:12:36 attilio Exp $"); >=20 > > Most likely, this is a different bug then. Just to make sure, please, s= how > > the output of ps axl | grep dump. The dump processes shall sleep, and be > > killable (check that, please). >=20 > % ps axwwl | grep dump | grep -v grep > 9900 74530 74443 0 8 0 28248 26000 wait I+ p1 0:00.88 dump = -0Luan -f s.dump /s (dump) > 9900 74593 74530 0 4 0 28248 26020 sbwait I+ p1 0:01.05 dump:= /dev/da1: pass 4: 44.73% done, finished in 0:00 at Mon Sep 17 10:27:03 200= 7 (dump) > 9900 74594 74593 1 20 0 28248 26000 pause I+ p1 0:01.06 dump = -0Luan -f s.dump /s (dump) > 9900 74595 74593 0 20 0 28248 26000 pause I+ p1 0:01.06 dump = -0Luan -f s.dump /s (dump) > 9900 74596 74593 0 20 0 28248 26000 pause I+ p1 0:01.06 dump = -0Luan -f s.dump /s (dump) >=20 >=20 > The process is killable: > # killall dump > [...] > DUMP: Is the new volume mounted and ready to go?: ("yes" or "no")=20 > DUMP: "Yes" or "No"? > DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") no > DUMP: Do you want to abort?: ("yes" or "no") yes > DUMP: The ENTIRE dump is aborted. > # And, are you sure that no dump processes left in the system ? If yes, this is indeed some other bug. --EqVOK5mkaJAMmtSx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG7kGPC3+MBN1Mb4gRAluuAKDFZL4j4oE6DGPmTncdU9ZgewJw4wCfWmiC /WudNQokfWCN4QOm3JOdlbA= =Jd8Z -----END PGP SIGNATURE----- --EqVOK5mkaJAMmtSx-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 09:15:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33FC116A418 for ; Mon, 17 Sep 2007 09:15:29 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id B6CF813C45D for ; Mon, 17 Sep 2007 09:15:28 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from admin.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IXChS-000D2q-Ka; Mon, 17 Sep 2007 13:15:26 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IXCiq-000AI5-0O; Mon, 17 Sep 2007 13:16:52 +0400 To: Kostik Belousov References: <96972293@srv.sem.ipt.ru> <20070917080415.GL79542@deviant.kiev.zoral.com.ua> <30899862@srv.sem.ipt.ru> <20070917083213.GM79542@deviant.kiev.zoral.com.ua> <98737674@srv.sem.ipt.ru> <20070917085751.GN79542@deviant.kiev.zoral.com.ua> From: Boris Samorodov Date: Mon, 17 Sep 2007 13:16:51 +0400 In-Reply-To: <20070917085751.GN79542@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Mon\, 17 Sep 2007 11\:57\:51 +0300") Message-ID: <11215820@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: twa + dump = sbwait X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 09:15:29 -0000 On Mon, 17 Sep 2007 11:57:51 +0300 Kostik Belousov wrote: > On Mon, Sep 17, 2007 at 12:45:57PM +0400, Boris Samorodov wrote: > > On Mon, 17 Sep 2007 11:32:13 +0300 Kostik Belousov wrote: > > > On Mon, Sep 17, 2007 at 12:09:29PM +0400, Boris Samorodov wrote: > > > > On Mon, 17 Sep 2007 11:04:15 +0300 Kostik Belousov wrote: > > > > > On Mon, Sep 17, 2007 at 11:28:58AM +0400, Boris Samorodov wrote: > > > > > > Hi! > > > > > > > > > > > > > > > > > > I can't use dump at -CURRENT with twa. The process goes to sbwait > > > > > > state forever. Here are the details. > > > > > > > > > > > > $ uname -a > > > > > > FreeBSD test.ipt.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat Sep 15 19:37:17 MSD 2007 bsam@test.ipt.ru:/usr/obj/usr/src/sys/TEST amd64 > > > > > > > > > > > > The controller: > > > > > > twa0: <3ware 9000 series Storage Controller> port 0x3000-0x30ff mem 0xd8000000-0xd9ffffff,0xda300000-0xda300fff irq 16 at device 0.0 on pci8 > > > > > > twa0: [GIANT-LOCKED] > > > > > > twa0: [ITHREAD] > > > > > > twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: > > > > > > twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 ports, Firmware FE9X 3.06.00.005, BIOS BE9X 3.06.00.002 > > > > > > > > > > > > Two disks at stripe: > > > > > > da1 at twa0 bus 0 target 1 lun 0 > > > > > > da1: Fixed Direct Access SCSI-5 device > > > > > > da1: 100.000MB/s transfers > > > > > > da1: 476816MB (976519168 512 byte sectors: 255H 63S/T 60785C) > > > > > > > > > > > > Mounted as: > > > > > > /dev/da1 /s ufs rw 2 2 > > > > > > > > > > > > The command: > > > > > > $ dump -0Luan -f s.dump /s > > > > > > DUMP: Date of this level 0 dump: Mon Sep 17 10:26:21 2007 > > > > > > DUMP: Date of last level 0 dump: the epoch > > > > > > DUMP: Dumping snapshot of /dev/da1 (/s) to s.dump > > > > > > DUMP: mapping (Pass I) [regular files] > > > > > > DUMP: mapping (Pass II) [directories] > > > > > > DUMP: estimated 432054 tape blocks. > > > > > > DUMP: dumping (Pass III) [directories] > > > > > > DUMP: dumping (Pass IV) [regular files] > > > > > > [wait here forever] > > > > > > > > > > > > The relevant part of iostat -w 10 and top: > > > > > > ----- > > > > > > tty da0 da1 cpu > > > > > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > > > > > 0 231 16.00 0 0.01 16.00 152 2.37 0 0 1 0 99 > > > > > > 0 257 16.00 1 0.02 16.00 147 2.29 0 0 1 0 99 > > > > > > 0 310 16.00 1 0.01 16.00 146 2.28 0 0 1 0 99 > > > > > > 0 265 16.00 0 0.01 16.00 152 2.38 0 0 1 0 99 > > > > > > 0 442 16.00 0 0.00 15.98 299 4.66 0 0 1 0 99 > > > > > > 0 620 15.54 3 0.04 3.46 1999 6.76 0 0 2 1 96 > > > > > > 0 363 16.00 0 0.01 2.77 5141 13.90 0 0 5 2 93 > > > > > > 0 309 0.00 0 0.00 3.22 114 0.36 0 0 0 0 100 > > > > > > 0 260 16.00 1 0.01 0.00 0 0.00 0 0 0 0 100 > > > > > > 0 263 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 > > > > > > > > > > > > last pid: 74610; load averages: 0.01, 0.06, 0.01 up 1+09:53:34 10:32:34 > > > > > > 98 processes: 98 sleeping > > > > > > CPU states: 0.0% user, 0.0% nice, 0.3% system, 0.0% interrupt, 99.6% idle > > > > > > Mem: 113M Active, 2374M Inact, 337M Wired, 480K Cache, 214M Buf, 4935M Free > > > > > > Swap: 4096M Total, 4096M Free > > > > > > > > > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > > > > > 74595 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump > > > > > > 74596 duser 1 20 0 28248K 26000K pause 2 0:01 0.00% dump > > > > > > 74594 duser 1 20 0 28248K 26000K pause 5 0:01 0.00% dump > > > > > > 74593 duser 1 4 0 28248K 26020K sbwait 7 0:01 0.00% dump > > > > > > 74530 duser 1 8 0 28248K 26000K wait 6 0:01 0.00% dump > > > > > > 74443 duser 1 8 0 6216K 1904K wait 5 0:00 0.00% sh > > > > > > ----- > > > > > > > > > > > > Gdb shows nothing interesting: > > > > > > # gdb dump 74593 > > > > > > 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 "amd64-marcel-freebsd"...(no debugging symbols found)... > > > > > > Attaching to program: /sbin/dump, process 74593 > > > > > > Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. > > > > > > Loaded symbols for /lib/libc.so.7 > > > > > > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. > > > > > > Loaded symbols for /libexec/ld-elf.so.1 > > > > > > 0x000000080071b34a in read () from /lib/libc.so.7 > > > > > > > > > > > > Shall I do some more debugging? Thanks! > > > > > > > > > Please, verify that you have rev. 1.39 of sys/kern/subr_sleepqueue.c. > > > > > > > > % grep FBSDID /sys/kern/subr_sleepqueue.c > > > > __FBSDID("$FreeBSD: src/sys/kern/subr_sleepqueue.c,v 1.39 2007/09/13 09:12:36 attilio Exp $"); > > > > > Most likely, this is a different bug then. Just to make sure, please, show > > > the output of ps axl | grep dump. The dump processes shall sleep, and be > > > killable (check that, please). > > > > % ps axwwl | grep dump | grep -v grep > > 9900 74530 74443 0 8 0 28248 26000 wait I+ p1 0:00.88 dump -0Luan -f s.dump /s (dump) > > 9900 74593 74530 0 4 0 28248 26020 sbwait I+ p1 0:01.05 dump: /dev/da1: pass 4: 44.73% done, finished in 0:00 at Mon Sep 17 10:27:03 2007 (dump) > > 9900 74594 74593 1 20 0 28248 26000 pause I+ p1 0:01.06 dump -0Luan -f s.dump /s (dump) > > 9900 74595 74593 0 20 0 28248 26000 pause I+ p1 0:01.06 dump -0Luan -f s.dump /s (dump) > > 9900 74596 74593 0 20 0 28248 26000 pause I+ p1 0:01.06 dump -0Luan -f s.dump /s (dump) > > > > > > The process is killable: > > # killall dump > > [...] > > DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") > > DUMP: "Yes" or "No"? > > DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") no > > DUMP: Do you want to abort?: ("yes" or "no") yes > > DUMP: The ENTIRE dump is aborted. > > # > And, are you sure that no dump processes left in the system ? If yes, this > is indeed some other bug. % ps auwx | grep dump | grep -v grep % WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 09:21:32 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5C0B16A468; Mon, 17 Sep 2007 09:21:32 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 628B313C474; Mon, 17 Sep 2007 09:21:32 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l8H9LUcZ024575; Mon, 17 Sep 2007 13:21:30 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1190020890; bh=in9z/PHZlGEE4tG+WYA7NtgItI4Bi1zZQaoCIFt Dt7k=; l=909; h=Date:From:To:Cc:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent; b=uOQLGFj6FPzeQ1rQme8/xregDOupVjSb+ZuPLH71 oVDd54XmuzZ8A9cWWOFoZ0wkHAzdMAtSFwtjU0hTyyNtaNBRlfwo6jH5hmVjw4+7qxE +I1dNJ2C8TCEdtpGzWLXxVRMukoKafMBe7w8IsnU69wLnT0YZT7craYCnE5sSB+w= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l8H9LU6d024574; Mon, 17 Sep 2007 13:21:30 +0400 (MSD) (envelope-from ache) Date: Mon, 17 Sep 2007 13:21:30 +0400 From: Andrey Chernov To: Petr Hroudn?? Message-ID: <20070917092130.GA24424@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Petr Hroudn?? , current@freebsd.org, i18n@freebsd.org, perky@freebsd.org References: <20070916192924.GA12678@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: perky@freebsd.org, current@freebsd.org, i18n@freebsd.org Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 09:21:33 -0000 On Mon, Sep 17, 2007 at 10:29:21AM +0200, Petr Hroudn?? wrote: > 2007/9/16, Andrey Chernov : > > The problem is: currently our single byte ctype functions are broken for > > wide characters locales in the argument range >= 0x80 - they may return > > false positives. > > > > For example, for UTF-8 locale we currently have: > > iswspace(0xA0)==1 and isspace(0xA0)==1 > > (because iswspace() and isspace() are the same code) > > but must have > > isspace(0xA0)==0 > > This is exactly what happens on other OSes and I agree this is the > right behaviour > for UTF-8. However, we must ensure, that: > > for C locale: isspace(0xA0)==0 > for ISO8859-* locales: isspace(0xA0)==1 > for UTF-8 locales: isspace(0xA0)==0 The patch test for wide char locale presence first (__mb_cur_max > 1), so does not affect single byte locales like ISO8859-* -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 09:25:44 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D76116A41B; Mon, 17 Sep 2007 09:25:44 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id D9A6913C4B3; Mon, 17 Sep 2007 09:25:42 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46EE4815.3050305@FreeBSD.org> Date: Mon, 17 Sep 2007 11:25:41 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ganbold References: <20070916225019.B921C4500C@ptavv.es.net> <46EDCC48.2090405@FreeBSD.org> <20070916202402.X4507@10.0.0.1> <46EE2C98.90802@micom.mng.net> In-Reply-To: <46EE2C98.90802@micom.mng.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , "David E. Thiel" , freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 09:25:44 -0000 Ganbold wrote: > I explained my problem in > http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076450.html. > This is a UP system and I have 1GB RAM and top results are shown there. Well, you have some other things to rule out still. Your kernel contains WITNESS! Kris From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 11:51:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9632316A420 for ; Mon, 17 Sep 2007 11:51:09 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 206F313C494 for ; Mon, 17 Sep 2007 11:51:08 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l8HBp5ff002136; Mon, 17 Sep 2007 21:51:05 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l8HBp586002135; Mon, 17 Sep 2007 21:51:05 +1000 (EST) (envelope-from peter) Date: Mon, 17 Sep 2007 21:51:05 +1000 From: Peter Jeremy To: Deng XueFeng Message-ID: <20070917115105.GH1163@turion.vk2pj.dyndns.org> References: <20070917160248.003B.DENGXF@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <20070917160248.003B.DENGXF@gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: using unix domain socket get ENOTCONN in both 6.2 and 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 11:51:09 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Sep-17 16:12:41 +0800, Deng XueFeng wrote: >then I write a test program, and can reproduce in 6.2 and 7.0 Read() and write() do not preserve message boundaries so you cannot guarantee to read 8193 bytes just because you wrote 8193 bytes. >#./ud_test >child recv len [4992] failed: Unknown error: 0 This is an error in your program: The read() succeeded and returned 4992 bytes. The child then exits >main send len [-1] failed: Socket is not connected Which leaves the socket unconnected so the parent (correctly) receives an error. --=20 Peter Jeremy --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG7moo/opHv/APuIcRAr0LAJ9Q0Y9UZDG0YbQRjSVFjsrcikp5ewCfZD6Y 6Z87lTVREmFdAB1ae1m6B/c= =5dXH -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 15:42:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAC8B16A417 for ; Fri, 14 Sep 2007 15:42:25 +0000 (UTC) (envelope-from ragge@ludd.ltu.se) Received: from mxi.ltu.se (mxi.ltu.se [130.240.42.23]) by mx1.freebsd.org (Postfix) with ESMTP id 8FAAA13C428 for ; Fri, 14 Sep 2007 15:42:25 +0000 (UTC) (envelope-from ragge@ludd.ltu.se) Received: from [130.240.112.103] (mandarine.its.ltu.se [130.240.112.103]) by mxi.ltu.se (8.13.1/8.13.1) with ESMTP id l8EEujcV019612 for ; Fri, 14 Sep 2007 16:56:45 +0200 Message-ID: <46EAA12D.4090207@ludd.ltu.se> Date: Fri, 14 Sep 2007 16:56:45 +0200 From: Anders Magnusson User-Agent: Thunderbird 1.5.0.12 (X11/20070718) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 17 Sep 2007 12:02:39 +0000 Subject: Compiling with another compiler than gcc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 15:42:26 -0000 (FYI: this mail was sent to a NetBSD mailing list, but it may be people interested of it here also) Hm, I realized that there were more people interested in this compiler, so I'll send a mail about it on these lists also. I have setup a mailing list about pcc, join it by: _echo "subscribe pcc-list" | Mail majordomo@ludd.ltu.se_ or similar. There is also an embryo to a web page about pcc; http://www.ludd.ltu.se/~ragge/pcc/ which contains some basic information. I have (as some people may know) been hacking on pcc for fun for some years. After having that project on the shelf for a year or so, I decided to make the compiler at least compile the NetBSD source tree again. It is not yet bug-free, but it can compile the i386 userspace. The big benefit of it (apart from that it's BSD licensed, for license geeks :-) is that it is fast, 5-10 times faster than gcc, while still producing reasonable code. The only optimization added so far is a multiple-register-class graph-coloring register allocator, which may be one of the best register allocators today. Conversion to SSA format is also implemented, but not yet the phi function. Not too difficult though, after that strength reduction is high on the list. It is also quite simple to port, writing the basics for i386 took three hours (hello world) and complete port (pretty much as it is right now) two days. I have added most of the C99 stuff (it is supposed to be a c99 compiler) but some stuff is still missing, like the ability to do variable declarations anywhere (requires some rewriting of the yacc code). If someone wants to look at the compiler it can be fetched from ftp://226.net120.skekraft.net/pcc/pcc-current.tgz, current version is 0.9.8. Currently only the i386 port is "supported", but there are a bunch of architectures included that probably wont compile. -- Ragge From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 08:31:49 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B440816A41B; Sat, 15 Sep 2007 08:31:49 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 7820F13C46E; Sat, 15 Sep 2007 08:31:49 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from coruscant.local (naboo.binarysolutions.dk [80.196.17.173]) by solow.pil.dk (Postfix) with ESMTP id 42C9B1CC0B8; Sat, 15 Sep 2007 10:31:33 +0200 (CEST) Received: by coruscant.local (Postfix, from userid 502) id 5BF83646758; Sat, 15 Sep 2007 10:31:32 +0200 (CEST) To: Pawel Jakub Dawidek References: <20070905141759.GJ12013@garage.freebsd.pl> <20070905171741.GA15709@garage.freebsd.pl> <20070913083635.GB1155@garage.freebsd.pl> From: Kenneth Vestergaard Schmidt Date: Sat, 15 Sep 2007 10:31:32 +0200 In-Reply-To: <20070913083635.GB1155@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Thu\, 13 Sep 2007 10\:36\:35 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 17 Sep 2007 12:02:39 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Unkillable and runaway processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 08:31:49 -0000 Pawel Jakub Dawidek writes: >> >> The full state of the process hanging is 'zfs:(&tx->tx_quiesce_done_cv)' >> >> - it cycles between RUN, CPUx and this one. >> > >> > Hmm, this means it didn't deadlock... >> >> Here's some debugging output. PIDs 14870, 14933 and 12458 are just >> spinning and being useless. Funnily, all three have rename() in their >> backtrace. >> >> db> ps > [...] >> 360 0 0 0 SL zfs:(&tq 0xd151877c [zil_clean] >> 359 0 0 0 SL zfs:(&tq 0xd1518848 [zil_clean] > [...] > > Are you sure you disabled ZIL? Not in that output, but after that I did, and the problem remained. I'll try to get a new dump, but right now I'm fighting 'kmem_map too small' panics again :( panic: kmem_malloc(16384): kmem_map too small: 628477952 total allocated panic(c0772a72,4000,2575d000,fbfee530,c070a4b0,...) at panic+0x124 kmem_malloc(c107108c,4000,2,fbfee580,c06bf020,...) at kmem_malloc+0x22b page_alloc(0,4000,fbfee573,2,2000000,...) at page_alloc+0x27 uma_large_malloc(4000,2,c7445200,c7591460,cc6a7d80,...) at uma_large_malloc+0x50 malloc(4000,c758e6a0,2,fbfee5c4,c7569c29,...) at malloc+0x88 zfs_kmem_alloc(4000,2,fbfee60c,c751d9b8,4000,...) at zfs_kmem_alloc+0x20 zio_buf_alloc(4000,2,2,10,c8576ce4,...) at zio_buf_alloc+0x19 arc_get_data_buf(c73e4e80,2,5,0,0,...) at arc_get_data_buf+0x5a8 arc_buf_alloc(c73cd800,4000,d8e442bc,2,479,...) at arc_buf_alloc+0xb0 arc_read(cb81ecf0,c73cd800,d3f8b080,c7561480,c7521be0,...) at arc_read+0x125 dbuf_read(d8e442bc,0,2,c7585d6f,fbfee704,...) at dbuf_read+0x4b7 dmu_buf_hold(d0dd3a90,4f6a,0,1004000,0,...) at dmu_buf_hold+0xea zap_idx_to_blk(fbfee770,6e1,c8f29638,0,5d875fa0,...) at zap_idx_to_blk+0xcc zap_deref_leaf(0,1,fbfee7c0,0,c758ba5f,...) at zap_deref_leaf+0x5a fzap_lookup(c8f29600,fbfee8bc,8,0,1,...) at fzap_lookup+0x78 zap_lookup(d0dd3a90,4f6a,0,fbfee8bc,8,...) at zap_lookup+0x81 zfs_dirent_lock(fbfee874,d0274bfc,fbfee8bc,fbfee870,6,...) at zfs_dirent_lock+0x30a zfs_dirlook(d0274bfc,fbfee8bc,fbfeeb5c,c05740f1,0,...) at zfs_dirlook+0x5e /Kenneth From owner-freebsd-current@FreeBSD.ORG Sat Sep 15 11:47:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C6F616A419 for ; Sat, 15 Sep 2007 11:47:23 +0000 (UTC) (envelope-from Gabor@Zahemszky.HU) Received: from mail01a.mail.t-online.hu (mail01a.mail.t-online.hu [84.2.40.6]) by mx1.freebsd.org (Postfix) with ESMTP id CD37213C461 for ; Sat, 15 Sep 2007 11:47:22 +0000 (UTC) (envelope-from Gabor@Zahemszky.HU) Received: from Picasso.Zahemszky.HU (dsl54028756.pool.t-online.hu [84.2.135.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail01a.mail.t-online.hu (Postfix) with ESMTP id 6DD1D1368B3; Sat, 15 Sep 2007 13:47:20 +0200 (CEST) Date: Sat, 15 Sep 2007 13:47:15 +0200 From: Zahemszky =?ISO-8859-2?Q?G=E1bor?= To: Weongyo Jeong Message-ID: <20070915134715.1abd092d@Picasso.Zahemszky.HU> In-Reply-To: <20070915032507.GA94238@freebsd.weongyo.org> References: <20070908164003.06ffa0dc@Picasso.Zahemszky.HU> <20070915032507.GA94238@freebsd.weongyo.org> Organization: Zahemszky Bt. X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.14; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 17 Sep 2007 12:02:39 +0000 Cc: freebsd-current@freebsd.org Subject: Re: crash (and the backtrace) in the new if_zyd driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 11:47:23 -0000 Sat, 15 Sep 2007 12:25:07 +0900 -n Weongyo Jeong =C3=ADrta: Hi! Here it is. > I checked your panic in my environment and tried to repeat panic you > encountered, but I failed. Interesting :-( > condition in ehci or zyd. Can you try to build the buildworld and the > buildkernel newly with CURRENT and tell me the result after trying to > up the zyd driver again? The source is csup-ped today morning, after reading your e-mail. (I compiled if_zyd *into* the kernel (and made a module, too). Now, I can 'ifconfig up' the interface without panic. I can ifconfig zyd0 list scan, too, but some seconds later, it panicked. The backtrace is: =3D=3D=3D Picasso# kgdb -q /usr/obj/usr/src/sys/GENERIC/kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0x34 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc06a0d66 stack pointer =3D 0x28:0xe3d6ea4c frame pointer =3D 0x28:0xe3d6ea74 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 13 (swi4: clock sio) Physical memory: 2009 MB Dumping 75 MB: 60 44 28 12 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc048cec9 in db_fncall (dummy1=3D-472455052, dummy2=3D0, dummy3=3D582, dummy4=3D0xe3d6e7e0 "p=F1H=C0") at /usr/src/sys/ddb/db_command.c:486 #2 0xc048d435 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401=20 #3 0xc048eba5 in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_main.c:222=20 #4 0xc0777926 in kdb_trap (type=3D12, code=3D0, tf=3D0xe3d6ea0c) at /usr/src/sys/kern/subr_kdb.c:502=20 #5 0xc0a0431f in trap_fatal (frame=3D0xe3d6ea0c, eva=3D52) at /usr/src/sys/i386/i386/trap.c:863=20 #6 0xc0a04553 in trap_pfault (frame=3D0xe3d6ea0c, usermode=3D0, eva=3D52) at /usr/src/sys/i386/i386/trap.c:785=20 #7 0xc0a04f05 in trap (frame=3D0xe3d6ea0c) at /usr/src/sys/i386/i386/trap.c:463=20 #8 0xc09eaa9b in calltrap () at /usr/src/sys/i386/i386/exception.s:139=20 #9 0xc06a0d66 in ehci_alloc_sqtd (sc=3D0xc519a000) at /usr/src/sys/dev/usb/ehci.c:2281=20 #10 0xc06a33f1 in ehci_device_bulk_start (xfer=3D0xc556dc00) at /usr/src/sys/dev/usb/ehci.c:3032=20 #11 0xc06a35d3 in ehci_device_bulk_transfer (xfer=3D0xc556dc00) at /usr/src/sys/dev/usb/ehci.c:2998=20 #12 0xc06d1fab in usbd_start_transfer (arg=3D0xc556dc00, segs=3D0xc556dc3c, nseg=3D1, error=3D0) at /usr/src/sys/dev/usb/usbdi.c:388=20 #13 0xc06d2545 in usbd_transfer (xfer=3D0xc556dc00) at /usr/src/sys/dev/usb/usbdi.c:320=20 #14 0xc06b88d2 in zyd_start (ifp=3D0xc5630c00) at /usr/src/sys/dev/usb/if_zyd.c:2096=20 #15 0xc07df959 in if_start (ifp=3D0xc5630c00) at /usr/src/sys/net/if.c:2704=20 #16 0xc08104c5 in ieee80211_send_probereq (ni=3D0xc5ac7000, sa=3D0xc5ac5288 "", da=3D0xc0a3aa80 "=FF=FF=FF=FF=FF=FFether_ifattach", bssid=3D0xc0a3aa80 "=FF=FF=FF=FF=FF=FFether_ifattach", ssid=3D0xc0a8ebdb "", ssidlen=3D0, opti= e=3D0x0, optielen=3D0) at /usr/src/sys/net80211/ieee80211_output.c:1540=20 #17 0xc0816e9a in scan_curchan (ic=3D0xc5ac5008, maxdwell=3D200) at /usr/src/sys/net80211/ieee80211_scan.c:664=20 #18 0xc0815ff9 in scan_next (arg=3D0xc55ad000) at /usr/src/sys/net80211/ieee80211_scan.c:753=20 #19 0xc07626e9 in softclock (dummy=3D0x0) at /usr/src/sys/kern/kern_timeout.c:281=20 #20 0xc0735655 in ithread_loop (arg=3D0xc50b24f0) at /usr/src/sys/kern/kern_intr.c:1036=20 #21 0xc0732ad8 in fork_exit (callout=3D0xc07354a0 , arg=3D0xc50b24f0, frame=3D0xe3d6ed38) at /usr/src/sys/kern/kern_fork.c:797 #22 0xc09eab10 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb)=20 =3D=3D=3D Bye, Gabor < Gabor at Zahemszky dot HU > --=20 #!/bin/ksh Z=3D'21N16I25C25E30, 40M30E33E25T15U!';IFS=3D' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';set -- $Z;for i;{ [[ $i =3D ? ]]&&print $i&&break;[[ $i =3D ??? ]]&&j=3D$i&&i=3D${i%?};typeset -i40 i=3D8#$i;print -n ${i#???};[[ "= $j" =3D ??? ]]&&print -n "${j#??} "&&j=3D;typeset +i i;};IFS=3D' 0123456789 ';s= et -- $Z;for i;{ [[ $i =3D , ]]&&i=3D2;[[ $i =3D ?? ]]||typeset -l i;j=3D"$j $i";typeset +l i;};print "$j" From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 08:56:38 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 779BC16A418 for ; Mon, 17 Sep 2007 08:56:38 +0000 (UTC) (envelope-from petr.hroudny@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 082C813C442 for ; Mon, 17 Sep 2007 08:56:37 +0000 (UTC) (envelope-from petr.hroudny@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1073432nfb for ; Mon, 17 Sep 2007 01:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DY9qk1mrQzFSVme1UmL3SYzjxsNz/ddmqKQVCmrMEss=; b=VJbCVJgXvJvBy9eIBcob8ESz+HuSlqaf+XKdUFaS+eALWYyF3Ma8/QubeRV2o3IenwY4RrWirA7SmjYUGRpaojRGsWvYUqukEpO4iHe54Iy6FARt2rbe+21PF1dP11yWUYI9PgkpYzf3LyEUEtPPbk1HE0lg8+9jkiXS66HSwkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p9iT8CMYN0OSiIE5lUo+LvmN+xjlrzAOuwCRvnf8bpmduuSUlgfvhE8FBmm4+8jZH38fdHQPY/7m+h+fasq8CU5kAdVWSFkcVU/Or88yt0S8dME9r67S2jZ/7TAKwyEUB6BTrh2f0nlWU24qd0yVKvGOgJU31/33YSIXVYyhv70= Received: by 10.78.186.9 with SMTP id j9mr2425142huf.1190017761621; Mon, 17 Sep 2007 01:29:21 -0700 (PDT) Received: by 10.78.100.2 with HTTP; Mon, 17 Sep 2007 01:29:21 -0700 (PDT) Message-ID: Date: Mon, 17 Sep 2007 10:29:21 +0200 From: "=?UTF-8?Q?Petr_Hroudn=C3=BD?=" To: "Andrey Chernov" , current@freebsd.org, i18n@freebsd.org, perky@freebsd.org, petr.hroudny@gmail.com In-Reply-To: <20070916192924.GA12678@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070916192924.GA12678@nagual.pp.ru> X-Mailman-Approved-At: Mon, 17 Sep 2007 12:02:39 +0000 Cc: Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 08:56:38 -0000 2007/9/16, Andrey Chernov : > The problem is: currently our single byte ctype functions are broken for > wide characters locales in the argument range >= 0x80 - they may return > false positives. > > For example, for UTF-8 locale we currently have: > iswspace(0xA0)==1 and isspace(0xA0)==1 > (because iswspace() and isspace() are the same code) > but must have > isspace(0xA0)==0 This is exactly what happens on other OSes and I agree this is the right behaviour for UTF-8. However, we must ensure, that: for C locale: isspace(0xA0)==0 for ISO8859-* locales: isspace(0xA0)==1 for UTF-8 locales: isspace(0xA0)==0 Regards, Petr. From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 12:06:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EF1E16A41B for ; Mon, 17 Sep 2007 12:06:33 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from martenvijn.nl (vijn.xs4all.nl [194.109.254.102]) by mx1.freebsd.org (Postfix) with ESMTP id B785313C468 for ; Mon, 17 Sep 2007 12:06:32 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from [127.0.0.1] ([192.168.1.20]) by martenvijn.nl (8.13.8/8.13.4) with ESMTP id l8HBpBoZ077715 for ; Mon, 17 Sep 2007 13:51:17 +0200 (CEST) (envelope-from info@martenvijn.nl) From: Marten Vijn To: freebsd-current@freebsd.org Content-Type: text/plain Date: Mon, 17 Sep 2007 13:09:26 +0200 Message-Id: <1190027366.11265.12.camel@medion.martenvijn.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:41:43 by milter-greylist-3.0 (martenvijn.nl [192.168.1.2]); Mon, 17 Sep 2007 13:51:17 +0200 (CEST) Subject: crunchgen fials on sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 12:06:33 -0000 in current from Sat Aug 11 20:40:50 CEST 2007 (also cvsuped src tree today) in crunch.conf: progs sh libs -lc libs -ledit libs -lncurses libs -lutil # crunchgen -f crunch.conf # make -f crunch.mk error (complete output below): cc -static -o tinycrunch tinycrunch.o sh.lo -lc -ledit -lncurses -lutil sh.lo(.text+0x1ea0): In function `yylex': : undefined reference to `yywrap' *** Error code 1 Stop in /tmp/obj. I have grepped /usr/src/bin/ for yy but did not find something usefull. did a make clean is this directory which did not solvethe issue. Any pointers who I can fix this are apprciated, kind regards, Marten unname -a medion# uname -a FreeBSD medion.martenvijn.nl 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sat Aug 11 20:40:50 CEST 2007 root@medion.martenvijn.nl:/usr/obj/usr/src/sys/MED i386 conplete output: (cd /usr/src/bin/sh && make depend && make alias.o arith.o arith_lex.o cd.o echo.o error.o eval.o exec.o expand.o histedit.o input.o jobs.o mail.o main.o memalloc.o miscbltin.o mystring.o options.o output.o parser.o redir.o show.o test.o trap.o var.o builtins.o init.o nodes.o syntax.o) `alias.o' is up to date. `arith.o' is up to date. `arith_lex.o' is up to date. `cd.o' is up to date. `echo.o' is up to date. `error.o' is up to date. `eval.o' is up to date. `exec.o' is up to date. `expand.o' is up to date. `histedit.o' is up to date. `input.o' is up to date. `jobs.o' is up to date. `mail.o' is up to date. `main.o' is up to date. `memalloc.o' is up to date. `miscbltin.o' is up to date. `mystring.o' is up to date. `options.o' is up to date. `output.o' is up to date. `parser.o' is up to date. `redir.o' is up to date. `show.o' is up to date. `test.o' is up to date. `trap.o' is up to date. `var.o' is up to date. `builtins.o' is up to date. `init.o' is up to date. `nodes.o' is up to date. `syntax.o' is up to date. cc -O1 -pipe -c tinycrunch.c tinycrunch.c: In function 'crunched_usage': tinycrunch.c:117: warning: incompatible implicit declaration of built-in function 'exit' cc -static -o tinycrunch tinycrunch.o sh.lo -lc -ledit -lncurses -lutil sh.lo(.text+0x1ea0): In function `yylex': : undefined reference to `yywrap' *** Error code 1 Stop in /tmp/obj. # uname -a FreeBSD medion.martenvijn.nl 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sat Aug 11 20:40:50 CEST 2007 root@medion.martenvijn.nl:/usr/obj/usr/src/sys/MED i386 medion# dmesg Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #2: Sat Aug 11 20:40:50 CEST 2007 root@medion.martenvijn.nl:/usr/obj/usr/src/sys/MED ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz (3059.21-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 Logical CPUs per core: 2 real memory = 536281088 (511 MB) avail memory = 506593280 (483 MB) 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) 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 cpu0: on acpi0 acpi_perf0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 acpi_button0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xd1000000-0xd1ffffff,0xe0000000-0xefffffff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] uhci0: port 0x1cc0-0x1cdf irq 16 at device 29.0 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 uhci1: port 0x1ce0-0x1cff irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2000-0x201f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2020-0x203f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd0000000-0xd00003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib2: at device 30.0 on pci0 pci3: on pcib2 cbb0: at device 4.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] cbb1: at device 4.1 on pci3 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [ITHREAD] pci3: at device 4.2 (no driver attached) pci3: at device 4.3 (no driver attached) rl0: port 0x3000-0x30ff mem 0xd2015800-0xd20158ff irq 19 at device 5.0 on pci3 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:0a:e4:55:3b:8f rl0: [ITHREAD] ath0: mem 0xd2000000-0xd200ffff irq 18 at device 6.0 on pci3 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0b:6b:34:55:41 ath0: mac 5.9 phy 4.3 radio 3.6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2060-0x206f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pcm0: port 0x1400-0x14ff,0x1c80-0x1cbf mem 0xd0000c00-0xd0000dff,0xd0000800-0xd00008ff irq 17 at device 31.5 on pci0 pcm0: [ITHREAD] pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 acpi_button1: 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 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1 port 0x2f8-0x2ff irq 3 drq 3 on acpi0 sio1: type 16550A sio1: [FILTER] battery0: on acpi0 acpi_acad0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd0fff,0xdc000-0xdffff 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 ppc0: parallel port not found. Timecounters tick every 1.000 msec ad0: 76319MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s2a rl0: link state changed to UP WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() pid 1025 (gnome-screensaver), uid 1001: exited on signal 6 From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 15:10:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4154716A419 for ; Mon, 17 Sep 2007 15:10:47 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id EC6AC13C467 for ; Mon, 17 Sep 2007 15:10:46 +0000 (UTC) (envelope-from marinosi@diogenis.ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id A3580EB4AA6; Mon, 17 Sep 2007 18:10:22 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 2BC6B159073; Mon, 17 Sep 2007 18:10:22 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hndu7-AiLPVE; Mon, 17 Sep 2007 18:10:22 +0300 (EEST) Received: from diogenis.ceid.upatras.gr (unknown [10.1.0.181]) by mail.ceid.upatras.gr (Postfix) with ESMTP id EE867159031; Mon, 17 Sep 2007 18:10:21 +0300 (EEST) Received: by diogenis.ceid.upatras.gr (Postfix, from userid 3149) id 6CC4C8FF4E; Mon, 17 Sep 2007 18:10:21 +0300 (EEST) Date: Mon, 17 Sep 2007 18:10:20 +0300 From: Marinos Ilias To: info@martenvijn.nl Message-ID: <20070917151020.GA23939@ceid.upatras.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: crunchgen fials on sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 15:10:47 -0000 You may just need to link with flex library. ( -lfl for gcc). For your case , try to add libs -lfl in your crunch.conf. Hope that does the job for you, Ilias Marinos From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 15:45:54 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C2F516A476 for ; Mon, 17 Sep 2007 15:45:54 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id D9DF113C47E for ; Mon, 17 Sep 2007 15:45:53 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l8HFjpPk091798; Mon, 17 Sep 2007 19:45:51 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 17 Sep 2007 19:45:51 +0400 (MSD) From: Dmitry Morozovsky To: current@FreeBSD.org Message-ID: <20070917194009.W84177@woozle.rinet.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Mon, 17 Sep 2007 19:45:52 +0400 (MSD) Cc: delphij@FreeBSD.org Subject: tmpfs on contemporary -current: panic: locked against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 15:45:54 -0000 Dear colleagues, on contemporary HEAD/i386, ports tinderbox on tmpfs I got panic: lockmgr: locking against myself cpuid = 0 KDB: enter: panic [thread pid 17317 tid 100062 ] Stopped at kdb_enter+0x32: leave db> ps 17317 pid ppid pgrp uid state wmesg wchan cmd 17317 17275 990 0 R+ CPU 0 sh 17316 17275 990 0 SE+ tmpfs 0xcca5e388 grep 17275 17219 990 0 S+ wait 0xcd77a558 sh 17220 17218 990 0 S+ nanslp 0xc0705ea4 pnohang 17219 17218 990 0 S+ wait 0xcd0f6000 make 17218 5809 990 0 S+ wait 0xcd77e2ac pnohang 5809 5077 990 0 S+ wait 0xc9eb6000 sh 5077 5076 990 0 S+ wait 0xcd77e804 sh 5076 13601 990 0 S+ wait 0xcd16d804 sh 62811 60266 62811 268 Ss piperd 0xc95aa630 sendmail 60268 60267 60267 268 S select 0xc070bf78 cvsup 60267 60266 60267 268 Ss wait 0xc6c95ab0 sh 60266 720 720 0 S piperd 0xce1f718c cron 41708 41406 41708 268 S+ pause 0xc6c9630c screen 41406 41405 41406 268 Ss+ pause 0xc6c105b8 tcsh 41405 41389 41389 268 S select 0xc070bf78 sshd 41389 702 41389 0 Ss sbwait 0xcb9b7560 sshd 47447 911 47447 268 S+ select 0xc070bf78 boinc_curses 86227 86226 54003 1001 S+ nanslp 0xc0705ea4 wcg_hpf2_rosetta_5. 86226 86225 54003 1001 S+ select 0xc070bf78 wcg_hpf2_rosetta_5. 86225 54003 54003 1001 R+ CPU 1 wcg_hpf2_rosetta_5. 86224 86223 54003 1001 S+ nanslp 0xc0705ea4 wcg_hpf2_rosetta_5. 86223 86222 54003 1001 S+ select 0xc070bf78 wcg_hpf2_rosetta_5. 86222 54003 54003 1001 R+ wcg_hpf2_rosetta_5. 54003 7364 54003 1001 S+ select 0xc070bf78 boinc 7364 92713 7364 1001 S+ pause 0xcc3b730c tcsh 92713 790 92713 268 Ss+ pause 0xc6c0c30c tcsh 71602 1 71602 0 Ss+ ttyin 0xc69e3c10 getty 10819 7980 10819 0 S+ ttyin 0xc69ca410 tcsh 7980 790 7980 268 Ss+ pause 0xcaa8eb10 tcsh 75146 75140 75146 268 Ss+ ttyin 0xc68af410 tcsh 75140 75096 75096 268 S select 0xc070bf78 sshd 75096 702 75096 0 Ss sbwait 0xcaaccea8 sshd 72145 860 72145 0 S+ kqread 0xc94cfa80 tail 13601 990 990 0 S+ select 0xc070bf78 make 12321 932 12321 268 S+ select 0xc070bf78 top 990 860 990 0 S+ wait 0xc6e7a2ac sh 976 962 976 0 S+ ttyin 0xc6999810 tcsh 962 790 962 268 Ss+ pause 0xc6c11b10 tcsh db> bt 17317 Tracing pid 17317 tid 100062 td 0xc6c12600 kdb_enter(c06a421c,0,c06a2861,e95739cc,0,...) at kdb_enter+0x32 panic(c06a2861,e95739dc,c05845e7,e9573ac0,cca5e330,...) at panic+0x124 _lockmgr(cca5e388,3002,cca5e3b8,c6c12600,c06aa49a,...) at _lockmgr+0x401 vop_stdlock(e9573a5c,c6c12600,3002,cca5e330,e9573a80,...) at vop_stdlock+0x40 VOP_LOCK1_APV(c70ccb20,e9573a5c,e9573bc0,0,c72e1770,...) at VOP_LOCK1_APV+0x46 _vn_lock(cca5e330,3002,c6c12600,c06aa49a,7f3,...) at _vn_lock+0x166 vget(cca5e330,1000,c6c12600,0,c6c12600,...) at vget+0x114 vm_object_reference(ca97d780,e9573b30,c067238d,c1071000,e3ce6000,...) at vm_object_reference+0x12a kern_execve(c6c12600,e9573c5c,0,8068ce0,8068dd8,e3ce6000,e3ce6000,e3ce6024,e3ce6549,e3d26000,3fab7,4,39) at kern_execve+0x312 execve(c6c12600,e9573cfc,c,c6c12600,e9573d2c,...) at execve+0x4c syscall(e9573d38) at syscall+0x345 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (59, FreeBSD ELF32, execve), eip = 0x8813d4df, esp = 0xbfbfda8c, ebp = 0xbfbfdab8 --- db> show lockedvnods Locked vnodes 0xcca5e330: tag tmpfs, type VREG usecount 1, writecount 0, refcount 4 mountedhere 0 flags (VI_OWEINACT) v_object 0xca97d780 ref 1 pages 18 lock type tmpfs: EXCL (count 1) by thread 0xc6c12600 (pid 17317) with 1 pending tag VT_TMPFS, tmpfs_node 0xcb0d2094, flags 0x0, links 9 mode 0555, owner 0, group 0, size 73800, status 0x0 db> I saved panic core, so I hope I can answer additional questions... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 16:12:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D8A016A41B for ; Mon, 17 Sep 2007 16:12:34 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.freebsd.org (Postfix) with ESMTP id EDCE313C45E for ; Mon, 17 Sep 2007 16:12:33 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1186539wxd for ; Mon, 17 Sep 2007 09:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=Qhd6eB/GL2LMRTG+RukBg2fBjMIO3L10dj6SlpfcWC8=; b=Hx3t43+n7iAEM1GslRTS6kSulkqKJmPWXMDs6mWI/kaALFC9oQU4Lc8D1DRUp4codGYVzkZxqRyzsaXPw7zZJAB7A02G/Y4Ibn8JDXw2PLeHPQBWb2h3pZGwC26EPeJCTSEMm3R3iDJaZGWsfjm8SbqCz9GC0VLhKDIcTDlGCKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=CT2a76rEfLEHJov0kpm2khK86v9zcQc12+LUXO0G9AuTGXpnz1L/3goeeocVR1mSfJv6RHk/PYnoCu3CjK7hbGnu8eIhOOY6k37k7T2OLBD4U8mfe5xtbmI+6G/jhAVIo/iqzZinWWBA6ycVidNtgf0/AgDRd2Q/wowb2Rqtmb0= Received: by 10.78.183.8 with SMTP id g8mr2789091huf.1190045551540; Mon, 17 Sep 2007 09:12:31 -0700 (PDT) Received: from orion ( [77.109.36.35]) by mx.google.com with ESMTPS id 10sm1930729hug.2007.09.17.09.12.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2007 09:12:30 -0700 (PDT) From: Nikolay Pavlov To: freebsd-current@freebsd.org Date: Mon, 17 Sep 2007 19:12:03 +0300 User-Agent: KMail/1.9.7 References: <20070917194009.W84177@woozle.rinet.ru> In-Reply-To: <20070917194009.W84177@woozle.rinet.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3222346.7Jdr1GAi7q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709171912.09060.qpadla@gmail.com> Cc: delphij@freebsd.org, Dmitry Morozovsky , current@freebsd.org Subject: Re: tmpfs on contemporary -current: panic: locked against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 16:12:34 -0000 --nextPart3222346.7Jdr1GAi7q Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 17 September 2007 18:45:51 Dmitry Morozovsky wrote: > Dear colleagues, > > on contemporary HEAD/i386, ports tinderbox on tmpfs I got > > panic: lockmgr: locking against myself > cpuid =3D 0 > KDB: enter: panic > [thread pid 17317 tid 100062 ] > Stopped at kdb_enter+0x32: leave > db> ps 17317 > pid ppid pgrp uid state wmesg wchan cmd > 17317 17275 990 0 R+ CPU 0 sh > 17316 17275 990 0 SE+ tmpfs 0xcca5e388 grep > 17275 17219 990 0 S+ wait 0xcd77a558 sh > 17220 17218 990 0 S+ nanslp 0xc0705ea4 pnohang > 17219 17218 990 0 S+ wait 0xcd0f6000 make > 17218 5809 990 0 S+ wait 0xcd77e2ac pnohang > 5809 5077 990 0 S+ wait 0xc9eb6000 sh > 5077 5076 990 0 S+ wait 0xcd77e804 sh > 5076 13601 990 0 S+ wait 0xcd16d804 sh > 62811 60266 62811 268 Ss piperd 0xc95aa630 sendmail > 60268 60267 60267 268 S select 0xc070bf78 cvsup > 60267 60266 60267 268 Ss wait 0xc6c95ab0 sh > 60266 720 720 0 S piperd 0xce1f718c cron > 41708 41406 41708 268 S+ pause 0xc6c9630c screen > 41406 41405 41406 268 Ss+ pause 0xc6c105b8 tcsh > 41405 41389 41389 268 S select 0xc070bf78 sshd > 41389 702 41389 0 Ss sbwait 0xcb9b7560 sshd > 47447 911 47447 268 S+ select 0xc070bf78 boinc_curses > 86227 86226 54003 1001 S+ nanslp 0xc0705ea4 wcg_hpf2_rosetta_5. > 86226 86225 54003 1001 S+ select 0xc070bf78 wcg_hpf2_rosetta_5. > 86225 54003 54003 1001 R+ CPU 1 wcg_hpf2_rosetta_5. > 86224 86223 54003 1001 S+ nanslp 0xc0705ea4 wcg_hpf2_rosetta_5. > 86223 86222 54003 1001 S+ select 0xc070bf78 wcg_hpf2_rosetta_5. > 86222 54003 54003 1001 R+ wcg_hpf2_rosetta_5. > 54003 7364 54003 1001 S+ select 0xc070bf78 boinc > 7364 92713 7364 1001 S+ pause 0xcc3b730c tcsh > 92713 790 92713 268 Ss+ pause 0xc6c0c30c tcsh > 71602 1 71602 0 Ss+ ttyin 0xc69e3c10 getty > 10819 7980 10819 0 S+ ttyin 0xc69ca410 tcsh > 7980 790 7980 268 Ss+ pause 0xcaa8eb10 tcsh > 75146 75140 75146 268 Ss+ ttyin 0xc68af410 tcsh > 75140 75096 75096 268 S select 0xc070bf78 sshd > 75096 702 75096 0 Ss sbwait 0xcaaccea8 sshd > 72145 860 72145 0 S+ kqread 0xc94cfa80 tail > 13601 990 990 0 S+ select 0xc070bf78 make > 12321 932 12321 268 S+ select 0xc070bf78 top > 990 860 990 0 S+ wait 0xc6e7a2ac sh > 976 962 976 0 S+ ttyin 0xc6999810 tcsh > 962 790 962 268 Ss+ pause 0xc6c11b10 tcsh > db> bt 17317 > Tracing pid 17317 tid 100062 td 0xc6c12600 > kdb_enter(c06a421c,0,c06a2861,e95739cc,0,...) at kdb_enter+0x32 > panic(c06a2861,e95739dc,c05845e7,e9573ac0,cca5e330,...) at panic+0x124 > _lockmgr(cca5e388,3002,cca5e3b8,c6c12600,c06aa49a,...) at _lockmgr+0x401 > vop_stdlock(e9573a5c,c6c12600,3002,cca5e330,e9573a80,...) at > vop_stdlock+0x40 > VOP_LOCK1_APV(c70ccb20,e9573a5c,e9573bc0,0,c72e1770,...) at > VOP_LOCK1_APV+0x46 _vn_lock(cca5e330,3002,c6c12600,c06aa49a,7f3,...) at > _vn_lock+0x166 vget(cca5e330,1000,c6c12600,0,c6c12600,...) at vget+0x114 > vm_object_reference(ca97d780,e9573b30,c067238d,c1071000,e3ce6000,...) at > vm_object_reference+0x12a > kern_execve(c6c12600,e9573c5c,0,8068ce0,8068dd8,e3ce6000,e3ce6000,e3ce60 >24,e3ce6549,e3d26000,3fab7,4,39) at kern_execve+0x312 > execve(c6c12600,e9573cfc,c,c6c12600,e9573d2c,...) at execve+0x4c > syscall(e9573d38) at syscall+0x345 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (59, FreeBSD ELF32, execve), eip =3D 0x8813d4df, esp =3D > 0xbfbfda8c, ebp =3D 0xbfbfdab8 --- > db> show lockedvnods > Locked vnodes > > 0xcca5e330: tag tmpfs, type VREG > usecount 1, writecount 0, refcount 4 mountedhere 0 > flags (VI_OWEINACT) > v_object 0xca97d780 ref 1 pages 18 > lock type tmpfs: EXCL (count 1) by thread 0xc6c12600 (pid 17317) > with 1 pending > tag VT_TMPFS, tmpfs_node 0xcb0d2094, flags 0x0, links 9 > mode 0555, owner 0, group 0, size 73800, status 0x0 > > db> > > I saved panic core, so I hope I can answer additional questions... > > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" Yes it's still need more fixes. I have send a mail to delphij regarding=20 this one panic:=20 http://docs.freebsd.org/cgi/mid.cgi?200708201848.22157.qpadla But with out any response. May be he is busy :( =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart3222346.7Jdr1GAi7q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG7qdZ/2R6KvEYGaIRAnJXAKCu03M2io0F6w5jPb8ktMIhSZsQ+gCdFN8A YV+Hq3LcjSzoBpFjGDNs6Ng= =orYD -----END PGP SIGNATURE----- --nextPart3222346.7Jdr1GAi7q-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 16:18:13 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 492DB16A41A; Mon, 17 Sep 2007 16:18:13 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 0336B13C465; Mon, 17 Sep 2007 16:18:12 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id EAA9BEB1187; Tue, 18 Sep 2007 00:18:11 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id M96xYQ-VsX+R; Tue, 18 Sep 2007 00:18:03 +0800 (CST) Received: from LI-Xins-MacBook.local (unknown [61.49.108.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 2D2C8EB109E; Tue, 18 Sep 2007 00:18:02 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=fhDxlsj8BQtHRa1tG+qXma1swZj/is1gOkh/oE4duXkhhJbmBZxt3Rj23PE+P1nMw a90sGu+2kA4DyleHAx8GQ== Message-ID: <46EEA89F.3060606@delphij.net> Date: Tue, 18 Sep 2007 00:17:35 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: qpadla@gmail.com References: <20070917194009.W84177@woozle.rinet.ru> <200709171912.09060.qpadla@gmail.com> In-Reply-To: <200709171912.09060.qpadla@gmail.com> X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig6B350494C2AD6E629B99B89C" Cc: MingyanGuo , current@freebsd.org, Dmitry Morozovsky , freebsd-current@freebsd.org, delphij@freebsd.org, Howard Su Subject: Re: tmpfs on contemporary -current: panic: locked against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 16:18:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6B350494C2AD6E629B99B89C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nikolay Pavlov wrote: [...] > Yes it's still need more fixes. I have send a mail to delphij regarding= =20 > this one panic:=20 > http://docs.freebsd.org/cgi/mid.cgi?200708201848.22157.qpadla > But with out any response. May be he is busy :( Sorry I am aware of the issue and am busy for $REALJOB these days. I have cc'ed howardsu@ and mingyanguo@ to see if they have some suggestions. The problem seems to be a race condition caused by incorrect VFS related locking, but diagnosing it is relatively hard. I'll try to pick up with the development in early October. Before that I can only do some small scale bugfixes rather than investing more time into tmpfs stuff... :-( Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig6B350494C2AD6E629B99B89C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG7qifOfuToMruuMARCqgzAJ92lkPtNZR9D8LrRoPXMWm2XXnAXQCfQ8mG Zn0BWM+HVoIeyOU7NFtdgU8= =8uaR -----END PGP SIGNATURE----- --------------enig6B350494C2AD6E629B99B89C-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 16:18:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 492DB16A41A; Mon, 17 Sep 2007 16:18:13 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 0336B13C465; Mon, 17 Sep 2007 16:18:12 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id EAA9BEB1187; Tue, 18 Sep 2007 00:18:11 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id M96xYQ-VsX+R; Tue, 18 Sep 2007 00:18:03 +0800 (CST) Received: from LI-Xins-MacBook.local (unknown [61.49.108.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 2D2C8EB109E; Tue, 18 Sep 2007 00:18:02 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=fhDxlsj8BQtHRa1tG+qXma1swZj/is1gOkh/oE4duXkhhJbmBZxt3Rj23PE+P1nMw a90sGu+2kA4DyleHAx8GQ== Message-ID: <46EEA89F.3060606@delphij.net> Date: Tue, 18 Sep 2007 00:17:35 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: qpadla@gmail.com References: <20070917194009.W84177@woozle.rinet.ru> <200709171912.09060.qpadla@gmail.com> In-Reply-To: <200709171912.09060.qpadla@gmail.com> X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig6B350494C2AD6E629B99B89C" Cc: MingyanGuo , current@freebsd.org, Dmitry Morozovsky , freebsd-current@freebsd.org, delphij@freebsd.org, Howard Su Subject: Re: tmpfs on contemporary -current: panic: locked against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 16:18:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6B350494C2AD6E629B99B89C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nikolay Pavlov wrote: [...] > Yes it's still need more fixes. I have send a mail to delphij regarding= =20 > this one panic:=20 > http://docs.freebsd.org/cgi/mid.cgi?200708201848.22157.qpadla > But with out any response. May be he is busy :( Sorry I am aware of the issue and am busy for $REALJOB these days. I have cc'ed howardsu@ and mingyanguo@ to see if they have some suggestions. The problem seems to be a race condition caused by incorrect VFS related locking, but diagnosing it is relatively hard. I'll try to pick up with the development in early October. Before that I can only do some small scale bugfixes rather than investing more time into tmpfs stuff... :-( Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig6B350494C2AD6E629B99B89C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG7qifOfuToMruuMARCqgzAJ92lkPtNZR9D8LrRoPXMWm2XXnAXQCfQ8mG Zn0BWM+HVoIeyOU7NFtdgU8= =8uaR -----END PGP SIGNATURE----- --------------enig6B350494C2AD6E629B99B89C-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 16:22:35 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CFF516A417 for ; Mon, 17 Sep 2007 16:22:35 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from viefep24-int.chello.at (viefep18-int.chello.at [213.46.255.22]) by mx1.freebsd.org (Postfix) with ESMTP id E33F913C468 for ; Mon, 17 Sep 2007 16:22:34 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from novel.renet.ru ([82.116.33.234]) by viefep24-int.chello.at (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20070917162232.WCEU22742.viefep24-int.chello.at@novel.renet.ru>; Mon, 17 Sep 2007 18:22:32 +0200 Date: Mon, 17 Sep 2007 20:24:00 +0400 From: Roman Bogorodskiy To: Jeff Roberson Message-ID: <20070917162400.GA42669@underworld.novel.ru> References: <20070916061932.GA93480@underworld.novel.ru> <20070915234855.G531@10.0.0.1> <20070916071421.GA1320@underworld.novel.ru> <20070916003323.U4507@10.0.0.1> <20070917044351.GA17565@underworld.novel.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20070917044351.GA17565@underworld.novel.ru> X-PGP: http://people.freebsd.org/~novel/novel.key.asc Cc: freebsd-current@FreeBSD.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 16:22:35 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Roman Bogorodskiy wrote: > Jeff Roberson wrote: >=20 > > On Sun, 16 Sep 2007, Roman Bogorodskiy wrote: > >=20 > >> Jeff Roberson wrote: > >>=20 > >>> This is contrary to the experiences of many others. Can you send me = your > >>> dmesg? There may be something about your particular hardware that is > >>> triggering a bug. ULE is definitely designed to be responsive on the > >>> desktop. > >>=20 > >> Thanks for the quick answer! > >>=20 > >> Here's my dmesg: http://people.freebsd.org/~novel/misc/dmesg.txt > >=20 > > Roman, > >=20 > > The enclosed patch helps things on my system, however, there are still = some=20 > > delays due to IO issues. Let me know if this helps. >=20 > This patch seems to make my system react faster. However I need some > time to test it more carefully. It looks like it's not really so, it's still very slow under load. :( =20 > > Thanks, > > Jeff > >=20 > >>=20 > >> Roman Bogorodskiy > >>=20 >=20 >=20 > Roman Bogorodskiy Roman Bogorodskiy --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQCVAwUBRu6qIIB0WzgdqspGAQIulQP/QeYKTJxwS4x6w1SNvGTzVtemrK/sO8kU E+Naj8wjWyYU1ua8UswR9ojGd2/+PQItlvWRxbDRHq4mYuBQa3ENlA1nOO8OYI4R aEDoU3WSFsHlccanQOaiV3EmUChH/tuteQpxIc/XOhqh/NTExCAA4RBU2yDI10Ds BSc5KSHShuQ= =ZDA9 -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 16:40:25 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B403E16A41A for ; Mon, 17 Sep 2007 16:40:25 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 2FE1E13C478 for ; Mon, 17 Sep 2007 16:40:25 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1179290nfb for ; Mon, 17 Sep 2007 09:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=Qhd6eB/GL2LMRTG+RukBg2fBjMIO3L10dj6SlpfcWC8=; b=Hx3t43+n7iAEM1GslRTS6kSulkqKJmPWXMDs6mWI/kaALFC9oQU4Lc8D1DRUp4codGYVzkZxqRyzsaXPw7zZJAB7A02G/Y4Ibn8JDXw2PLeHPQBWb2h3pZGwC26EPeJCTSEMm3R3iDJaZGWsfjm8SbqCz9GC0VLhKDIcTDlGCKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=CT2a76rEfLEHJov0kpm2khK86v9zcQc12+LUXO0G9AuTGXpnz1L/3goeeocVR1mSfJv6RHk/PYnoCu3CjK7hbGnu8eIhOOY6k37k7T2OLBD4U8mfe5xtbmI+6G/jhAVIo/iqzZinWWBA6ycVidNtgf0/AgDRd2Q/wowb2Rqtmb0= Received: by 10.78.183.8 with SMTP id g8mr2789091huf.1190045551540; Mon, 17 Sep 2007 09:12:31 -0700 (PDT) Received: from orion ( [77.109.36.35]) by mx.google.com with ESMTPS id 10sm1930729hug.2007.09.17.09.12.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2007 09:12:30 -0700 (PDT) From: Nikolay Pavlov To: freebsd-current@freebsd.org Date: Mon, 17 Sep 2007 19:12:03 +0300 User-Agent: KMail/1.9.7 References: <20070917194009.W84177@woozle.rinet.ru> In-Reply-To: <20070917194009.W84177@woozle.rinet.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3222346.7Jdr1GAi7q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709171912.09060.qpadla@gmail.com> Cc: delphij@freebsd.org, Dmitry Morozovsky , current@freebsd.org Subject: Re: tmpfs on contemporary -current: panic: locked against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 16:40:25 -0000 --nextPart3222346.7Jdr1GAi7q Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 17 September 2007 18:45:51 Dmitry Morozovsky wrote: > Dear colleagues, > > on contemporary HEAD/i386, ports tinderbox on tmpfs I got > > panic: lockmgr: locking against myself > cpuid =3D 0 > KDB: enter: panic > [thread pid 17317 tid 100062 ] > Stopped at kdb_enter+0x32: leave > db> ps 17317 > pid ppid pgrp uid state wmesg wchan cmd > 17317 17275 990 0 R+ CPU 0 sh > 17316 17275 990 0 SE+ tmpfs 0xcca5e388 grep > 17275 17219 990 0 S+ wait 0xcd77a558 sh > 17220 17218 990 0 S+ nanslp 0xc0705ea4 pnohang > 17219 17218 990 0 S+ wait 0xcd0f6000 make > 17218 5809 990 0 S+ wait 0xcd77e2ac pnohang > 5809 5077 990 0 S+ wait 0xc9eb6000 sh > 5077 5076 990 0 S+ wait 0xcd77e804 sh > 5076 13601 990 0 S+ wait 0xcd16d804 sh > 62811 60266 62811 268 Ss piperd 0xc95aa630 sendmail > 60268 60267 60267 268 S select 0xc070bf78 cvsup > 60267 60266 60267 268 Ss wait 0xc6c95ab0 sh > 60266 720 720 0 S piperd 0xce1f718c cron > 41708 41406 41708 268 S+ pause 0xc6c9630c screen > 41406 41405 41406 268 Ss+ pause 0xc6c105b8 tcsh > 41405 41389 41389 268 S select 0xc070bf78 sshd > 41389 702 41389 0 Ss sbwait 0xcb9b7560 sshd > 47447 911 47447 268 S+ select 0xc070bf78 boinc_curses > 86227 86226 54003 1001 S+ nanslp 0xc0705ea4 wcg_hpf2_rosetta_5. > 86226 86225 54003 1001 S+ select 0xc070bf78 wcg_hpf2_rosetta_5. > 86225 54003 54003 1001 R+ CPU 1 wcg_hpf2_rosetta_5. > 86224 86223 54003 1001 S+ nanslp 0xc0705ea4 wcg_hpf2_rosetta_5. > 86223 86222 54003 1001 S+ select 0xc070bf78 wcg_hpf2_rosetta_5. > 86222 54003 54003 1001 R+ wcg_hpf2_rosetta_5. > 54003 7364 54003 1001 S+ select 0xc070bf78 boinc > 7364 92713 7364 1001 S+ pause 0xcc3b730c tcsh > 92713 790 92713 268 Ss+ pause 0xc6c0c30c tcsh > 71602 1 71602 0 Ss+ ttyin 0xc69e3c10 getty > 10819 7980 10819 0 S+ ttyin 0xc69ca410 tcsh > 7980 790 7980 268 Ss+ pause 0xcaa8eb10 tcsh > 75146 75140 75146 268 Ss+ ttyin 0xc68af410 tcsh > 75140 75096 75096 268 S select 0xc070bf78 sshd > 75096 702 75096 0 Ss sbwait 0xcaaccea8 sshd > 72145 860 72145 0 S+ kqread 0xc94cfa80 tail > 13601 990 990 0 S+ select 0xc070bf78 make > 12321 932 12321 268 S+ select 0xc070bf78 top > 990 860 990 0 S+ wait 0xc6e7a2ac sh > 976 962 976 0 S+ ttyin 0xc6999810 tcsh > 962 790 962 268 Ss+ pause 0xc6c11b10 tcsh > db> bt 17317 > Tracing pid 17317 tid 100062 td 0xc6c12600 > kdb_enter(c06a421c,0,c06a2861,e95739cc,0,...) at kdb_enter+0x32 > panic(c06a2861,e95739dc,c05845e7,e9573ac0,cca5e330,...) at panic+0x124 > _lockmgr(cca5e388,3002,cca5e3b8,c6c12600,c06aa49a,...) at _lockmgr+0x401 > vop_stdlock(e9573a5c,c6c12600,3002,cca5e330,e9573a80,...) at > vop_stdlock+0x40 > VOP_LOCK1_APV(c70ccb20,e9573a5c,e9573bc0,0,c72e1770,...) at > VOP_LOCK1_APV+0x46 _vn_lock(cca5e330,3002,c6c12600,c06aa49a,7f3,...) at > _vn_lock+0x166 vget(cca5e330,1000,c6c12600,0,c6c12600,...) at vget+0x114 > vm_object_reference(ca97d780,e9573b30,c067238d,c1071000,e3ce6000,...) at > vm_object_reference+0x12a > kern_execve(c6c12600,e9573c5c,0,8068ce0,8068dd8,e3ce6000,e3ce6000,e3ce60 >24,e3ce6549,e3d26000,3fab7,4,39) at kern_execve+0x312 > execve(c6c12600,e9573cfc,c,c6c12600,e9573d2c,...) at execve+0x4c > syscall(e9573d38) at syscall+0x345 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (59, FreeBSD ELF32, execve), eip =3D 0x8813d4df, esp =3D > 0xbfbfda8c, ebp =3D 0xbfbfdab8 --- > db> show lockedvnods > Locked vnodes > > 0xcca5e330: tag tmpfs, type VREG > usecount 1, writecount 0, refcount 4 mountedhere 0 > flags (VI_OWEINACT) > v_object 0xca97d780 ref 1 pages 18 > lock type tmpfs: EXCL (count 1) by thread 0xc6c12600 (pid 17317) > with 1 pending > tag VT_TMPFS, tmpfs_node 0xcb0d2094, flags 0x0, links 9 > mode 0555, owner 0, group 0, size 73800, status 0x0 > > db> > > I saved panic core, so I hope I can answer additional questions... > > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" Yes it's still need more fixes. I have send a mail to delphij regarding=20 this one panic:=20 http://docs.freebsd.org/cgi/mid.cgi?200708201848.22157.qpadla But with out any response. May be he is busy :( =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart3222346.7Jdr1GAi7q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG7qdZ/2R6KvEYGaIRAnJXAKCu03M2io0F6w5jPb8ktMIhSZsQ+gCdFN8A YV+Hq3LcjSzoBpFjGDNs6Ng= =orYD -----END PGP SIGNATURE----- --nextPart3222346.7Jdr1GAi7q-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 17:01:09 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3331216A417; Mon, 17 Sep 2007 17:01:09 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id DE1EA13C481; Mon, 17 Sep 2007 17:01:08 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id AFFCB10749; Tue, 18 Sep 2007 02:01:07 +0900 (JST) Received: from basalt.tackymt.homeip.net ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24382-07; Tue, 18 Sep 2007 02:01:03 +0900 (JST) Received: from biotite (biotite.tackymt.homeip.net [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTP; Tue, 18 Sep 2007 02:01:03 +0900 (JST) Date: Tue, 18 Sep 2007 02:01:00 +0900 From: "YAMAMOTO, Taku" To: Andrey Chernov Message-Id: <20070918020100.d43beb0b.taku@tackymt.homeip.net> In-Reply-To: <20070917092130.GA24424@nagual.pp.ru> References: <20070916192924.GA12678@nagual.pp.ru> <20070917092130.GA24424@nagual.pp.ru> Organization: Trans New Technology, Inc. X-Mailer: Sylpheed 2.4.4 (GTK+ 2.10.14; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at tackymt.homeip.net Cc: current@freebsd.org, i18n@freebsd.org, Petr Hroudn?? , perky@freebsd.org Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 17:01:09 -0000 On Mon, 17 Sep 2007 13:21:30 +0400 Andrey Chernov wrote: > On Mon, Sep 17, 2007 at 10:29:21AM +0200, Petr Hroudn?? wrote: > > 2007/9/16, Andrey Chernov : > > > The problem is: currently our single byte ctype functions are broken for > > > wide characters locales in the argument range >= 0x80 - they may return > > > false positives. > > > > > > For example, for UTF-8 locale we currently have: > > > iswspace(0xA0)==1 and isspace(0xA0)==1 > > > (because iswspace() and isspace() are the same code) > > > but must have > > > isspace(0xA0)==0 > > > > This is exactly what happens on other OSes and I agree this is the > > right behaviour > > for UTF-8. However, we must ensure, that: > > > > for C locale: isspace(0xA0)==0 > > for ISO8859-* locales: isspace(0xA0)==1 > > for UTF-8 locales: isspace(0xA0)==0 > > The patch test for wide char locale presence first (__mb_cur_max > 1), so > does not affect single byte locales like ISO8859-* > Checking for __mb_cur_max is not enough for certain locales. For example, SJIS has following range for JIS X0201 (a.k.a. HALFWIDTH KANA). /* * JIS X201 */ PUNCT 0xa1-0xa5 SPACE 0xa0 BLANK 0xa0 SPECIAL 0xa1-0xdf PHONOGRAM 0xa6-0xdf SWIDTH1 0xa0-0xdf -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 17:16:37 2007 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EEC116A417; Mon, 17 Sep 2007 17:16:37 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 0E43413C4A6; Mon, 17 Sep 2007 17:16:36 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l8HHGZXW031324; Mon, 17 Sep 2007 21:16:35 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1190049395; bh=iQfeje9qqF9lbolnz9WqglI0kxZFvHAVG/cL99q 34hg=; l=584; h=Date:From:To:Cc:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent; b=Oz4ClMR4KQGKp8VsvHt6oWON8XlC1myBw0ZDcdXA DCj8z7Fg1BYFZ6tmf2zbw9dYwaNxSXm6xhvm6VPQQKFeKziNfg9/XniR5Vfv1ysTYq2 Ti9snEedii45dytDbDA3VwuMNNvpl3sYmAx+Sh4luxGNBNcurgpV8fMAAnkbnk1Q= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l8HHGXFn031323; Mon, 17 Sep 2007 21:16:34 +0400 (MSD) (envelope-from ache) Date: Mon, 17 Sep 2007 21:16:33 +0400 From: Andrey Chernov To: "YAMAMOTO, Taku" Message-ID: <20070917171633.GA31179@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , "YAMAMOTO, Taku" , current@FreeBSD.ORG, i18n@FreeBSD.ORG, Petr Hroudn?? , perky@FreeBSD.ORG References: <20070916192924.GA12678@nagual.pp.ru> <20070917092130.GA24424@nagual.pp.ru> <20070918020100.d43beb0b.taku@tackymt.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070918020100.d43beb0b.taku@tackymt.homeip.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Petr Hroudn?? , current@FreeBSD.ORG, perky@FreeBSD.ORG, i18n@FreeBSD.ORG Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 17:16:37 -0000 On Tue, Sep 18, 2007 at 02:01:00AM +0900, YAMAMOTO, Taku wrote: > Checking for __mb_cur_max is not enough for certain locales. > For example, SJIS has following range for JIS X0201 (a.k.a. HALFWIDTH KANA). > > /* > * JIS X201 > */ > PUNCT 0xa1-0xa5 > SPACE 0xa0 > BLANK 0xa0 > SPECIAL 0xa1-0xdf > PHONOGRAM 0xa6-0xdf > SWIDTH1 0xa0-0xdf I don't understand your remark. MSKanji have __mb_cur_max = 2 and so those ranges are wchar_t ranges. My patch restrict unsigned char ranges only. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 18:13:57 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A12FE16A418 for ; Mon, 17 Sep 2007 18:13:57 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6EEF613C494 for ; Mon, 17 Sep 2007 18:13:57 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from admin.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IXL6a-000FPV-Dj for freebsd-current@FreeBSD.org; Mon, 17 Sep 2007 22:13:56 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IXL7z-000Ae4-5h for freebsd-current@FreeBSD.org; Mon, 17 Sep 2007 22:15:23 +0400 To: freebsd-current@FreeBSD.org References: <96972293@srv.sem.ipt.ru> From: Boris Samorodov Date: Mon, 17 Sep 2007 22:15:23 +0400 In-Reply-To: <96972293@srv.sem.ipt.ru> (Boris Samorodov's message of "Mon\, 17 Sep 2007 11\:28\:58 +0400") Message-ID: <11217972@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: gmirror + dump = sbwait (was: twa + dump = sbwait) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 18:13:57 -0000 On Mon, 17 Sep 2007 11:28:58 +0400 Boris Samorodov wrote: > I can't use dump at -CURRENT with twa. The process goes to sbwait > state forever. Here are the details. The same is for gmirror (plain GENERIC but without WITNESS* and INVARIANT*): ----- $ df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mirror/gm0s1a 507630 387740 79280 83% / devfs 1 1 0 100% /dev /dev/mirror/gm0s1e 507630 16 467004 0% /tmp /dev/mirror/gm0s1f 20802680 4463056 14675410 23% /usr /dev/mirror/gm0s1d 9117774 53354 8335000 1% /var [...] $ dump -0Luan -f usr.dump /usr DUMP: Date of this level 0 dump: Mon Sep 17 21:58:24 2007 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/mirror/gm0s1f (/usr) to usr.dump DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 4485376 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] load: 0.03 cmd: dump 98789 [sbwait] 0.19u 0.44s 0% 2448k load: 0.01 cmd: dump 98791 [pause] 0.03u 1.00s 0% 2408k load: 0.00 cmd: dump 98789 [sbwait] 0.19u 0.44s 0% 2448k [waiting forever] % sockstat | grep duser duser dump 98792 5 stream -> ?? duser dump 98792 7 stream -> ?? duser dump 98792 9 stream -> ?? duser dump 98791 5 stream -> ?? duser dump 98791 7 stream -> ?? duser dump 98790 5 stream -> ?? duser dump 98789 5 stream -> ?? duser dump 98789 6 stream -> ?? duser dump 98789 7 stream -> ?? duser dump 98789 8 stream -> ?? duser dump 98789 9 stream -> ?? duser dump 98789 10 stream -> ?? Top: last pid: 98864; load averages: 0.00, 0.01, 0.03 up 1+21:27:20 22:06:20 86 processes: 1 running, 85 sleeping CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.9% idle Mem: 86M Active, 3331M Inact, 337M Wired, 468K Cache, 214M Buf, 3994M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 98792 duser 1 4 0 4696K 2424K sbwait 5 0:01 0.00% dump 98791 duser 1 20 0 4696K 2424K pause 6 0:01 0.00% dump 98790 duser 1 20 0 4696K 2424K pause 2 0:01 0.00% dump 98789 duser 1 4 0 4824K 2464K sbwait 6 0:01 0.00% dump 98786 duser 1 8 0 4696K 2424K wait 5 0:00 0.00% dump 78998 duser 1 8 0 6216K 1936K wait 6 0:00 0.00% sh ----- Need more details? Just ask! ;-) Thanks. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 18:51:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A679D16A417 for ; Mon, 17 Sep 2007 18:51:33 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 5A70013C45B for ; Mon, 17 Sep 2007 18:51:33 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.1]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 20:38:16 +0200 Message-ID: <46EEC9AB.2010805@dlr.de> Date: Mon, 17 Sep 2007 20:38:35 +0200 From: Hartmut Brandt Organization: German Aerospace Center User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Anders Magnusson References: <46EAA12D.4090207@ludd.ltu.se> In-Reply-To: <46EAA12D.4090207@ludd.ltu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2007 18:38:16.0905 (UTC) FILETIME=[E98C7390:01C7F959] Cc: freebsd-current@freebsd.org Subject: Re: Compiling with another compiler than gcc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 18:51:33 -0000 Anders Magnusson wrote: > It is not yet bug-free, but it can compile the i386 userspace. The big > benefit of it > (apart from that it's BSD licensed, for license geeks :-) is that it is > fast, 5-10 times > faster than gcc, while still producing reasonable code. The only When reading the name pcc my first thought was: isn't that the compiler that was distributed on later Unix V7 tapes? And yes, the web-page says it is based on that one. I'm quite sure that the original code had no BSD copyright, so I wonder how it obtained one? For the rewritten code there is no question, but what for the remaining original code? Has it been relicensed by the original author? It's interesting that the compiler is so much faster than gcc. I remember that it was around 3-5 times slower than the dmr compiler under V7. This tells a lot about gcc's speed :-( harti From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 18:55:09 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D70F16A494 for ; Mon, 17 Sep 2007 18:55:09 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id D825813C457 for ; Mon, 17 Sep 2007 18:55:08 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.68] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l8HII6jQ062463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2007 11:18:08 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <46EEC481.5010503@FreeBSD.org> Date: Mon, 17 Sep 2007 11:16:33 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dmitry Morozovsky References: <20070914124630.D14000@woozle.rinet.ru> In-Reply-To: <20070914124630.D14000@woozle.rinet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: i386 package building on an amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 18:55:09 -0000 Dmitry Morozovsky wrote: > Hi there colleagues, > > possibly stupid question: it there a way to fool jail (real, not "tinderbox" > one) that it's working under i386 kernel? This would be extremely useful for > local package building. > > Quick googling does not reveal anything, or did I miss something obvious? > > Thanks in advance. Works here like a charm. The only thing is that you need to set UNAME_p=i386 UNAME_m=i386 and CPUTYPE=i686 variables in the chroot/jail. -Maxim From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 20:29:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46F4B16A417 for ; Mon, 17 Sep 2007 20:29:50 +0000 (UTC) (envelope-from ragge@ludd.ltu.se) Received: from samson.dc.luth.se (samson.dc.ltu.se [130.240.112.30]) by mx1.freebsd.org (Postfix) with ESMTP id CF7EC13C458 for ; Mon, 17 Sep 2007 20:29:49 +0000 (UTC) (envelope-from ragge@ludd.ltu.se) Received: from localhost (ragge@localhost [127.0.0.1]) by samson.dc.luth.se (8.12.5/8.12.5) with SMTP id l8HKEMS4002706; Mon, 17 Sep 2007 22:14:23 +0200 (MET DST) X-Authentication-Warning: samson.dc.luth.se: ragge@localhost [127.0.0.1] didn't use HELO protocol Message-ID: <46EEE02F.10409@ludd.ltu.se> Date: Mon, 17 Sep 2007 22:14:39 +0200 From: Anders Magnusson User-Agent: Mail/News 1.5.0.9 (X11/20070124) MIME-Version: 1.0 To: Hartmut Brandt References: <46EAA12D.4090207@ludd.ltu.se> <46EEC9AB.2010805@dlr.de> In-Reply-To: <46EEC9AB.2010805@dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Compiling with another compiler than gcc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 20:29:50 -0000 Hi, Hartmut Brandt wrote: > Anders Magnusson wrote: >> It is not yet bug-free, but it can compile the i386 userspace. The >> big benefit of it >> (apart from that it's BSD licensed, for license geeks :-) is that it >> is fast, 5-10 times >> faster than gcc, while still producing reasonable code. The only > > When reading the name pcc my first thought was: isn't that the > compiler that was distributed on later Unix V7 tapes? And yes, the > web-page says it is based on that one. I'm quite sure that the > original code had no BSD copyright, so I wonder how it obtained one? > For the rewritten code there is no question, but what for the > remaining original code? Has it been relicensed by the original author? Caldera released it with BSD license some 6 years ago, as part of their "ancient unix". > It's interesting that the compiler is so much faster than gcc. I > remember that it was around 3-5 times slower than the dmr compiler > under V7. This tells a lot about gcc's speed :-( > Yes, and you are remembering correct. And yes, it says something about gcc. Even more interesting is that there are lots of quite slow sanity check code in pcc, despite that it's really fast. -- Ragge From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 21:12:43 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF59C16A417 for ; Mon, 17 Sep 2007 21:12:43 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 665F313C442 for ; Mon, 17 Sep 2007 21:12:43 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8HLCexi034895 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Sep 2007 17:12:42 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 17 Sep 2007 14:15:36 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: current@freebsd.org Message-ID: <20070917141407.B558@10.0.0.1> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1681148293-1190063736=:558" Cc: Subject: Fix ULE swapping. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 21:12:43 -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. --0-1681148293-1190063736=:558 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed The enclosed patch changes the way the kernel detects how long as thread has been swapped out or sleeping so that it is more compatible with ULE. For those of you who have run into swapping problems with ULE leading to poor interactivity, please test and report back your findings. Thanks, Jeff --0-1681148293-1190063736=:558 Content-Type: TEXT/x-diff; charset=US-ASCII; name=swap2.diff Content-Transfer-Encoding: BASE64 Content-ID: <20070917141536.M558@10.0.0.1> Content-Description: Content-Disposition: attachment; filename=swap2.diff SW5kZXg6IGxpYi9saWJrdm0va3ZtX3Byb2MuYw0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL2xpYi9saWJrdm0v a3ZtX3Byb2MuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuOTMNCmRpZmYg LXUgLXAgLXIxLjkzIGt2bV9wcm9jLmMNCi0tLSBsaWIvbGlia3ZtL2t2bV9w cm9jLmMJMTcgU2VwIDIwMDcgMDU6Mjc6MTggLTAwMDAJMS45Mw0KKysrIGxp Yi9saWJrdm0va3ZtX3Byb2MuYwkxNyBTZXAgMjAwNyAwNTo1ODowOSAtMDAw MA0KQEAgLTg1LDYgKzg1LDkgQEAgX19GQlNESUQoIiRGcmVlQlNEOiBzcmMv bGliL2xpYmt2bS9rdm1fcA0KICNkZWZpbmUgS1JFQUQoa2QsIGFkZHIsIG9i aikgXA0KIAkoa3ZtX3JlYWQoa2QsIGFkZHIsIChjaGFyICopKG9iaiksIHNp emVvZigqb2JqKSkgIT0gc2l6ZW9mKCpvYmopKQ0KIA0KK2ludCB0aWNrczsN CitpbnQgaHo7DQorDQogLyoNCiAgKiBSZWFkIHByb2MncyBmcm9tIG1lbW9y eSBmaWxlIGludG8gYnVmZmVyIGJwLCB3aGljaCBoYXMgc3BhY2UgdG8gaG9s ZA0KICAqIGF0IG1vc3QgbWF4Y250IHByb2NzLg0KQEAgLTM2OCw3ICszNzEs NyBAQCBub3BncnA6DQogCQlrcC0+a2lfYWNmbGFnID0gcHJvYy5wX2FjZmxh ZzsNCiAJCWtwLT5raV9sb2NrID0gcHJvYy5wX2xvY2s7DQogCQlpZiAocHJv Yy5wX3N0YXRlICE9IFBSU19aT01CSUUpIHsNCi0JCQlrcC0+a2lfc3d0aW1l ID0gcHJvYy5wX3N3dGltZTsNCisJCQlrcC0+a2lfc3d0aW1lID0gKHRpY2tz IC0gcHJvYy5wX3N3dGljaykgLyBoejsNCiAJCQlrcC0+a2lfZmxhZyA9IHBy b2MucF9mbGFnOw0KIAkJCWtwLT5raV9zZmxhZyA9IDA7DQogCQkJa3AtPmtp X25pY2UgPSBwcm9jLnBfbmljZTsNCkBAIC01MzUsMTIgKzUzOCwxNCBAQCBr dm1fZ2V0cHJvY3Moa2QsIG9wLCBhcmcsIGNudCkNCiBsaXZlb3V0Og0KIAkJ bnByb2NzID0gc2l6ZSA9PSAwID8gMCA6IHNpemUgLyBrZC0+cHJvY2Jhc2Ut PmtpX3N0cnVjdHNpemU7DQogCX0gZWxzZSB7DQotCQlzdHJ1Y3Qgbmxpc3Qg bmxbNF0sICpwOw0KKwkJc3RydWN0IG5saXN0IG5sWzZdLCAqcDsNCiANCiAJ CW5sWzBdLm5fbmFtZSA9ICJfbnByb2NzIjsNCiAJCW5sWzFdLm5fbmFtZSA9 ICJfYWxscHJvYyI7DQogCQlubFsyXS5uX25hbWUgPSAiX3pvbWJwcm9jIjsN Ci0JCW5sWzNdLm5fbmFtZSA9IDA7DQorCQlubFszXS5uX25hbWUgPSAiX3Rp Y2tzIjsNCisJCW5sWzRdLm5fbmFtZSA9ICJfaHoiOw0KKwkJbmxbNV0ubl9u YW1lID0gMDsNCiANCiAJCWlmIChrdm1fbmxpc3Qoa2QsIG5sKSAhPSAwKSB7 DQogCQkJZm9yIChwID0gbmw7IHAtPm5fdHlwZSAhPSAwOyArK3ApDQpAQCAt NTUzLDYgKzU1OCwxNCBAQCBsaXZlb3V0Og0KIAkJCV9rdm1fZXJyKGtkLCBr ZC0+cHJvZ3JhbSwgImNhbid0IHJlYWQgbnByb2NzIik7DQogCQkJcmV0dXJu ICgwKTsNCiAJCX0NCisJCWlmIChLUkVBRChrZCwgbmxbM10ubl92YWx1ZSwg JnRpY2tzKSkgew0KKwkJCV9rdm1fZXJyKGtkLCBrZC0+cHJvZ3JhbSwgImNh bid0IHJlYWQgdGlja3MiKTsNCisJCQlyZXR1cm4gKDApOw0KKwkJfQ0KKwkJ aWYgKEtSRUFEKGtkLCBubFs0XS5uX3ZhbHVlLCAmaHopKSB7DQorCQkJX2t2 bV9lcnIoa2QsIGtkLT5wcm9ncmFtLCAiY2FuJ3QgcmVhZCBoeiIpOw0KKwkJ CXJldHVybiAoMCk7DQorCQl9DQogCQlzaXplID0gbnByb2NzICogc2l6ZW9m KHN0cnVjdCBraW5mb19wcm9jKTsNCiAJCWtkLT5wcm9jYmFzZSA9IChzdHJ1 Y3Qga2luZm9fcHJvYyAqKV9rdm1fbWFsbG9jKGtkLCBzaXplKTsNCiAJCWlm IChrZC0+cHJvY2Jhc2UgPT0gMCkNCkluZGV4OiBzeXMva2Vybi9rZXJuX2Zv cmsuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21l L25jdnMvc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jLHYNCnJldHJpZXZpbmcg cmV2aXNpb24gMS4yODENCmRpZmYgLXUgLXAgLXIxLjI4MSBrZXJuX2Zvcmsu Yw0KLS0tIHN5cy9rZXJuL2tlcm5fZm9yay5jCTE3IFNlcCAyMDA3IDA1OjI3 OjIwIC0wMDAwCTEuMjgxDQorKysgc3lzL2tlcm4va2Vybl9mb3JrLmMJMTcg U2VwIDIwMDcgMDU6NDg6NTMgLTAwMDANCkBAIC01MDAsNiArNTAwLDcgQEAg YWdhaW46DQogCSAqIEluY3JlYXNlIHJlZmVyZW5jZSBjb3VudHMgb24gc2hh cmVkIG9iamVjdHMuDQogCSAqLw0KIAlwMi0+cF9mbGFnID0gUF9JTk1FTTsN CisJcDItPnBfc3d0aWNrID0gdGlja3M7DQogCWlmIChwMS0+cF9mbGFnICYg UF9QUk9GSUwpDQogCQlzdGFydHByb2ZjbG9jayhwMik7DQogCXRkMi0+dGRf dWNyZWQgPSBjcmhvbGQocDItPnBfdWNyZWQpOw0KSW5kZXg6IHN5cy9rZXJu L2tlcm5fcHJvYy5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmls ZTogL2hvbWUvbmN2cy9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmMsdg0KcmV0 cmlldmluZyByZXZpc2lvbiAxLjI1MQ0KZGlmZiAtdSAtcCAtcjEuMjUxIGtl cm5fcHJvYy5jDQotLS0gc3lzL2tlcm4va2Vybl9wcm9jLmMJMTcgU2VwIDIw MDcgMDU6Mjc6MjAgLTAwMDAJMS4yNTENCisrKyBzeXMva2Vybi9rZXJuX3By b2MuYwkxNyBTZXAgMjAwNyAwNjowMzoyMSAtMDAwMA0KQEAgLTY5NCw3ICs2 OTQsOCBAQCBmaWxsX2tpbmZvX3Byb2Nfb25seShzdHJ1Y3QgcHJvYyAqcCwg c3RyDQogCQlrcC0+a2lfc2ZsYWcgPSBQU19JTk1FTTsNCiAJZWxzZQ0KIAkJ a3AtPmtpX3NmbGFnID0gMDsNCi0Ja3AtPmtpX3N3dGltZSA9IHAtPnBfc3d0 aW1lOw0KKwkvKiBDYWxjdWxhdGUgbGVnYWN5IHN3dGltZSBhcyBzZWNvbmRz IHNpbmNlICdzd3RpY2snLiAqLw0KKwlrcC0+a2lfc3d0aW1lID0gKHRpY2tz IC0gcC0+cF9zd3RpY2spIC8gaHo7DQogCWtwLT5raV9waWQgPSBwLT5wX3Bp ZDsNCiAJa3AtPmtpX25pY2UgPSBwLT5wX25pY2U7DQogCXJ1ZmV0Y2gocCwg JmtwLT5raV9ydXNhZ2UpOw0KQEAgLTgxMiw3ICs4MTMsNyBAQCBmaWxsX2tp bmZvX3RocmVhZChzdHJ1Y3QgdGhyZWFkICp0ZCwgc3RyDQogCWtwLT5raV9r c3RhY2sgPSAodm9pZCAqKXRkLT50ZF9rc3RhY2s7DQogCWtwLT5raV9wY3Rj cHUgPSBzY2hlZF9wY3RjcHUodGQpOw0KIAlrcC0+a2lfZXN0Y3B1ID0gdGQt PnRkX2VzdGNwdTsNCi0Ja3AtPmtpX3NscHRpbWUgPSB0ZC0+dGRfc2xwdGlt ZTsNCisJa3AtPmtpX3NscHRpbWUgPSAodGlja3MgLSB0ZC0+dGRfc2xwdGlj aykgLyBoejsNCiAJa3AtPmtpX3ByaS5wcmlfY2xhc3MgPSB0ZC0+dGRfcHJp X2NsYXNzOw0KIAlrcC0+a2lfcHJpLnByaV91c2VyID0gdGQtPnRkX3VzZXJf cHJpOw0KIA0KSW5kZXg6IHN5cy9rZXJuL3NjaGVkXzRic2QuYw0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5 cy9rZXJuL3NjaGVkXzRic2QuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEu MTA0DQpkaWZmIC11IC1wIC1yMS4xMDQgc2NoZWRfNGJzZC5jDQotLS0gc3lz L2tlcm4vc2NoZWRfNGJzZC5jCTE3IFNlcCAyMDA3IDA1OjI3OjIwIC0wMDAw CTEuMTA0DQorKysgc3lzL2tlcm4vc2NoZWRfNGJzZC5jCTE3IFNlcCAyMDA3 IDA2OjA2OjM5IC0wMDAwDQpAQCAtODQsNiArODQsNyBAQCBzdHJ1Y3QgdGRf c2NoZWQgew0KIAlmaXhwdF90CQl0c19wY3RjcHU7CS8qIChqKSAlY3B1IGR1 cmluZyBwX3N3dGltZS4gKi8NCiAJdV9jaGFyCQl0c19ycWluZGV4OwkvKiAo aikgUnVuIHF1ZXVlIGluZGV4LiAqLw0KIAlpbnQJCXRzX2NwdGlja3M7CS8q IChqKSBUaWNrcyBvZiBjcHUgdGltZS4gKi8NCisJaW50CQl0c19zbHB0aW1l OwkvKiAoaikgU2Vjb25kcyAhUlVOTklORy4gKi8NCiAJc3RydWN0IHJ1bnEJ KnRzX3J1bnE7CS8qIHJ1bnEgdGhlIHRocmVhZCBpcyBjdXJyZW50bHkgb24g Ki8NCiB9Ow0KIA0KQEAgLTM3OSwxMSArMzgwLDYgQEAgc2NoZWRjcHUodm9p ZCkNCiAJc3hfc2xvY2soJmFsbHByb2NfbG9jayk7DQogCUZPUkVBQ0hfUFJP Q19JTl9TWVNURU0ocCkgew0KIAkJUFJPQ19TTE9DSyhwKTsNCi0JCS8qDQot CQkgKiBJbmNyZW1lbnQgdGltZSBpbi9vdXQgb2YgbWVtb3J5LiAgV2UgaWdu b3JlIG92ZXJmbG93OyB3aXRoDQotCQkgKiAxNi1iaXQgaW50J3MgKHJlbWVt YmVyIHRoZW0/KSBvdmVyZmxvdyB0YWtlcyA0NSBkYXlzLg0KLQkJICovDQot CQlwLT5wX3N3dGltZSsrOw0KIAkJRk9SRUFDSF9USFJFQURfSU5fUFJPQyhw LCB0ZCkgeyANCiAJCQlhd2FrZSA9IDA7DQogCQkJdGhyZWFkX2xvY2sodGQp Ow0KQEAgLTQ0MCw3ICs0MzYsNyBAQCBYWFggIHRoaXMgaXMgYnJva2VuDQog DQogCQkJICovDQogCQkJaWYgKGF3YWtlKSB7DQotCQkJCWlmICh0ZC0+dGRf c2xwdGltZSA+IDEpIHsNCisJCQkJaWYgKHRzLT50c19zbHB0aW1lID4gMSkg ew0KIAkJCQkJLyoNCiAJCQkJCSAqIEluIGFuIGlkZWFsIHdvcmxkLCB0aGlz IHNob3VsZCBub3QNCiAJCQkJCSAqIGhhcHBlbiwgYmVjYXVzZSB3aG9ldmVy IHdva2UgdXMNCkBAIC00NTIsMTAgKzQ0OCwxMCBAQCBYWFggIHRoaXMgaXMg YnJva2VuDQogCQkJCQkgKi8NCiAJCQkJCXVwZGF0ZXByaSh0ZCk7DQogCQkJ CX0NCi0JCQkJdGQtPnRkX3NscHRpbWUgPSAwOw0KKwkJCQl0cy0+dHNfc2xw dGltZSA9IDA7DQogCQkJfSBlbHNlDQotCQkJCXRkLT50ZF9zbHB0aW1lKys7 DQotCQkJaWYgKHRkLT50ZF9zbHB0aW1lID4gMSkgew0KKwkJCQl0cy0+dHNf c2xwdGltZSsrOw0KKwkJCWlmICh0cy0+dHNfc2xwdGltZSA+IDEpIHsNCiAJ CQkJdGhyZWFkX3VubG9jayh0ZCk7DQogCQkJCWNvbnRpbnVlOw0KIAkJCX0N CkBAIC00OTAsMTYgKzQ4NiwxOCBAQCBzY2hlZGNwdV90aHJlYWQodm9pZCkN CiBzdGF0aWMgdm9pZA0KIHVwZGF0ZXByaShzdHJ1Y3QgdGhyZWFkICp0ZCkN CiB7DQotCXJlZ2lzdGVyIGZpeHB0X3QgbG9hZGZhYzsNCi0JcmVnaXN0ZXIg dW5zaWduZWQgaW50IG5ld2NwdTsNCisJc3RydWN0IHRkX3NjaGVkICp0czsN CisJZml4cHRfdCBsb2FkZmFjOw0KKwl1bnNpZ25lZCBpbnQgbmV3Y3B1Ow0K IA0KKwl0cyA9IHRkLT50ZF9zY2hlZDsNCiAJbG9hZGZhYyA9IGxvYWRmYWN0 b3IoYXZlcnVubmFibGUubGRhdmdbMF0pOw0KLQlpZiAodGQtPnRkX3NscHRp bWUgPiA1ICogbG9hZGZhYykNCisJaWYgKHRzLT50c19zbHB0aW1lID4gNSAq IGxvYWRmYWMpDQogCQl0ZC0+dGRfZXN0Y3B1ID0gMDsNCiAJZWxzZSB7DQog CQluZXdjcHUgPSB0ZC0+dGRfZXN0Y3B1Ow0KLQkJdGQtPnRkX3NscHRpbWUt LTsJLyogd2FzIGluY3JlbWVudGVkIGluIHNjaGVkY3B1KCkgKi8NCi0JCXdo aWxlIChuZXdjcHUgJiYgLS10ZC0+dGRfc2xwdGltZSkNCisJCXRzLT50c19z bHB0aW1lLS07CS8qIHdhcyBpbmNyZW1lbnRlZCBpbiBzY2hlZGNwdSgpICov DQorCQl3aGlsZSAobmV3Y3B1ICYmIC0tdHMtPnRzX3NscHRpbWUpDQogCQkJ bmV3Y3B1ID0gZGVjYXlfY3B1KGxvYWRmYWMsIG5ld2NwdSk7DQogCQl0ZC0+ dGRfZXN0Y3B1ID0gbmV3Y3B1Ow0KIAl9DQpAQCAtODI3LDcgKzgyNSw4IEBA IHNjaGVkX3NsZWVwKHN0cnVjdCB0aHJlYWQgKnRkKQ0KIHsNCiANCiAJVEhS RUFEX0xPQ0tfQVNTRVJUKHRkLCBNQV9PV05FRCk7DQotCXRkLT50ZF9zbHB0 aW1lID0gMDsNCisJdGQtPnRkX3NscHRpY2sgPSB0aWNrczsNCisJdGQtPnRk X3NjaGVkLT50c19zbHB0aW1lID0gMDsNCiB9DQogDQogdm9pZA0KQEAgLTkz OSwxMiArOTM4LDE2IEBAIHNjaGVkX3N3aXRjaChzdHJ1Y3QgdGhyZWFkICp0 ZCwgc3RydWN0IHQNCiB2b2lkDQogc2NoZWRfd2FrZXVwKHN0cnVjdCB0aHJl YWQgKnRkKQ0KIHsNCisJc3RydWN0IHRkX3NjaGVkICp0czsNCisNCiAJVEhS RUFEX0xPQ0tfQVNTRVJUKHRkLCBNQV9PV05FRCk7DQotCWlmICh0ZC0+dGRf c2xwdGltZSA+IDEpIHsNCisJdHMgPSB0ZC0+dGRfc2NoZWQ7DQorCWlmICh0 cy0+dHNfc2xwdGltZSA+IDEpIHsNCiAJCXVwZGF0ZXByaSh0ZCk7DQogCQly ZXNldHByaW9yaXR5KHRkKTsNCiAJfQ0KLQl0ZC0+dGRfc2xwdGltZSA9IDA7 DQorCXRkLT50ZF9zbHB0aWNrID0gdGlja3M7DQorCXRzLT50c19zbHB0aW1l ID0gMDsNCiAJc2NoZWRfYWRkKHRkLCBTUlFfQk9SSU5HKTsNCiB9DQogDQpJ bmRleDogc3lzL2tlcm4vc2NoZWRfdWxlLmMNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMva2Vybi9zY2hl ZF91bGUuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjA2DQpkaWZmIC11 IC1wIC1yMS4yMDYgc2NoZWRfdWxlLmMNCi0tLSBzeXMva2Vybi9zY2hlZF91 bGUuYwkxNyBTZXAgMjAwNyAwNToyNzoyMCAtMDAwMAkxLjIwNg0KKysrIHN5 cy9rZXJuL3NjaGVkX3VsZS5jCTE3IFNlcCAyMDA3IDA2OjA3OjMwIC0wMDAw DQpAQCAtODgsNyArODgsNiBAQCBzdHJ1Y3QgdGRfc2NoZWQgewkNCiAJc2hv cnQJCXRzX2ZsYWdzOwkvKiBUU0ZfKiBmbGFncy4gKi8NCiAJdV9jaGFyCQl0 c19ycWluZGV4OwkvKiBSdW4gcXVldWUgaW5kZXguICovDQogCXVfY2hhcgkJ dHNfY3B1OwkJLyogQ1BVIHRoYXQgd2UgaGF2ZSBhZmZpbml0eSBmb3IuICov DQotCWludAkJdHNfc2xwdGljazsJLyogVGljayB3aGVuIHdlIHdlbnQgdG8g c2xlZXAuICovDQogCWludAkJdHNfc2xpY2U7CS8qIFRpY2tzIG9mIHNsaWNl IHJlbWFpbmluZy4gKi8NCiAJdV9pbnQJCXRzX3NscHRpbWU7CS8qIE51bWJl ciBvZiB0aWNrcyB3ZSB2b2wuIHNsZXB0ICovDQogCXVfaW50CQl0c19ydW50 aW1lOwkvKiBOdW1iZXIgb2YgdGlja3Mgd2Ugd2VyZSBydW5uaW5nICovDQpA QCAtMTkxNCw3ICsxOTEzLDcgQEAgc2NoZWRfc2xlZXAoc3RydWN0IHRocmVh ZCAqdGQpDQogDQogCVRIUkVBRF9MT0NLX0FTU0VSVCh0ZCwgTUFfT1dORUQp Ow0KIA0KLQl0ZC0+dGRfc2NoZWQtPnRzX3NscHRpY2sgPSB0aWNrczsNCisJ dGQtPnRkX3NscHRpY2sgPSB0aWNrczsNCiB9DQogDQogLyoNCkBAIC0xOTMz LDggKzE5MzIsOCBAQCBzY2hlZF93YWtldXAoc3RydWN0IHRocmVhZCAqdGQp DQogCSAqIElmIHdlIHNsZXB0IGZvciBtb3JlIHRoYW4gYSB0aWNrIHVwZGF0 ZSBvdXIgaW50ZXJhY3Rpdml0eSBhbmQNCiAJICogcHJpb3JpdHkuDQogCSAq Lw0KLQlzbHB0aWNrID0gdHMtPnRzX3NscHRpY2s7DQotCXRzLT50c19zbHB0 aWNrID0gMDsNCisJc2xwdGljayA9IHRkLT50ZF9zbHB0aWNrOw0KKwl0ZC0+ dGRfc2xwdGljayA9IDA7DQogCWlmIChzbHB0aWNrICYmIHNscHRpY2sgIT0g dGlja3MpIHsNCiAJCXVfaW50IGh6dGlja3M7DQogDQpAQCAtMjQzNSw3ICsy NDM0LDYgQEAgc2NoZWRfcGN0Y3B1KHN0cnVjdCB0aHJlYWQgKnRkKQ0KIAkJ cnRpY2sgPSBtaW4oU0NIRURfVElDS19IWih0cykgLyBTQ0hFRF9USUNLX1NF Q1MsIGh6KTsNCiAJCXBjdGNwdSA9IChGU0NBTEUgKiAoKEZTQ0FMRSAqIHJ0 aWNrKS9oeikpID4+IEZTSElGVDsNCiAJfQ0KLQl0ZC0+dGRfcHJvYy0+cF9z d3RpbWUgPSB0cy0+dHNfbHRpY2sgLSB0cy0+dHNfZnRpY2s7DQogCXRocmVh ZF91bmxvY2sodGQpOw0KIA0KIAlyZXR1cm4gKHBjdGNwdSk7DQpJbmRleDog c3lzL3N5cy9wcm9jLmgNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBm aWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvc3lzL3Byb2MuaCx2DQpyZXRyaWV2 aW5nIHJldmlzaW9uIDEuNDkwDQpkaWZmIC11IC1wIC1yMS40OTAgcHJvYy5o DQotLS0gc3lzL3N5cy9wcm9jLmgJMTcgU2VwIDIwMDcgMDU6Mjc6MjEgLTAw MDAJMS40OTANCisrKyBzeXMvc3lzL3Byb2MuaAkxNyBTZXAgMjAwNyAwNjow MDo1MCAtMDAwMA0KQEAgLTI0Miw3ICsyNDIsNyBAQCBzdHJ1Y3QgdGhyZWFk IHsNCiAJc3RydWN0IHRocmVhZAkqdGRfc3RhbmRpbjsJLyogKGsgKyBhKSBV c2UgdGhpcyBmb3IgYW4gdXBjYWxsLiAqLw0KIAlzdHJ1Y3Qga3NlX3VwY2Fs bCAqdGRfdXBjYWxsOwkvKiAoayArIHQpIFVwY2FsbCBzdHJ1Y3R1cmUuICov DQogCXVfaW50CQl0ZF9lc3RjcHU7CS8qICh0KSBlc3RpbWF0ZWQgY3B1IHV0 aWxpemF0aW9uICovDQotCXVfaW50CQl0ZF9zbHB0aW1lOwkvKiAodCkgSG93 IGxvbmcgY29tcGxldGVseSBibG9ja2VkLiAqLw0KKwl1X2ludAkJdGRfc2xw dGljazsJLyogKHQpIFRpbWUgYXQgc2xlZXAuICovDQogCXN0cnVjdCBydXNh Z2UJdGRfcnU7CQkvKiAodCkgcnVzYWdlIGluZm9ybWF0aW9uICovDQogCXVp bnQ2NF90CXRkX3J1bnRpbWU7CS8qICh0KSBIb3cgbWFueSBjcHUgdGlja3Mg d2UndmUgcnVuLiAqLw0KIAl1X2ludCAJCXRkX3B0aWNrczsJLyogKHQpIFN0 YXRjbG9jayBoaXRzIGZvciBwcm9maWxpbmcgKi8NCkBAIC01MjAsNyArNTIw LDcgQEAgc3RydWN0IHByb2Mgew0KICNkZWZpbmUJcF9zdGFydHplcm8JcF9v cHBpZA0KIAlwaWRfdAkJcF9vcHBpZDsJLyogKGMgKyBlKSBTYXZlIHBwaWQg aW4gcHRyYWNlLiBYWFggKi8NCiAJc3RydWN0IHZtc3BhY2UJKnBfdm1zcGFj ZTsJLyogKGIpIEFkZHJlc3Mgc3BhY2UuICovDQotCXVfaW50CQlwX3N3dGlt ZTsJLyogKGopIFRpbWUgc3dhcHBlZCBpbiBvciBvdXQuICovDQorCXVfaW50 CQlwX3N3dGljazsJLyogKGopIFRpY2sgd2hlbiBzd2FwcGVkIGluIG9yIG91 dC4gKi8NCiAJc3RydWN0IGl0aW1lcnZhbCBwX3JlYWx0aW1lcjsJLyogKGMp IEFsYXJtIHRpbWVyLiAqLw0KIAlzdHJ1Y3QgcnVzYWdlCXBfcnU7CQkvKiAo YSkgRXhpdCBpbmZvcm1hdGlvbi4gKi8NCiAJc3RydWN0IHJ1c2FnZV9leHQg cF9ydXg7CS8qIChjaikgSW50ZXJuYWwgcmVzb3VyY2UgdXNhZ2UuICovDQpJ bmRleDogc3lzL3ZtL3ZtX2dsdWUuYw0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy92bS92bV9nbHVlLmMs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjIyNA0KZGlmZiAtdSAtcCAtcjEu MjI0IHZtX2dsdWUuYw0KLS0tIHN5cy92bS92bV9nbHVlLmMJMTcgU2VwIDIw MDcgMDU6Mjc6MjEgLTAwMDAJMS4yMjQNCisrKyBzeXMvdm0vdm1fZ2x1ZS5j CTE3IFNlcCAyMDA3IDA2OjA1OjA3IC0wMDAwDQpAQCAtNjM2LDcgKzYzNiw3 IEBAIGZhdWx0aW4ocCkNCiAJCVBST0NfTE9DSyhwKTsNCiAJCVBST0NfU0xP Q0socCk7DQogCQlzd2FwY2xlYXIocCk7DQotCQlwLT5wX3N3dGltZSA9IDA7 DQorCQlwLT5wX3N3dGljayA9IHRpY2tzOw0KIAkJUFJPQ19TVU5MT0NLKHAp Ow0KIA0KIAkJd2FrZXVwKCZwLT5wX2ZsYWcpOw0KQEAgLTY2Myw5ICs2NjMs MTEgQEAgc2NoZWR1bGVyKGR1bW15KQ0KIHsNCiAJc3RydWN0IHByb2MgKnA7 DQogCXN0cnVjdCB0aHJlYWQgKnRkOw0KLQlpbnQgcHJpOw0KIAlzdHJ1Y3Qg cHJvYyAqcHA7DQorCWludCBzbHB0aW1lOw0KKwlpbnQgc3d0aW1lOw0KIAlp bnQgcHByaTsNCisJaW50IHByaTsNCiANCiAJbXR4X2Fzc2VydCgmR2lhbnQs IE1BX09XTkVEIHwgTUFfTk9UUkVDVVJTRUQpOw0KIAltdHhfdW5sb2NrKCZH aWFudCk7DQpAQCAtNjg4LDYgKzY5MCw3IEBAIGxvb3A6DQogCQkJUFJPQ19V TkxPQ0socCk7DQogCQkJY29udGludWU7DQogCQl9DQorCQlzd3RpbWUgPSAo dGlja3MgLSBwLT5wX3N3dGljaykgLyBoejsNCiAJCVBST0NfU0xPQ0socCk7 DQogCQlGT1JFQUNIX1RIUkVBRF9JTl9QUk9DKHAsIHRkKSB7DQogCQkJLyoN CkBAIC02OTcsNyArNzAwLDggQEAgbG9vcDoNCiAJCQkgKi8NCiAJCQl0aHJl YWRfbG9jayh0ZCk7DQogCQkJaWYgKHRkLT50ZF9pbmhpYml0b3JzID09IFRE SV9TV0FQUEVEKSB7DQotCQkJCXByaSA9IHAtPnBfc3d0aW1lICsgdGQtPnRk X3NscHRpbWU7DQorCQkJCXNscHRpbWUgPSAodGlja3MgLSB0ZC0+dGRfc2xw dGljaykgLyBoejsNCisJCQkJcHJpID0gc3d0aW1lICsgc2xwdGltZTsNCiAJ CQkJaWYgKCh0ZC0+dGRfZmxhZ3MgJiBUREZfU1dBUElOUkVRKSA9PSAwKQ0K IAkJCQkJcHJpIC09IHAtPnBfbmljZSAqIDg7DQogCQkJCS8qDQpAQCAtODE2 LDYgKzgyMCw3IEBAIHJldHJ5Og0KIAlGT1JFQUNIX1BST0NfSU5fU1lTVEVN KHApIHsNCiAJCXN0cnVjdCB2bXNwYWNlICp2bTsNCiAJCWludCBtaW5zbHB0 aW1lID0gMTAwMDAwOw0KKwkJaW50IHNscHRpbWU7DQogCQkNCiAJCS8qDQog CQkgKiBXYXRjaCBvdXQgZm9yIGEgcHJvY2VzcyBpbg0KQEAgLTg4MiwxMiAr ODg3LDEyIEBAIHJldHJ5Og0KIAkJCQkJdGhyZWFkX3VubG9jayh0ZCk7DQog CQkJCQlnb3RvIG5leHRwcm9jOw0KIAkJCQl9DQotDQorCQkJCXNscHRpbWUg PSAodGlja3MgLSB0ZC0+dGRfc2xwdGljaykgLyBoejsNCiAJCQkJLyoNCiAJ CQkJICogR3VhcmFudGVlIHN3YXBfaWRsZV90aHJlc2hvbGQxDQogCQkJCSAq IHRpbWUgaW4gbWVtb3J5Lg0KIAkJCQkgKi8NCi0JCQkJaWYgKHRkLT50ZF9z bHB0aW1lIDwgc3dhcF9pZGxlX3RocmVzaG9sZDEpIHsNCisJCQkJaWYgKHNs cHRpbWUgPCBzd2FwX2lkbGVfdGhyZXNob2xkMSkgew0KIAkJCQkJdGhyZWFk X3VubG9jayh0ZCk7DQogCQkJCQlnb3RvIG5leHRwcm9jOw0KIAkJCQl9DQpA QCAtOTE0LDEzICs5MTksMTMgQEAgcmV0cnk6DQogCQkJCSAqLw0KIAkJCQlp ZiAoKChhY3Rpb24gJiBWTV9TV0FQX05PUk1BTCkgPT0gMCkgJiYNCiAJCQkJ ICAgICgoKGFjdGlvbiAmIFZNX1NXQVBfSURMRSkgPT0gMCkgfHwNCi0JCQkJ ICAgICh0ZC0+dGRfc2xwdGltZSA8IHN3YXBfaWRsZV90aHJlc2hvbGQyKSkp IHsNCisJCQkJICAgIChzbHB0aW1lIDwgc3dhcF9pZGxlX3RocmVzaG9sZDIp KSkgew0KIAkJCQkJdGhyZWFkX3VubG9jayh0ZCk7DQogCQkJCQlnb3RvIG5l eHRwcm9jOw0KIAkJCQl9DQogDQotCQkJCWlmIChtaW5zbHB0aW1lID4gdGQt PnRkX3NscHRpbWUpDQotCQkJCQltaW5zbHB0aW1lID0gdGQtPnRkX3NscHRp bWU7DQorCQkJCWlmIChtaW5zbHB0aW1lID4gc2xwdGltZSkNCisJCQkJCW1p bnNscHRpbWUgPSBzbHB0aW1lOw0KIAkJCQl0aHJlYWRfdW5sb2NrKHRkKTsN CiAJCQl9DQogDQpAQCAtMTAzOCw3ICsxMDQzLDcgQEAgc3dhcG91dChwKQ0K IAlQUk9DX0xPQ0socCk7DQogCXAtPnBfZmxhZyAmPSB+UF9TV0FQUElOR09V VDsNCiAJUFJPQ19TTE9DSyhwKTsNCi0JcC0+cF9zd3RpbWUgPSAwOw0KKwlw LT5wX3N3dGljayA9IHRpY2tzOw0KIAlyZXR1cm4gKDApOw0KIH0NCiAjZW5k aWYgLyogIU5PX1NXQVBQSU5HICovDQo= --0-1681148293-1190063736=:558-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 21:14:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CDA616A46B; Mon, 17 Sep 2007 21:14:17 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id F132213C481; Mon, 17 Sep 2007 21:14:16 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8HLEE9Y035318 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2007 17:14:15 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 17 Sep 2007 14:17:09 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Ganbold In-Reply-To: <46EE2C98.90802@micom.mng.net> Message-ID: <20070917141639.Q558@10.0.0.1> References: <20070916225019.B921C4500C@ptavv.es.net> <46EDCC48.2090405@FreeBSD.org> <20070916202402.X4507@10.0.0.1> <46EE2C98.90802@micom.mng.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "David E. Thiel" , freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 21:14:17 -0000 On Mon, 17 Sep 2007, Ganbold wrote: > Jeff Roberson wrote: >> On Mon, 17 Sep 2007, Kris Kennaway wrote: >> >>> Kevin Oberman wrote: >>>>> Date: Sun, 16 Sep 2007 14:47:54 -0700 >>>>> From: "David E. Thiel" >>>>> Sender: owner-freebsd-current@freebsd.org >>>>> >>>>> On Sun, Sep 16, 2007 at 12:58:33AM -0700, vehemens wrote: >>>>>> On Saturday 15 September 2007 11:19:32 pm Roman Bogorodskiy wrote: >>>>>>> I'm curious if SCHED_ULE is designed to be used on a desktop system. >>>>>>> I'm >>>>>>> running -CURRENT at home and tried to use SCHED_ULE for some time. It >>>>>>> works alright while the load is not very high. But once I start >>>>>>> compiling something (running 'make buildworld' or 'portupgrade -a' for >>>>>>> example), the machine comes almost unusable - X11's windows takes a >>>>>>> lot >>>>>>> of time to redraw, changing virtual desktop in window manager may take >>>>>>> a several seconds. And it's nearly impossible to watch some movie with >>>>>>> mplayer. >>>>>> I also see something similar running -CURRENT with SCHED_4BSD, >>>>>> but it shows up with X/gnome. Remote logins are still responsive >>>>>> and running X/twm works fine. >>>>> In my experience, both 4BSD and ULE are unresponsive on the desktop >>>>> in -CURRENT, with ULE being somewhat worse. Compiling an application >>>>> causes the mouse to be jerky, windows to draw slowly, audio to start >>>>> skipping, and occasionally the whole desktop freezes for a minute at >>>>> a time (with ULE only). This is with INVARIANTS and all the debugging >>>>> kernel options disabled and malloc debugging turned off. I'll give >>>>> running without PREEMPTION with 4BSD and the ULE patch a shot, >>>>> but in its stock form, -CURRENT is definitely worse than -STABLE on the >>>>> desktop for me in a UP configuration. Up till now, I've been working >>>>> around it manually by juggling with rtprio. >>>>> >>>>> If it's of any use, dmesg is at: >>>>> >>>>> http://redundancy.redundancy.org/dmesg.txt >>>> >>>> I have been seeing this for quite some time and, while the scheduler may >>>> make a bit of difference, I suspect pager issues. As long as I have >>>> available memory, interactivity is fine. If I run a big build and I see >>>> swap file use, things slow to a crawl. I see very slow re-draws of the >>>> screen and general lack of responsiveness. >>>> >>>> I run gkrellm and can tell at a glance when swap usage starts to >>>> increase. The linkage is clear and not terribly surprising. It may be >>>> that you need to add a bit more RAM. >>> >>> Yes, not surprising in the least. When your system touches swap, >>> performance will drop to a tiny fraction of its normal performance. >>> Depending on your disk this could be 1% or lower. Anyone who is seeing >>> poor interactive performance needs to rule this out as the cause. >> >> Ah, I think I know why people are reporting worse problems with ULE. ULE >> is not properly accounting swtime so different threads are being chosen for >> swapout with ULE and 4BSD. My test systems all have more than enough >> memory to do parallel buildworlds without swapping. This is likely why I >> haven't run into this. >> >> I really need to fix p_swtime with ULE. Could the people reporting bad >> behavior please verify whether or not you're seeing swapping activity? Even >> just looking for swap used in top will help me verify that this is the >> problem. > > I explained my problem in > http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076450.html. > This is a UP system and I have 1GB RAM and top results are shown there. Ganbold, Thank you for your report. I just sent a follow-up mail to current with a patch that addresses this issue. Can you test and report back? Thanks! Jeff > > > Ganbold > >> >> Thanks, >> Jeff >> >> >>> >>> Kris >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 21:15:02 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4392316A41A for ; Mon, 17 Sep 2007 21:15:02 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id D4B4C13C467 for ; Mon, 17 Sep 2007 21:15:01 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l8HLF04L097281; Tue, 18 Sep 2007 01:15:00 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Tue, 18 Sep 2007 01:15:00 +0400 (MSD) From: Dmitry Morozovsky To: Maxim Sobolev In-Reply-To: <46EEC481.5010503@FreeBSD.org> Message-ID: <20070918011258.L96165@woozle.rinet.ru> References: <20070914124630.D14000@woozle.rinet.ru> <46EEC481.5010503@FreeBSD.org> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Tue, 18 Sep 2007 01:15:00 +0400 (MSD) Cc: current@FreeBSD.org Subject: Re: i386 package building on an amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 21:15:02 -0000 On Mon, 17 Sep 2007, Maxim Sobolev wrote: MS> > possibly stupid question: it there a way to fool jail (real, not MS> > "tinderbox" one) that it's working under i386 kernel? This would be MS> > extremely useful for local package building. MS> > MS> > Quick googling does not reveal anything, or did I miss something obvious? MS> > MS> > Thanks in advance. MS> MS> Works here like a charm. The only thing is that you need to set UNAME_p=i386 MS> UNAME_m=i386 and CPUTYPE=i686 variables in the chroot/jail. I know aboot uname tricks ;-) What about sysctls revealing amd64 system internals? Did you compare packages built by this jailed system with native? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 21:19:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78CE216A420; Mon, 17 Sep 2007 21:19:36 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3479F13C4D1; Mon, 17 Sep 2007 21:19:36 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8HLJYg1036807 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2007 17:19:35 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 17 Sep 2007 14:22:29 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Roman Bogorodskiy In-Reply-To: <20070917162400.GA42669@underworld.novel.ru> Message-ID: <20070917141820.M558@10.0.0.1> References: <20070916061932.GA93480@underworld.novel.ru> <20070915234855.G531@10.0.0.1> <20070916071421.GA1320@underworld.novel.ru> <20070916003323.U4507@10.0.0.1> <20070917044351.GA17565@underworld.novel.ru> <20070917162400.GA42669@underworld.novel.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 21:19:36 -0000 On Mon, 17 Sep 2007, Roman Bogorodskiy wrote: > Roman Bogorodskiy wrote: > >> Jeff Roberson wrote: >> >>> On Sun, 16 Sep 2007, Roman Bogorodskiy wrote: >>> >>>> Jeff Roberson wrote: >>>> >>>>> This is contrary to the experiences of many others. Can you send me your >>>>> dmesg? There may be something about your particular hardware that is >>>>> triggering a bug. ULE is definitely designed to be responsive on the >>>>> desktop. >>>> >>>> Thanks for the quick answer! >>>> >>>> Here's my dmesg: http://people.freebsd.org/~novel/misc/dmesg.txt >>> >>> Roman, >>> >>> The enclosed patch helps things on my system, however, there are still some >>> delays due to IO issues. Let me know if this helps. >> >> This patch seems to make my system react faster. However I need some >> time to test it more carefully. > > It looks like it's not really so, it's still very slow under load. :( Roman, Can you please verify that you are not swapping. If you are, try the patch that I sent. Otherwise, can you try getting KTR_SCHED output for me? Put the following in your kernel config file: options KTR options KTR_COMPILE=KTR_SCHED options KTR_MASK=KTR_SCHED options KTR_ENTRIES=65536 Then run the load that exhibits the problem. compile, play a movie, etc. wait for a particularly bad pause and then run the following: sysctl debug.ktr.mask=0 && ktrdump -ct > out && sysctl debug.ktr.mask=536870 It's best to have the command ready in a shell so you can run it in the closest proximity to the incident. Then gzip the results and email them to me. On my system I'm not able to play a movie while running buildworld due to long disk waits. However, if I use a dvd driver, mplayer and x windows both get enough cpu time to play the movie skip free. So this is not a cpu scheduler problem as such. IO scheduling does feel less responsive than 6.x but I have not done a side by side comparison. Jeff > >>> Thanks, >>> Jeff >>> >>>> >>>> Roman Bogorodskiy >>>> >> >> >> Roman Bogorodskiy > > > Roman Bogorodskiy > From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 21:29:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B05B16A41B for ; Mon, 17 Sep 2007 21:29:50 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2050113C478 for ; Mon, 17 Sep 2007 21:29:49 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.2]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 23:29:48 +0200 Message-ID: <46EEF1DE.50101@dlr.de> Date: Mon, 17 Sep 2007 23:30:06 +0200 From: Hartmut Brandt Organization: German Aerospace Center User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Wilko Bulte References: <46EAA12D.4090207@ludd.ltu.se> <46EEC9AB.2010805@dlr.de> <20070917191306.GA13449@freebie.xs4all.nl> In-Reply-To: <20070917191306.GA13449@freebie.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2007 21:29:48.0761 (UTC) FILETIME=[DFF90C90:01C7F971] Cc: freebsd-current@freebsd.org, Anders Magnusson Subject: Re: Compiling with another compiler than gcc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 21:29:50 -0000 Wilko Bulte wrote: > On Mon, Sep 17, 2007 at 08:38:35PM +0200, Hartmut Brandt wrote.. >> Anders Magnusson wrote: >>> It is not yet bug-free, but it can compile the i386 userspace. The big >>> benefit of it >>> (apart from that it's BSD licensed, for license geeks :-) is that it is >>> fast, 5-10 times >>> faster than gcc, while still producing reasonable code. The only >> When reading the name pcc my first thought was: isn't that the compiler >> that was distributed on later Unix V7 tapes? And yes, the web-page says >> it is based on that one. I'm quite sure that the original code had no >> BSD copyright, so I wonder how it obtained one? For the rewritten code >> there is no question, but what for the remaining original code? Has it >> been relicensed by the original author? >> >> It's interesting that the compiler is so much faster than gcc. I >> remember that it was around 3-5 times slower than the dmr compiler under >> V7. This tells a lot about gcc's speed :-( > > Wanna try if that is still the case? I can drag the uPDP 11/73 from my > basement. 2BSD on it and all that. > > 8-) > I've wrote an emulator for the KDJ11A (11/73 I think) more than 10 years ago before I gave my machine to Grog. It runs RSX11M[+], RT11, v[567], 2.11BSD at light speed :-) It's on people.freebsd.org/~harti. Compiles 2.11BSD in less than an hour. It's probably easier than to put up your 11/73 :-) About pcc: I've a z8000 based computer with a Unix System III on which uses pcc as the system compiler. It's so buggy that I wonder how the system even runs. But I suppose these bugs are mostly in the z8000 backend (no sources to check, though). harti From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 21:36:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8451216A468 for ; Mon, 17 Sep 2007 21:36:56 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 39F7B13C45D for ; Mon, 17 Sep 2007 21:36:56 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.2]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 23:36:55 +0200 Message-ID: <46EEF38A.6030304@dlr.de> Date: Mon, 17 Sep 2007 23:37:14 +0200 From: Hartmut Brandt Organization: German Aerospace Center User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Anders Magnusson References: <46EAA12D.4090207@ludd.ltu.se> <46EEC9AB.2010805@dlr.de> <46EEE02F.10409@ludd.ltu.se> In-Reply-To: <46EEE02F.10409@ludd.ltu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2007 21:36:55.0461 (UTC) FILETIME=[DE4E4D50:01C7F972] Cc: freebsd-current@freebsd.org Subject: Re: Compiling with another compiler than gcc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 21:36:56 -0000 Anders Magnusson wrote: > Hi, > > Hartmut Brandt wrote: >> Anders Magnusson wrote: >>> It is not yet bug-free, but it can compile the i386 userspace. The >>> big benefit of it >>> (apart from that it's BSD licensed, for license geeks :-) is that it >>> is fast, 5-10 times >>> faster than gcc, while still producing reasonable code. The only >> >> When reading the name pcc my first thought was: isn't that the >> compiler that was distributed on later Unix V7 tapes? And yes, the >> web-page says it is based on that one. I'm quite sure that the >> original code had no BSD copyright, so I wonder how it obtained one? >> For the rewritten code there is no question, but what for the >> remaining original code? Has it been relicensed by the original author? > Caldera released it with BSD license some 6 years ago, as part of their > "ancient unix". I've still one of these licenses that costed $100 in the beginning :-( So that looks ok. > >> It's interesting that the compiler is so much faster than gcc. I >> remember that it was around 3-5 times slower than the dmr compiler >> under V7. This tells a lot about gcc's speed :-( >> > Yes, and you are remembering correct. And yes, it says something about > gcc. > Even more interesting is that there are lots of quite slow sanity check > code in > pcc, despite that it's really fast. I suppose that the slowness when compared to Ritchie's compiler was because it was much larger (causing a lot of swapping) and it uses lex and yacc instead of hand-written parsers and lexers. Those where much slower on a PDP11. Nowadays this shouldn't make a big difference, though. The slowness of gcc comes probably from the machine-independent code representation in the backend. At least I remember a speed drop of a factor 3-4 when they inventend it going from gcc1.x to gcc2.x Nice to hear, that you're working on this! harti From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 21:38:31 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F76116A418 for ; Mon, 17 Sep 2007 21:38:31 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id ED15F13C46B for ; Mon, 17 Sep 2007 21:38:30 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 17 Sep 2007 14:04:35 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id l8HL9upt015952; Mon, 17 Sep 2007 14:09:56 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id l8HL9uiZ015951; Mon, 17 Sep 2007 14:09:56 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200709172109.l8HL9uiZ015951@ambrisko.com> In-Reply-To: <20070914124630.D14000@woozle.rinet.ru> To: Dmitry Morozovsky Date: Mon, 17 Sep 2007 14:09:56 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: current@freebsd.org Subject: Re: i386 package building on an amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 21:38:31 -0000 Dmitry Morozovsky writes: | Hi there colleagues, | | possibly stupid question: it there a way to fool jail (real, not "tinderbox" | one) that it's working under i386 kernel? This would be extremely useful for | local package building. | | Quick googling does not reveal anything, or did I miss something obvious? Mostly, OSVERSION= UNAME_m= UNAME_p= UNAME_r= UNAME_s= UNAME_v= then chroot or jail. I have a script: #!/bin/sh UNAME_s="FreeBSD" UNAME_m="i386" UNAME_p="i386" ROOT=$HOME/current_$UNAME_p REVISION=`cd ${ROOT}/sys/conf && grep REVISION= newvers.sh | cut -f2 -d'"'` BRANCH=`cd ${ROOT}/sys/conf && grep BRANCH= newvers.sh | head -n1 | cut -f2 -d' "'` UNAME_r=$REVISION-$BRANCH UNAME_v="$UNAME_s $UNAME_r #0: Thu May 4 07:54:55 PDT 2006 root@a21p:/data/ home/ambrisko/current/usr/src/sys/$UNAME_p/compile/THINK" OSVERSION=`awk '/\#define.*__FreeBSD_version/ { print $3 }' < ${ROOT}/sys/sys/pa ram.h` export UNAME_s UNAME_r UNAME_v UNAME_m UNAME_p OSVERSION ROOT if [ -r $ROOT/dev/zero ] then echo dev already mounted else sudo mount -t devfs dev $ROOT/dev fi sudo ln -sf ld-elf.so.1 $ROOT/libexec/ld-elf32.so.1 sudo sh -c '( echo "libpthread.so.2 libthr.so.2" ;\ echo "libpthread.so libthr.so") > ${ROOT}/etc/libmap.conf' sudo cp ${ROOT}/etc/libmap.conf ${ROOT}/etc/libmap32.conf sudo chroot $ROOT It could be made even smarter but looking at the dest and figuring out the release as well. We could make it a make target since you can do this into 6.2 world as well (amd64/current -> amd64/6.2, amd64/current -> i386/6.2 or amd64/current -> amd64/i386). I think I merged in the UNAME_/OSVERSION stuff before 6.2 went out. I also have local hacks to do this with 4.X. At work, our build machines are all loaded up with amd64 and we build i386 or amd64 SW on them. This includes whatever ports are needed. Doug A. From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 22:10:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D6B216A418 for ; Mon, 17 Sep 2007 22:10:57 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 39E2B13C457 for ; Mon, 17 Sep 2007 22:10:57 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IXOnp-00070W-GX for freebsd-current@freebsd.org; Tue, 18 Sep 2007 00:10:49 +0200 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Sep 2007 00:10:49 +0200 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Sep 2007 00:10:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Mon, 17 Sep 2007 15:10:33 -0700 Lines: 117 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.10.5 Sender: news Subject: sctp panic: Huh, its non zero and nothing on control? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 22:10:57 -0000 I got this panic today while testing sctp on a different target with this box as a client, although the version of current is a little crusty (maybe I should be running sctp without INVARIANTS?) FreeBSD 7.0-CURRENT #1: Fri Aug 10 08:14:46 PDT 2007 panic: Huh, its non zero and nothing on control? cpuid = 1 KDB: enter: panic [thread pid 8815 tid 100130 ] Stopped at kdb_enter+0x32: leave db> db> where Tracing pid 8815 tid 100130 td 0xc5992000 kdb_enter(c0aa11be,1,c0ab6a33,e83e8930,1,...) at kdb_enter+0x32 panic(c0ab6a33,0,c0ab68a2,130b,c70c3b48,...) at panic+0x124 sctp_sorecvmsg(c70c3ad4,e83e8bf4,0,e83e8a8c,100,...) at sctp_sorecvmsg+0x3e4 sctp_soreceive(c70c3ad4,e83e8be8,e83e8bf4,0,0,...) at sctp_soreceive+0x9e soreceive(c70c3ad4,e83e8be8,e83e8bf4,0,0,...) at soreceive+0x4d kern_recvit(c5992000,3,e83e8c60,0,0,...) at kern_recvit+0x153 recvit(0,c0aa2cd4,83b,bfbcdec8,3e8,0,0,e83e8c58,1,0,281aceb8,0) at recvit+0x31 recvfrom(c5992000,e83e8cfc,18,c0aa6ebd,c0b4ec18,...) at recvfrom+0x76 syscall(e83e8d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (29, FreeBSD ELF32, recvfrom), eip = 0x281558e7, esp = 0xbfbcddfc, ebp = 0xbfbcde28 --- db> call doadump Physical memory: 2034 MB Dumping 278 MB: 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 Dump complete = 0xf [root@marka-k8we K8WE]$ kgdb kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: Huh, its non zero and nothing on control? cpuid = 1 KDB: enter: panic Physical memory: 2034 MB Dumping 278 MB: 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc048cbc9 in db_fncall (dummy1=-1065925454, dummy2=0, dummy3=-1, dummy4=0xe83e8708 "") at /usr/src/sys/ddb/db_command.c:486 #2 0xc048d135 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #3 0xc048e8b5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 #4 0xc0774335 in kdb_trap (type=3, code=0, tf=0xe83e88b0) at /usr/src/sys/kern/subr_kdb.c:502 #5 0xc0a0a88f in trap (frame=0xe83e88b0) at /usr/src/sys/i386/i386/trap.c:621 #6 0xc09f0edb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc07744b2 in kdb_enter (msg=0xc0aa11be "panic") at cpufunc.h:60 #8 0xc074bb54 in panic ( fmt=0xc0ab6a33 "Huh, its non zero and nothing on control?") at /usr/src/sys/kern/kern_shutdown.c:547 #9 0xc0880114 in sctp_sorecvmsg (so=0xc70c3ad4, uio=0xe83e8bf4, mp=0x0, from=0xe83e8a8c, fromlen=256, msg_flags=0xe83e8c78, sinfo=0xe83e8a0c, filling_sinfo=0) at /usr/src/sys/netinet/sctputil.c:4881 #10 0xc088186e in sctp_soreceive (so=0xc70c3ad4, psa=0xe83e8be8, uio=0xe83e8bf4, mp0=0x0, controlp=0x0, flagsp=0xe83e8c78) at /usr/src/sys/netinet/sctputil.c:5687 #11 0xc07a240d in soreceive (so=0xc70c3ad4, psa=0xe83e8be8, uio=0xe83e8bf4, mp0=0x0, controlp=0x0, flagsp=0xe83e8c78) at /usr/src/sys/kern/uipc_socket.c:1853 #12 0xc07a8763 in kern_recvit (td=0xc5992000, s=3, mp=0xe83e8c60, ---Type to continue, or q to quit--- fromseg=UIO_USERSPACE, controlp=0x0) at /usr/src/sys/kern/uipc_syscalls.c:986 #13 0xc07a8951 in recvit (td=Variable "td" is not available. ) at /usr/src/sys/kern/uipc_syscalls.c:1093 #14 0xc07a8ac6 in recvfrom (td=0xc5992000, uap=0xe83e8cfc) at /usr/src/sys/kern/uipc_syscalls.c:1137 #15 0xc0a0a063 in syscall (frame=0xe83e8d38) at /usr/src/sys/i386/i386/trap.c:1008 #16 0xc09f0f40 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #17 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) (kgdb) frame 9 #9 0xc0880114 in sctp_sorecvmsg (so=0xc70c3ad4, uio=0xe83e8bf4, mp=0x0, from=0xe83e8a8c, fromlen=256, msg_flags=0xe83e8c78, sinfo=0xe83e8a0c, filling_sinfo=0) at /usr/src/sys/netinet/sctputil.c:4881 4881 panic("Huh, its non zero and nothing on control?"); (kgdb) list 4876 hold_rlock = 1; 4877 } 4878 control = TAILQ_FIRST(&inp->read_queue); 4879 if ((control == NULL) && (so->so_rcv.sb_cc != 0)) { 4880 #ifdef INVARIANTS 4881 panic("Huh, its non zero and nothing on control?"); 4882 #endif 4883 so->so_rcv.sb_cc = 0; 4884 } 4885 SCTP_INP_READ_UNLOCK(inp); (kgdb) -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 23:07:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50DFA16A417 for ; Mon, 17 Sep 2007 23:07:21 +0000 (UTC) (envelope-from w0lfie@clear.net.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id 2EDEB13C48D for ; Mon, 17 Sep 2007 23:07:19 +0000 (UTC) (envelope-from w0lfie@clear.net.nz) Received: from clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with SMTP id <0JOJ00IZSC87VV00@smtp5.clear.net.nz> for freebsd-current@freebsd.org; Tue, 18 Sep 2007 11:07:19 +1200 (NZST) Date: Tue, 18 Sep 2007 11:07:19 +1200 From: Sam Banks Sender: w0lfie@clear.net.nz To: freebsd-current@freebsd.org Message-id: <46ef08a7.39.4605.24269@clear.net.nz> X-Mailer: CLEAR Net WebMail; webmail.clear.net.nz; user: w0lfie; ip: 202.78.240.7 Priority: normal Cc: Bruce Cran , "Sam Fourman Jr." , Ali Mashtizadeh , Stefan Ehmann Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: w0lfie@clear.net.nz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 23:07:21 -0000 Out of interest, what USB host controller are each of you running? UHCI or OHCI? Sam. ----- Original Message Follows ----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 01:52:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEE7616A418 for ; Tue, 18 Sep 2007 01:52:35 +0000 (UTC) (envelope-from dengxf@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 8457A13C48A for ; Tue, 18 Sep 2007 01:52:35 +0000 (UTC) (envelope-from dengxf@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2215021waf for ; Mon, 17 Sep 2007 18:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:subject:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; bh=P+ea6lxOAtaCeuL8qSTcIEhzH17YX3FZbStI/xsFncc=; b=HUd8Lj+/RL1rAkidXlBdgS86sUn5wxwdZMC+WbsI2J3yQRXhpPpgO5jPFWnKBpihze5U9p4ho9TZ+OJXBK3f3aMPm1Z2AzB2t7+WZ/1pWt1lXzgnRkhcdyuR99AIZIVCRbJqj/+FvwUdbjHcrYDFmAwqRH5kSvEhZQf/871U17Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; b=T0an3ShcxozXM8r/NSl7XbbWAamQdFCfpg+9wavLOBMUWSyppcuoOt+aiZidiJsOMraRw7tjt8OklfIf4UV4QatagigKmQOfV75H29nCZAWUccPP47N6dv8za9jOBYM2VR0KnutTHNDiKXSXSsPPOlMa3mGKTMf/m5eYWqM29XU= Received: by 10.114.78.1 with SMTP id a1mr2201900wab.1190080354531; Mon, 17 Sep 2007 18:52:34 -0700 (PDT) Received: from ?127.0.0.1? ( [218.94.128.114]) by mx.google.com with ESMTPS id j15sm5433494waf.2007.09.17.18.52.29 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Sep 2007 18:52:32 -0700 (PDT) Date: Tue, 18 Sep 2007 09:52:31 +0800 From: Deng XueFeng To: freebsd-current@freebsd.org, peterjeremy@optushome.com.au Message-Id: <20070918095036.1B14.DENGXF@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_46EF2EEC1B12036963D0_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.31 [CN] X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Fw: Re: using unix domain socket get ENOTCONN in both 6.2 and 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 01:52:36 -0000 --------_46EF2EEC1B12036963D0_MULTIPART_MIXED_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable forgot cc.... =D3=C9 Deng XueFeng =D7=AA=B7=A2=A3=BA ----------------------- =D4=AD=D3=CA=BC=FE=C6=F0=CA=BC=CE=BB --------------= --------- From: "Deng XueFeng" To: "Peter Jeremy" Date: Mon, 17 Sep 2007 21:06:33 +0800 Subject: Re: using unix domain socket get ENOTCONN in both 6.2 and 7.0 ---- yes, i do not chech anything, because i want create a race between close(2) and write(2) int the parent process, the write(2) should not return ENOTCONN. in 2005, there was one like this: http://lists.freebsd.org/pipermail/freebsd-bugs/2005-March/012123.html 2007/9/17, Peter Jeremy : > > On 2007-Sep-17 16:12:41 +0800, Deng XueFeng wrote: > >then I write a test program, and can reproduce in 6.2 and 7.0 > > Read() and write() do not preserve message boundaries so you cannot > guarantee to read 8193 bytes just because you wrote 8193 bytes. > > >#./ud_test > >child recv len [4992] failed: Unknown error: 0 > > This is an error in your program: The read() succeeded and returned > 4992 bytes. The child then exits > > >main send len [-1] failed: Socket is not connected > > Which leaves the socket unconnected so the parent (correctly) receives > an error. > > -- > Peter Jeremy > > --------------------- =D4=AD=D3=CA=BC=FE=BD=E1=CA=F8=CE=BB ----------------= ---- --=20 Deng XueFeng --------_46EF2EEC1B12036963D0_MULTIPART_MIXED_ Content-Disposition: attachment; filename=forward.html Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" yes, i do not chech anything, because i want create a race between close(2) and write(2) int the parent process, the write(2) should not return ENOTCONN. in 2005, there was one like this: [1]http://lists.freebsd.org/pipermail/freebsd-bugs/2005-March/012123.h tml 2007/9/17, Peter Jeremy <[2]peterjeremy@optushome.com.au>: On 2007-Sep-17 16:12:41 +0800, Deng XueFeng <[3]dengxf@gmail.com> wrote: >then I write a test program, and can reproduce in 6.2 and 7.0 Read() and write() do not preserve message boundaries so you cannot guarantee to read 8193 bytes just because you wrote 8193 bytes. >#./ud_test >child recv len [4992] failed: Unknown error: 0 This is an error in your program: The read() succeeded and returned 4992 bytes. The child then exits >main send len [-1] failed: Socket is not connected Which leaves the socket unconnected so the parent (correctly) receives an error. -- Peter Jeremy References 1. http://lists.freebsd.org/pipermail/freebsd-bugs/2005-March/012123.html 2. mailto:peterjeremy@optushome.com.au 3. mailto:dengxf@gmail.com --------_46EF2EEC1B12036963D0_MULTIPART_MIXED_-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 03:23:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34B2B16A417 for ; Tue, 18 Sep 2007 03:23:04 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7017F13C442 for ; Tue, 18 Sep 2007 03:23:03 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1303652nfb for ; Mon, 17 Sep 2007 20:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=zpb0slbWG1SemGSasJVwM3aI4XLtfZL/mwWZLS6k2XA=; b=B/gwiFC7JE0Vkv6e+hME9Op7OQUb8ipx7VXRXLtX0yz2Vs6I/U9dfMS3jUmxjh3oGDq5VA1MbgRbu+QtWxQqquZhQM6aj2iCEjW7xzncZapwKYik/C8BuUocujJQFbWWC4jmV/vPt3h1XQ1WWtxRU9T5Uq6m/PYAbb8OalqhAH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Lfe/qyRjrEXiNBTKEaabQeNimnXK1HlssNWPD4j9ePWX+MEwR5ZgzXUkh+uZGRnAhbbbqFtzPTEl6K89/E4W/MmCrL5Ejan1Itvk1D0H4mEWjZYmUhHM49JOBGbzlVvxNtUu0m74cszDy4qT+HCOYXy7adeIkFRpFSSm3rwScrI= Received: by 10.86.60.7 with SMTP id i7mr4272113fga.1190085772291; Mon, 17 Sep 2007 20:22:52 -0700 (PDT) Received: by 10.86.52.6 with HTTP; Mon, 17 Sep 2007 20:22:52 -0700 (PDT) Message-ID: <11167f520709172022p3a714750u52913641383d1937@mail.gmail.com> Date: Mon, 17 Sep 2007 22:22:52 -0500 From: "Sam Fourman Jr." To: w0lfie@clear.net.nz In-Reply-To: <46ef08a7.39.4605.24269@clear.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46ef08a7.39.4605.24269@clear.net.nz> Cc: Bruce Cran , Ali Mashtizadeh , freebsd-current@freebsd.org, Stefan Ehmann Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 03:23:04 -0000 On 9/17/07, Sam Banks wrote: > Out of interest, what USB host controller are each of you > running? UHCI or OHCI? > > Sam. Here is my Full dmesg for -current , don't ask me what the tcp errors are at the end I have no idea. if someone knows please drop me a hint on how to fix it. Sam Fourman Jr. Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-20070814-SNAP #0: Tue Aug 14 10:20:29 UTC 2007 root@builder.snapshots.us.freebsd.org:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2399.99-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 4 real memory = 2146369536 (2046 MB) avail memory = 2082390016 (1985 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 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) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fdf0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est3 attach returned 6 p4tcc3: on cpu3 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 1.4 (no driver attached) pci0: at device 1.5 (no driver attached) pci0: at device 1.6 (no driver attached) pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) pci0: at device 2.2 (no driver attached) pcib1: at device 3.0 on pci0 pci1: on pcib1 nvidia0: port 0xdf00-0xdf7f mem 0xec000000-0xecffffff,0xd0000000-0xdfffffff,0xea000000-0xebffffff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcib2: at device 6.0 on pci0 pci2: on pcib2 pcib3: at device 7.0 on pci0 pci3: on pcib3 pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) ohci0: mem 0xeffff000-0xefffffff irq 21 at device 11.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xefffe000-0xefffe0ff irq 22 at device 11.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 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 13.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem 0xefffd000-0xefffdfff irq 23 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf200-0xf20f mem 0xefffc000-0xefffcfff irq 20 at device 14.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xf100-0xf107,0xf000-0xf003,0xef00-0xef07,0xee00-0xee03,0xed00-0xed0f mem 0xefffb000-0xefffbfff irq 21 at device 14.2 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] pcib4: at device 15.0 on pci0 pci4: on pcib4 fwohci0: port 0xcf00-0xcf7f mem 0xefbff000-0xefbff7ff irq 19 at device 11.0 on pci4 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:01:1e:3d:ab fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:d8:1e:3d:ab fwe0: Ethernet address: 02:11:d8:1e:3d:ab fwip0: on firewire0 fwip0: Firewire address: 00:11:d8:00:01:1e:3d:ab @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7d920000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pcm0: mem 0xefff0000-0xefff3fff irq 22 at device 15.1 on pci0 pcm0: [ITHREAD] nfe0: port 0xec00-0xec07 mem 0xefffa000-0xefffafff,0xefff9000-0xefff90ff,0xefff8000-0xefff800f irq 23 at device 17.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:1a:92:46:e0:44 nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe1: port 0xeb00-0xeb07 mem 0xefff7000-0xefff7fff,0xefff6000-0xefff60ff,0xefff5000-0xefff500f irq 20 at device 18.0 on pci0 miibus1: on nfe1 e1000phy1: PHY 1 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe1: Ethernet address: 00:1a:92:46:ed:f7 nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] pcib5: at device 19.0 on pci0 pci5: on pcib5 pcib6: at device 20.0 on pci0 pci6: on pcib6 pcib7: at device 21.0 on pci0 pci7: on pcib7 pcib8: at device 22.0 on pci0 pci8: on pcib8 atapci4: port 0x6f00-0x6f7f mem 0xef2ff000-0xef2ff07f,0xef2f8000-0xef2fbfff irq 16 at device 0.0 on pci8 atapci4: [ITHREAD] ata8: on atapci4 ata8: [ITHREAD] ata9: on atapci4 ata9: [ITHREAD] pcib9: at device 23.0 on pci0 pci9: on pcib9 pcib10: at device 24.0 on pci0 pci10: on pcib10 acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd3fff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. 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 uhub2: on uhub0 uhub2: 4 ports with 2 removable, bus powered ukbd0: on uhub2 kbd2 at ukbd0 uhid0: on uhub2 uhid1: on uhub2 ums0: on uhub0 ums0: 8 buttons and Z dir. 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 UDMA66 acd1: CDRW at ata0-slave UDMA33 ad4: 152627MB at ata2-master SATA300 ad6: 152627MB at ata3-master SATA300 ad8: 152627MB at ata4-master SATA300 pcm0: pcm0: SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad8s1a TCP: [65.87.18.131]:443 to [192.168.0.46]:57437 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received data after socket was closed, sending RST and removing tcpcb TCP: [65.87.18.131]:443 to [192.168.0.46]:51816 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received data after socket was closed, sending RST and removing tcpcb TCP: [64.233.167.147]:80 to [192.168.0.46]:64551 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received data after socket was closed, sending RST and removing tcpcb TCP: [64.233.167.147]:80 to [192.168.0.46]:54477 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received data after socket was closed, sending RST and removing tcpcb TCP: [64.233.167.147]:80 to [192.168.0.46]:58252 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received data after socket was closed, sending RST and removing tcpcb TCP: [65.87.24.34]:80 to [192.168.0.46]:51475 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received data after socket was closed, sending RST and removing tcpcb TCP: [65.87.24.34]:80 to [192.168.0.46]:57558 tcpflags 0x10; tcp_do_segment: FIN_WAIT_1: Received data after socket was closed, sending RST and removing tcpcb TCP: [64.233.167.147]:80 to [192.168.0.46]:65081 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received data after socket was closed, sending RST and removing tcpcb TCP: [212.241.194.1]:80 to [192.168.0.46]:49845 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received data after socket was closed, sending RST and removing tcpcb TCP: [144.171.20.25]:80 to [192.168.0.46]:57822 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received data after socket was closed, sending RST and removing tcpcb TCP: [205.130.197.120]:80 to [192.168.0.46]:64545 tcpflags 0x19; tcp_do_segment: FIN_WAIT_2: Received data after socket was closed, sending RST and removing tcpcb TCP: [64.233.167.104]:80 to [192.168.0.46]:58216 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received data after socket was closed, sending RST and removing tcpcb TCP: [66.150.96.119]:80 to [192.168.0.46]:61711 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received data after socket was closed, sending RST and removing tcpcb TCP: [8.15.32.24]:80 to [192.168.0.46]:60810 tcpflags 0x10; tcp_do_segment: FIN_WAIT_1: Received data after socket was closed, sending RST and removing tcpcb From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 03:55:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA9C916A41B for ; Tue, 18 Sep 2007 03:55:21 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB5C13C46C for ; Tue, 18 Sep 2007 03:55:21 +0000 (UTC) (envelope-from tomdean@speakeasy.org) Received: (qmail 27287 invoked from network); 18 Sep 2007 03:55:08 -0000 Received: from dsl081-173-150.sea1.dsl.speakeasy.net (HELO dv6000.tddhome) ([64.81.173.150]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 18 Sep 2007 03:55:07 -0000 Received: from dv6000.tddhome (localhost [127.0.0.1]) by dv6000.tddhome (8.14.1/8.14.1) with ESMTP id l8I3t5Jl057025; Mon, 17 Sep 2007 20:55:05 -0700 (PDT) (envelope-from tomdean@dv6000.tddhome) Received: (from tomdean@localhost) by dv6000.tddhome (8.14.1/8.14.1/Submit) id l8I3t5rw057022; Mon, 17 Sep 2007 20:55:05 -0700 (PDT) (envelope-from tomdean) Date: Mon, 17 Sep 2007 20:55:05 -0700 (PDT) Message-Id: <200709180355.l8I3t5rw057022@dv6000.tddhome> From: "Thomas D. Dean" To: sfourman@gmail.com In-reply-to: <11167f520709172022p3a714750u52913641383d1937@mail.gmail.com> (sfourman@gmail.com) References: <46ef08a7.39.4605.24269@clear.net.nz> <11167f520709172022p3a714750u52913641383d1937@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 03:55:21 -0000 I see a similar problem in -stable and -current on an HP Pavillion dv6446 notebook. I have a Logitech wireless USB receiver with a keyboard and mouse. The keyboard led's do not function, for either the local or wireless keyboard when the Logitech receiver is connnected. dmesg below. tomdean Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #2: Sat Sep 15 11:31:41 PDT 2007 root@dv6000.tddhome:/scratch/obj/usr/usr/src/sys/SMP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) Duo CPU T2450 @ 2.00GHz (1995.61-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6ec Stepping = 12 Features=0xbfe9fbff Features2=0xc189,> AMD Features=0x100000 Cores per package: 2 real memory = 2137456640 (2038 MB) avail memory = 2086514688 (1989 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 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 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 2000 acpi0: Power Button (fixed) acpi0: reservation of fed00000, 400 (3) failed 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 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: port 0x1800-0x1807 mem 0xd8100000-0xd817ffff,0xc0000000-0xcfffffff,0xd8200000-0xd823ffff irq 16 at device 2.0 on pci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M pci0: at device 2.1 (no driver attached) pci0: at device 27.0 (no driver attached) pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 pci2: at device 0.0 (no driver attached) pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 uhci0: port 0x1820-0x183f irq 23 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 0x1840-0x185f 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 0x1860-0x187f 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 uhci3: port 0x1880-0x189f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd8444000-0xd84443ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered ugen0: Sonix Technology Co., Ltd. USB 2.0 Camera, rev 2.00/2.10, addr 2 pcib3: at device 30.0 on pci0 pci5: on pcib3 fwohci0: <1394 Open Host Controller Interface> mem 0xd8001000-0xd80017ff irq 16 at device 5.0 on pci5 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:24:1b:00:bb:30:23: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:30:23:00 fwe0: Ethernet address: 02:24:1b:30:23:00 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci5: at device 5.1 (no driver attached) pci5: at device 5.2 (no driver attached) pci5: at device 5.3 (no driver attached) pci5: at device 5.4 (no driver attached) fxp0: port 0x4000-0x403f mem 0xd8000000-0xd8000fff irq 20 at device 8.0 on pci5 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:1b:24:49:da:97 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xd8444400-0xd84447ff irq 19 at device 31.2 on pci0 atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata3: on atapci1 ata4: on atapci1 ata5: on atapci1 pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 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, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xce800-0xcffff,0xdf000-0xdf7ff,0xe0000-0xe17ff on isa0 ppc0: parallel port not found. 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 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding 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 ukbd0: Logitech USB Receiver, rev 1.10/38.10, addr 2, iclass 3/1 kbd2 at ukbd0 ums0: Logitech USB Receiver, rev 1.10/38.10, addr 2, iclass 3/1 ums0: 8 buttons and Z dir. Timecounters tick every 1.000 msec acd0: DVDR at ata0-master PIO4 ad4: 152627MB at ata2-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a fxp0: link state changed to UP drmsub0: : (child of agp_i810.c) on agp0 info: [drm] AGP at 0xd8100000 0MB info: [drm] Initialized i915 1.5.0 20060119 fxp0: link state changed to DOWN fxp0: link state changed to UP fxp0: link state changed to DOWN fxp0: link state changed to UP From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 05:17:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48B5916A419 for ; Tue, 18 Sep 2007 05:17:09 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id E7DAA13C46A for ; Tue, 18 Sep 2007 05:17:08 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (cran1.demon.co.uk [80.177.26.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id 0F9E030122; Tue, 18 Sep 2007 06:16:45 +0100 (BST) Message-ID: <46EF5EB9.1040001@cran.org.uk> Date: Tue, 18 Sep 2007 06:14:33 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: w0lfie@clear.net.nz References: <46ef08a7.39.4605.24269@clear.net.nz> In-Reply-To: <46ef08a7.39.4605.24269@clear.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Sam Fourman Jr." , Ali Mashtizadeh , freebsd-current@freebsd.org, Stefan Ehmann Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 05:17:09 -0000 Sam Banks wrote: > Out of interest, what USB host controller are each of you > running? UHCI or OHCI? > It's a VIA UHCI controller: uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered -- Bruce From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 05:33:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4A3C16A419 for ; Tue, 18 Sep 2007 05:33:26 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6DD13C45A for ; Tue, 18 Sep 2007 05:33:26 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (cran1.demon.co.uk [80.177.26.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id 2DAC030122; Tue, 18 Sep 2007 06:32:18 +0100 (BST) Message-ID: <46EF622F.9000702@cran.org.uk> Date: Tue, 18 Sep 2007 06:29:19 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: w0lfie@clear.net.nz References: <46ef08a7.39.4605.24269@clear.net.nz> In-Reply-To: <46ef08a7.39.4605.24269@clear.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Sam Fourman Jr." , Ali Mashtizadeh , freebsd-current@freebsd.org, Stefan Ehmann Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 05:33:26 -0000 Sam Banks wrote: > Out of interest, what USB host controller are each of you > running? UHCI or OHCI? > > Sam. > I tried connecting the same keyboard to my Dell Inspiron 1501 laptop, with similar results. Interestingly the built-in keyboard indicator lights on the laptop changed and worked as expected when I pressed the keys on the USB keyboard, but the ones on the USB keyboard didn't - the caps lock button came on once and then none of the lights changed after that. usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 uhub0: 2 ports with 2 removable, self powered ukbd0: on uhub0 kbd2 at ukbd0 -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 05:35:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00F6A16A418 for ; Tue, 18 Sep 2007 05:35:09 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.freebsd.org (Postfix) with ESMTP id BBA8A13C48A for ; Tue, 18 Sep 2007 05:35:07 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.232.62]) by natial.ongs.co.jp (Postfix) with ESMTP id 723CD244C19; Tue, 18 Sep 2007 14:35:02 +0900 (JST) Message-ID: <46EF6386.9050700@ongs.co.jp> Date: Tue, 18 Sep 2007 14:35:02 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: Kurt Jaeger , freebsd-stable@freebsd.org, FreeBSD Current References: <200709141103.18612.h.schmalzbauer@omnisec.de> <20070914110024.G14481@fledge.watson.org> <46EBEA18.3080800@ongs.co.jp> <20070915170104.GF2061@home.c0mplx.org> In-Reply-To: <20070915170104.GF2061@home.c0mplx.org> Content-Type: multipart/mixed; boundary="------------070007080303020601050807" Cc: Subject: Re: Unionfs patchset p19 commit? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 05:35:09 -0000 This is a multi-part message in MIME format. --------------070007080303020601050807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kurt Jaeger wrote: > Hi! > >> I have a big hope to get merged into FreeBSD until >> 7-RELEASE. Progress is step by step slowly, but going >> forward absolutely. If you have interest in unionfs >> improvements, push your passion to re@ and fs@ committers ;-) > > Did you have a chance to look into this ? > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-June/035798.html > > Thanks! Already we have fixed above issue. But it is not in a first merge patches bunch. FAI, I include a patch that has should been patched after p19. Try it. (unionfs6 for stable, unionfs for current). First, we should merge current unionfs patch into current tree. Above issue patch will be merged after that work. Well, whatsoever, we should do first merge work done :) -- Daichi GOTO, http://people.freebsd.org/~daichi --------------070007080303020601050807 Content-Type: text/x-patch; name="unionfs6-20070712.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="unionfs6-20070712.diff" diff -urBN /usr/src.p19/sys/fs/unionfs/union.h /usr/src/sys/fs/unionfs/union.h --- /usr/src.p19/sys/fs/unionfs/union.h Thu Jul 12 21:01:05 2007 +++ /usr/src/sys/fs/unionfs/union.h Thu Jul 12 22:20:51 2007 @@ -84,7 +84,12 @@ struct vnode *un_uppervp; /* upper side vnode */ struct vnode *un_dvp; /* parent unionfs vnode */ struct vnode *un_vnode; /* Back pointer */ - LIST_HEAD(, unionfs_node_status) un_unshead; /* unionfs status head */ + LIST_HEAD(, unionfs_node_status) un_unshead; + /* unionfs status head */ + LIST_HEAD(unionfs_node_hashhead, unionfs_node) *un_hashtbl; + /* dir vnode hash table */ + LIST_ENTRY(unionfs_node) un_hash; /* hash list entry */ + u_long un_hashmask; /* bit mask */ char *un_path; /* path */ int un_flag; /* unionfs node flag */ }; diff -urBN /usr/src.p19/sys/fs/unionfs/union_subr.c /usr/src/sys/fs/unionfs/union_subr.c --- /usr/src.p19/sys/fs/unionfs/union_subr.c Thu Jul 12 21:01:05 2007 +++ /usr/src/sys/fs/unionfs/union_subr.c Thu Jul 12 22:20:51 2007 @@ -60,6 +60,9 @@ #include +#define NUNIONFSNODECACHE 16 + +static MALLOC_DEFINE(M_UNIONFSHASH, "UNIONFS hash", "UNIONFS hash table"); MALLOC_DEFINE(M_UNIONFSNODE, "UNIONFS node", "UNIONFS vnode private part"); MALLOC_DEFINE(M_UNIONFSPATH, "UNIONFS path", "UNIONFS path private part"); @@ -82,6 +85,117 @@ return (0); } +static struct unionfs_node_hashhead * +unionfs_get_hashhead(struct vnode *dvp, char *path) +{ + int count; + char hash; + struct unionfs_node *unp; + + hash = 0; + unp = VTOUNIONFS(dvp); + if (path != NULL) { + for (count = 0; path[count]; count++) + hash += path[count]; + } + + return (&(unp->un_hashtbl[hash & (unp->un_hashmask)])); +} + +/* + * Get the cached vnode. (only VDIR) + */ +static struct vnode * +unionfs_get_cached_vdir(struct vnode *uvp, struct vnode *lvp, + struct vnode *dvp, char *path) +{ + struct unionfs_node_hashhead *hd; + struct unionfs_node *unp; + struct vnode *vp; + + KASSERT((uvp == NULLVP || uvp->v_type == VDIR), + ("unionfs_get_cached_vdir: v_type != VDIR")); + KASSERT((lvp == NULLVP || lvp->v_type == VDIR), + ("unionfs_get_cached_vdir: v_type != VDIR")); + + VI_LOCK(dvp); + hd = unionfs_get_hashhead(dvp, path); + LIST_FOREACH(unp, hd, un_hash) { + if (!strcmp(unp->un_path, path)) { + vp = UNIONFSTOV(unp); + VI_LOCK_FLAGS(vp, MTX_DUPOK); + VI_UNLOCK(dvp); + vp->v_iflag &= ~VI_OWEINACT; + if ((vp->v_iflag & (VI_DOOMED | VI_DOINGINACT)) != 0) { + VI_UNLOCK(vp); + vp = NULLVP; + } else + VI_UNLOCK(vp); + return (vp); + } + } + VI_UNLOCK(dvp); + + return (NULLVP); +} + +/* + * Add the new vnode into cache. (only VDIR) + */ +static struct vnode * +unionfs_ins_cached_vdir(struct unionfs_node *uncp, + struct vnode *dvp, char *path) +{ + struct unionfs_node_hashhead *hd; + struct unionfs_node *unp; + struct vnode *vp; + + KASSERT((uncp->un_uppervp==NULLVP || uncp->un_uppervp->v_type==VDIR), + ("unionfs_ins_cached_vdir: v_type != VDIR")); + KASSERT((uncp->un_lowervp==NULLVP || uncp->un_lowervp->v_type==VDIR), + ("unionfs_ins_cached_vdir: v_type != VDIR")); + + VI_LOCK(dvp); + hd = unionfs_get_hashhead(dvp, path); + LIST_FOREACH(unp, hd, un_hash) { + if (!strcmp(unp->un_path, path)) { + vp = UNIONFSTOV(unp); + VI_LOCK_FLAGS(vp, MTX_DUPOK); + vp->v_iflag &= ~VI_OWEINACT; + if ((vp->v_iflag & (VI_DOOMED | VI_DOINGINACT)) != 0) { + LIST_INSERT_HEAD(hd, uncp, un_hash); + VI_UNLOCK(vp); + vp = NULLVP; + } else + VI_UNLOCK(vp); + VI_UNLOCK(dvp); + return (vp); + } + } + + LIST_INSERT_HEAD(hd, uncp, un_hash); + VI_UNLOCK(dvp); + + return (NULLVP); +} + +/* + * Remove the vnode. (only VDIR) + */ +static void +unionfs_rem_cached_vdir(struct unionfs_node *unp, struct vnode *dvp) +{ + KASSERT((unp != NULL), ("unionfs_rem_cached_vdir: null node")); + KASSERT((dvp != NULLVP), + ("unionfs_rem_cached_vdir: null parent vnode")); + KASSERT((unp->un_hash.le_prev != NULL), + ("unionfs_rem_cached_vdir: null hash")); + + VI_LOCK(dvp); + LIST_REMOVE(unp, un_hash); + VI_UNLOCK(dvp); +} + /* * Make a new or get existing unionfs node. * @@ -100,21 +214,36 @@ struct vnode *vp; int error; int lkflags; + enum vtype vt; char *path; ump = MOUNTTOUNIONFSMOUNT(mp); lkflags = (cnp ? cnp->cn_lkflags : 0); path = (cnp ? cnp->cn_nameptr : NULL); + *vpp = NULLVP; if (uppervp == NULLVP && lowervp == NULLVP) panic("unionfs_nodeget: upper and lower is null"); + vt = (uppervp != NULLVP ? uppervp->v_type : lowervp->v_type); + /* If it has no ISLASTCN flag, path check is skipped. */ if (cnp && !(cnp->cn_flags & ISLASTCN)) path = NULL; + /* check the vdir cache */ + if (path != NULL && dvp != NULLVP && vt == VDIR) { + vp = unionfs_get_cached_vdir(uppervp, lowervp, dvp, path); + if (vp != NULLVP) { + vref(vp); + *vpp = vp; + goto unionfs_nodeget_out; + } + } + if ((uppervp == NULLVP || ump->um_uppervp != uppervp) || (lowervp == NULLVP || ump->um_lowervp != lowervp)) { + /* dvp will be NULLVP only in case of root vnode. */ if (dvp == NULLVP) return (EINVAL); } @@ -134,10 +263,18 @@ } if (dvp != NULLVP) vref(dvp); - if (uppervp != NULLVP) + if (uppervp != NULLVP) { vref(uppervp); - if (lowervp != NULLVP) + vkernref(uppervp); + } + if (lowervp != NULLVP) { vref(lowervp); + vkernref(lowervp); + } + + if (vt == VDIR) + unp->un_hashtbl = hashinit(NUNIONFSNODECACHE, M_UNIONFSHASH, + &(unp->un_hashmask)); unp->un_vnode = vp; unp->un_uppervp = uppervp; @@ -148,24 +285,46 @@ else vp->v_vnlock = lowervp->v_vnlock; - if (path) { + if (path != NULL) { unp->un_path = (char *) malloc(cnp->cn_namelen +1, M_UNIONFSPATH, M_WAITOK|M_ZERO); bcopy(cnp->cn_nameptr, unp->un_path, cnp->cn_namelen); unp->un_path[cnp->cn_namelen] = '\0'; } - vp->v_type = (uppervp != NULLVP ? uppervp->v_type : lowervp->v_type); + vp->v_type = vt; vp->v_data = unp; if ((uppervp != NULLVP && ump->um_uppervp == uppervp) && (lowervp != NULLVP && ump->um_lowervp == lowervp)) vp->v_vflag |= VV_ROOT; + if (path != NULL && dvp != NULLVP && vt == VDIR) + *vpp = unionfs_ins_cached_vdir(unp, dvp, path); + if ((*vpp) != NULLVP) { + if (dvp != NULLVP) + vrele(dvp); + if (uppervp != NULLVP) { + vkernrele(uppervp); + vrele(uppervp); + } + if (lowervp != NULLVP) { + vkernrele(lowervp); + vrele(lowervp); + } + + unp->un_uppervp = NULLVP; + unp->un_lowervp = NULLVP; + unp->un_dvp = NULLVP; + vrele(vp); + vp = *vpp; + vref(vp); + } else + *vpp = vp; + +unionfs_nodeget_out: if (lkflags & LK_TYPE_MASK) vn_lock(vp, lkflags | LK_RETRY, td); - *vpp = vp; - return (0); } @@ -180,6 +339,7 @@ struct unionfs_node_status *unsp, *unsp_tmp; struct vnode *lvp; struct vnode *uvp; + struct vnode *dvp; /* * Use the interlock to protect the clearing of v_data to @@ -189,6 +349,7 @@ unp = VTOUNIONFS(vp); lvp = unp->un_lowervp; uvp = unp->un_uppervp; + dvp = unp->un_dvp; unp->un_lowervp = unp->un_uppervp = NULLVP; vp->v_vnlock = &(vp->v_lock); @@ -200,27 +361,35 @@ VOP_UNLOCK(uvp, 0, td); vp->v_object = NULL; + if (unp->un_path != NULL && dvp != NULLVP && vp->v_type == VDIR) + unionfs_rem_cached_vdir(unp, dvp); + if (lvp != NULLVP) { vfslocked = VFS_LOCK_GIANT(lvp->v_mount); + vkernrele(lvp); vrele(lvp); VFS_UNLOCK_GIANT(vfslocked); } if (uvp != NULLVP) { vfslocked = VFS_LOCK_GIANT(uvp->v_mount); + vkernrele(uvp); vrele(uvp); VFS_UNLOCK_GIANT(vfslocked); } - if (unp->un_dvp != NULLVP) { - vfslocked = VFS_LOCK_GIANT(unp->un_dvp->v_mount); - vrele(unp->un_dvp); + if (dvp != NULLVP) { + vfslocked = VFS_LOCK_GIANT(dvp->v_mount); + vrele(dvp); VFS_UNLOCK_GIANT(vfslocked); unp->un_dvp = NULLVP; } - if (unp->un_path) { + if (unp->un_path != NULL) { free(unp->un_path, M_UNIONFSPATH); unp->un_path = NULL; } + if (unp->un_hashtbl != NULL) + hashdestroy(unp->un_hashtbl, M_UNIONFSHASH, unp->un_hashmask); + LIST_FOREACH_SAFE(unsp, &(unp->un_unshead), uns_list, unsp_tmp) { LIST_REMOVE(unsp, uns_list); free(unsp, M_TEMP); @@ -536,13 +705,16 @@ int count, lockcnt; struct vnode *vp; struct vnode *lvp; + struct vnode *dvp; vp = UNIONFSTOV(unp); lvp = unp->un_lowervp; + dvp = unp->un_dvp; /* * lock update */ + vkernref(uvp); VI_LOCK(vp); unp->un_uppervp = uvp; vp->v_vnlock = uvp->v_vnlock; @@ -552,6 +724,19 @@ VI_UNLOCK(vp); for (count = 1; count < lockcnt; count++) vn_lock(uvp, LK_EXCLUSIVE | LK_CANRECURSE | LK_RETRY, td); + + /* + * cache update + */ + if (unp->un_path != NULL && dvp != NULLVP && vp->v_type == VDIR) { + static struct unionfs_node_hashhead *hd; + + VI_LOCK(dvp); + hd = unionfs_get_hashhead(dvp, unp->un_path); + LIST_REMOVE(unp, un_hash); + LIST_INSERT_HEAD(hd, unp, un_hash); + VI_UNLOCK(dvp); + } } /* diff -urBN /usr/src.p19/sys/kern/vfs_subr.c /usr/src/sys/kern/vfs_subr.c --- /usr/src.p19/sys/kern/vfs_subr.c Thu Jul 12 20:17:25 2007 +++ /usr/src/sys/kern/vfs_subr.c Thu Jul 12 22:20:51 2007 @@ -944,6 +944,7 @@ vp->v_tag = tag; vp->v_op = vops; v_incr_usecount(vp); + vp->v_kernusecount = 0; vp->v_data = 0; #ifdef MAC mac_init_vnode(vp); @@ -2063,6 +2064,8 @@ VNASSERT(vp->v_writecount < vp->v_usecount || vp->v_usecount < 1, vp, ("vrele: missed vn_close")); + if (vp->v_usecount <= vp->v_kernusecount) + panic("vrele: kernel is referring to it"); if (vp->v_usecount > 1 || ((vp->v_iflag & VI_DOINGINACT) && vp->v_usecount == 1)) { v_decr_usecount(vp); @@ -2102,6 +2105,32 @@ } /* + * Increase the reference count of a vnode used by kernel. + */ +void +vkernref(struct vnode *vp) +{ + VI_LOCK(vp); + if (vp->v_usecount <= vp->v_kernusecount) + panic("vkernref: vkernref call without vref"); + vp->v_kernusecount++; + VI_UNLOCK(vp); +} + +/* + * Decrease the reference count of a vnode used by kernel. + */ +void +vkernrele(struct vnode *vp) +{ + VI_LOCK(vp); + if (vp->v_kernusecount < 1) + panic("vkernrele: negative kern ref count"); + vp->v_kernusecount--; + VI_UNLOCK(vp); +} + +/* * Release an already locked vnode. This give the same effects as * unlock+vrele(), but takes less time and avoids releasing and * re-aquiring the lock (as vrele() aquires the lock internally.) @@ -2336,7 +2365,8 @@ * * If FORCECLOSE is set, forcibly close the vnode. */ - if (vp->v_usecount == 0 || (flags & FORCECLOSE)) { + if ((vp->v_usecount == 0 || (flags & FORCECLOSE)) && + vp->v_kernusecount == 0) { VNASSERT(vp->v_usecount == 0 || (vp->v_type != VCHR && vp->v_type != VBLK), vp, ("device VNODE %p is FORCECLOSED", vp)); diff -urBN /usr/src.p19/sys/sys/vnode.h /usr/src/sys/sys/vnode.h --- /usr/src.p19/sys/sys/vnode.h Thu Jul 12 20:17:31 2007 +++ /usr/src/sys/sys/vnode.h Thu Jul 12 22:20:51 2007 @@ -162,6 +162,7 @@ struct lock *v_vnlock; /* u pointer to vnode lock */ int v_holdcnt; /* i prevents recycling. */ int v_usecount; /* i ref count of users */ + int v_kernusecount; /* i ref count of kernel */ u_long v_iflag; /* i vnode flags (see below) */ u_long v_vflag; /* v vnode flags */ int v_writecount; /* v ref count of writers */ @@ -704,6 +705,8 @@ | (noffset > osize ? NOTE_EXTEND : 0)); \ } +void vkernrele(struct vnode *vp); +void vkernref(struct vnode *vp); void vput(struct vnode *vp); void vrele(struct vnode *vp); void vref(struct vnode *vp); --------------070007080303020601050807 Content-Type: text/x-patch; name="unionfs-20070712.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="unionfs-20070712.diff" diff -urBN /usr/src.p19/sys/fs/unionfs/union.h /usr/src/sys/fs/unionfs/union.h --- /usr/src.p19/sys/fs/unionfs/union.h 2007-07-10 01:38:29.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union.h 2007-07-12 19:48:06.000000000 +0900 @@ -83,7 +83,12 @@ struct vnode *un_uppervp; /* upper side vnode */ struct vnode *un_dvp; /* parent unionfs vnode */ struct vnode *un_vnode; /* Back pointer */ - LIST_HEAD(, unionfs_node_status) un_unshead; /* unionfs status head */ + LIST_HEAD(, unionfs_node_status) un_unshead; + /* unionfs status head */ + LIST_HEAD(unionfs_node_hashhead, unionfs_node) *un_hashtbl; + /* dir vnode hash table */ + LIST_ENTRY(unionfs_node) un_hash; /* hash list entry */ + u_long un_hashmask; /* bit mask */ char *un_path; /* path */ int un_flag; /* unionfs node flag */ }; diff -urBN /usr/src.p19/sys/fs/unionfs/union_subr.c /usr/src/sys/fs/unionfs/union_subr.c --- /usr/src.p19/sys/fs/unionfs/union_subr.c 2007-07-10 01:38:16.000000000 +0900 +++ /usr/src/sys/fs/unionfs/union_subr.c 2007-07-12 21:57:09.000000000 +0900 @@ -60,6 +60,9 @@ #include +#define NUNIONFSNODECACHE 16 + +static MALLOC_DEFINE(M_UNIONFSHASH, "UNIONFS hash", "UNIONFS hash table"); MALLOC_DEFINE(M_UNIONFSNODE, "UNIONFS node", "UNIONFS vnode private part"); MALLOC_DEFINE(M_UNIONFSPATH, "UNIONFS path", "UNIONFS path private part"); @@ -82,6 +85,117 @@ return (0); } +static struct unionfs_node_hashhead * +unionfs_get_hashhead(struct vnode *dvp, char *path) +{ + int count; + char hash; + struct unionfs_node *unp; + + hash = 0; + unp = VTOUNIONFS(dvp); + if (path != NULL) { + for (count = 0; path[count]; count++) + hash += path[count]; + } + + return (&(unp->un_hashtbl[hash & (unp->un_hashmask)])); +} + +/* + * Get the cached vnode. (only VDIR) + */ +static struct vnode * +unionfs_get_cached_vdir(struct vnode *uvp, struct vnode *lvp, + struct vnode *dvp, char *path) +{ + struct unionfs_node_hashhead *hd; + struct unionfs_node *unp; + struct vnode *vp; + + KASSERT((uvp == NULLVP || uvp->v_type == VDIR), + ("unionfs_get_cached_vdir: v_type != VDIR")); + KASSERT((lvp == NULLVP || lvp->v_type == VDIR), + ("unionfs_get_cached_vdir: v_type != VDIR")); + + VI_LOCK(dvp); + hd = unionfs_get_hashhead(dvp, path); + LIST_FOREACH(unp, hd, un_hash) { + if (!strcmp(unp->un_path, path)) { + vp = UNIONFSTOV(unp); + VI_LOCK_FLAGS(vp, MTX_DUPOK); + VI_UNLOCK(dvp); + vp->v_iflag &= ~VI_OWEINACT; + if ((vp->v_iflag & (VI_DOOMED | VI_DOINGINACT)) != 0) { + VI_UNLOCK(vp); + vp = NULLVP; + } else + VI_UNLOCK(vp); + return (vp); + } + } + VI_UNLOCK(dvp); + + return (NULLVP); +} + +/* + * Add the new vnode into cache. (only VDIR) + */ +static struct vnode * +unionfs_ins_cached_vdir(struct unionfs_node *uncp, + struct vnode *dvp, char *path) +{ + struct unionfs_node_hashhead *hd; + struct unionfs_node *unp; + struct vnode *vp; + + KASSERT((uncp->un_uppervp==NULLVP || uncp->un_uppervp->v_type==VDIR), + ("unionfs_ins_cached_vdir: v_type != VDIR")); + KASSERT((uncp->un_lowervp==NULLVP || uncp->un_lowervp->v_type==VDIR), + ("unionfs_ins_cached_vdir: v_type != VDIR")); + + VI_LOCK(dvp); + hd = unionfs_get_hashhead(dvp, path); + LIST_FOREACH(unp, hd, un_hash) { + if (!strcmp(unp->un_path, path)) { + vp = UNIONFSTOV(unp); + VI_LOCK_FLAGS(vp, MTX_DUPOK); + vp->v_iflag &= ~VI_OWEINACT; + if ((vp->v_iflag & (VI_DOOMED | VI_DOINGINACT)) != 0) { + LIST_INSERT_HEAD(hd, uncp, un_hash); + VI_UNLOCK(vp); + vp = NULLVP; + } else + VI_UNLOCK(vp); + VI_UNLOCK(dvp); + return (vp); + } + } + + LIST_INSERT_HEAD(hd, uncp, un_hash); + VI_UNLOCK(dvp); + + return (NULLVP); +} + +/* + * Remove the vnode. (only VDIR) + */ +static void +unionfs_rem_cached_vdir(struct unionfs_node *unp, struct vnode *dvp) +{ + KASSERT((unp != NULL), ("unionfs_rem_cached_vdir: null node")); + KASSERT((dvp != NULLVP), + ("unionfs_rem_cached_vdir: null parent vnode")); + KASSERT((unp->un_hash.le_prev != NULL), + ("unionfs_rem_cached_vdir: null hash")); + + VI_LOCK(dvp); + LIST_REMOVE(unp, un_hash); + VI_UNLOCK(dvp); +} + /* * Make a new or get existing unionfs node. * @@ -100,21 +214,36 @@ struct vnode *vp; int error; int lkflags; + enum vtype vt; char *path; ump = MOUNTTOUNIONFSMOUNT(mp); lkflags = (cnp ? cnp->cn_lkflags : 0); path = (cnp ? cnp->cn_nameptr : NULL); + *vpp = NULLVP; if (uppervp == NULLVP && lowervp == NULLVP) panic("unionfs_nodeget: upper and lower is null"); + vt = (uppervp != NULLVP ? uppervp->v_type : lowervp->v_type); + /* If it has no ISLASTCN flag, path check is skipped. */ if (cnp && !(cnp->cn_flags & ISLASTCN)) path = NULL; + /* check the vdir cache */ + if (path != NULL && dvp != NULLVP && vt == VDIR) { + vp = unionfs_get_cached_vdir(uppervp, lowervp, dvp, path); + if (vp != NULLVP) { + vref(vp); + *vpp = vp; + goto unionfs_nodeget_out; + } + } + if ((uppervp == NULLVP || ump->um_uppervp != uppervp) || (lowervp == NULLVP || ump->um_lowervp != lowervp)) { + /* dvp will be NULLVP only in case of root vnode. */ if (dvp == NULLVP) return (EINVAL); } @@ -139,10 +268,18 @@ } if (dvp != NULLVP) vref(dvp); - if (uppervp != NULLVP) + if (uppervp != NULLVP) { vref(uppervp); - if (lowervp != NULLVP) + vkernref(uppervp); + } + if (lowervp != NULLVP) { vref(lowervp); + vkernref(lowervp); + } + + if (vt == VDIR) + unp->un_hashtbl = hashinit(NUNIONFSNODECACHE, M_UNIONFSHASH, + &(unp->un_hashmask)); unp->un_vnode = vp; unp->un_uppervp = uppervp; @@ -153,24 +290,46 @@ else vp->v_vnlock = lowervp->v_vnlock; - if (path) { + if (path != NULL) { unp->un_path = (char *) malloc(cnp->cn_namelen +1, M_UNIONFSPATH, M_WAITOK|M_ZERO); bcopy(cnp->cn_nameptr, unp->un_path, cnp->cn_namelen); unp->un_path[cnp->cn_namelen] = '\0'; } - vp->v_type = (uppervp != NULLVP ? uppervp->v_type : lowervp->v_type); + vp->v_type = vt; vp->v_data = unp; if ((uppervp != NULLVP && ump->um_uppervp == uppervp) && (lowervp != NULLVP && ump->um_lowervp == lowervp)) vp->v_vflag |= VV_ROOT; + if (path != NULL && dvp != NULLVP && vt == VDIR) + *vpp = unionfs_ins_cached_vdir(unp, dvp, path); + if ((*vpp) != NULLVP) { + if (dvp != NULLVP) + vrele(dvp); + if (uppervp != NULLVP) { + vkernrele(uppervp); + vrele(uppervp); + } + if (lowervp != NULLVP) { + vkernrele(lowervp); + vrele(lowervp); + } + + unp->un_uppervp = NULLVP; + unp->un_lowervp = NULLVP; + unp->un_dvp = NULLVP; + vrele(vp); + vp = *vpp; + vref(vp); + } else + *vpp = vp; + +unionfs_nodeget_out: if (lkflags & LK_TYPE_MASK) vn_lock(vp, lkflags | LK_RETRY, td); - *vpp = vp; - return (0); } @@ -185,6 +344,7 @@ struct unionfs_node_status *unsp, *unsp_tmp; struct vnode *lvp; struct vnode *uvp; + struct vnode *dvp; /* * Use the interlock to protect the clearing of v_data to @@ -194,6 +354,7 @@ unp = VTOUNIONFS(vp); lvp = unp->un_lowervp; uvp = unp->un_uppervp; + dvp = unp->un_dvp; unp->un_lowervp = unp->un_uppervp = NULLVP; vp->v_vnlock = &(vp->v_lock); @@ -205,27 +366,35 @@ VOP_UNLOCK(uvp, 0, td); vp->v_object = NULL; + if (unp->un_path != NULL && dvp != NULLVP && vp->v_type == VDIR) + unionfs_rem_cached_vdir(unp, dvp); + if (lvp != NULLVP) { vfslocked = VFS_LOCK_GIANT(lvp->v_mount); + vkernrele(lvp); vrele(lvp); VFS_UNLOCK_GIANT(vfslocked); } if (uvp != NULLVP) { vfslocked = VFS_LOCK_GIANT(uvp->v_mount); + vkernrele(uvp); vrele(uvp); VFS_UNLOCK_GIANT(vfslocked); } - if (unp->un_dvp != NULLVP) { - vfslocked = VFS_LOCK_GIANT(unp->un_dvp->v_mount); - vrele(unp->un_dvp); + if (dvp != NULLVP) { + vfslocked = VFS_LOCK_GIANT(dvp->v_mount); + vrele(dvp); VFS_UNLOCK_GIANT(vfslocked); unp->un_dvp = NULLVP; } - if (unp->un_path) { + if (unp->un_path != NULL) { free(unp->un_path, M_UNIONFSPATH); unp->un_path = NULL; } + if (unp->un_hashtbl != NULL) + hashdestroy(unp->un_hashtbl, M_UNIONFSHASH, unp->un_hashmask); + LIST_FOREACH_SAFE(unsp, &(unp->un_unshead), uns_list, unsp_tmp) { LIST_REMOVE(unsp, uns_list); free(unsp, M_TEMP); @@ -541,13 +710,16 @@ int count, lockcnt; struct vnode *vp; struct vnode *lvp; + struct vnode *dvp; vp = UNIONFSTOV(unp); lvp = unp->un_lowervp; + dvp = unp->un_dvp; /* * lock update */ + vkernref(uvp); VI_LOCK(vp); unp->un_uppervp = uvp; vp->v_vnlock = uvp->v_vnlock; @@ -557,6 +729,19 @@ VI_UNLOCK(vp); for (count = 1; count < lockcnt; count++) vn_lock(uvp, LK_EXCLUSIVE | LK_CANRECURSE | LK_RETRY, td); + + /* + * cache update + */ + if (unp->un_path != NULL && dvp != NULLVP && vp->v_type == VDIR) { + static struct unionfs_node_hashhead *hd; + + VI_LOCK(dvp); + hd = unionfs_get_hashhead(dvp, unp->un_path); + LIST_REMOVE(unp, un_hash); + LIST_INSERT_HEAD(hd, unp, un_hash); + VI_UNLOCK(dvp); + } } /* diff -urBN /usr/src.p19/sys/kern/vfs_subr.c /usr/src/sys/kern/vfs_subr.c --- /usr/src.p19/sys/kern/vfs_subr.c 2007-07-09 19:27:30.000000000 +0900 +++ /usr/src/sys/kern/vfs_subr.c 2007-07-12 21:58:26.000000000 +0900 @@ -953,6 +953,7 @@ vp->v_tag = tag; vp->v_op = vops; v_incr_usecount(vp); + vp->v_kernusecount = 0; vp->v_data = 0; #ifdef MAC mac_init_vnode(vp); @@ -2104,6 +2105,8 @@ VNASSERT(vp->v_writecount < vp->v_usecount || vp->v_usecount < 1, vp, ("vrele: missed vn_close")); + if (vp->v_usecount <= vp->v_kernusecount) + panic("vrele: kernel is referring to it"); if (vp->v_usecount > 1 || ((vp->v_iflag & VI_DOINGINACT) && vp->v_usecount == 1)) { v_decr_usecount(vp); @@ -2143,6 +2146,32 @@ } /* + * Increase the reference count of a vnode used by kernel. + */ +void +vkernref(struct vnode *vp) +{ + VI_LOCK(vp); + if (vp->v_usecount <= vp->v_kernusecount) + panic("vkernref: vkernref call without vref"); + vp->v_kernusecount++; + VI_UNLOCK(vp); +} + +/* + * Decrease the reference count of a vnode used by kernel. + */ +void +vkernrele(struct vnode *vp) +{ + VI_LOCK(vp); + if (vp->v_kernusecount < 1) + panic("vkernrele: negative kern ref count"); + vp->v_kernusecount--; + VI_UNLOCK(vp); +} + +/* * Release an already locked vnode. This give the same effects as * unlock+vrele(), but takes less time and avoids releasing and * re-aquiring the lock (as vrele() acquires the lock internally.) @@ -2373,7 +2402,8 @@ * * If FORCECLOSE is set, forcibly close the vnode. */ - if (vp->v_usecount == 0 || (flags & FORCECLOSE)) { + if ((vp->v_usecount == 0 || (flags & FORCECLOSE)) && + vp->v_kernusecount == 0) { VNASSERT(vp->v_usecount == 0 || (vp->v_type != VCHR && vp->v_type != VBLK), vp, ("device VNODE %p is FORCECLOSED", vp)); diff -urBN /usr/src.p19/sys/sys/vnode.h /usr/src/sys/sys/vnode.h --- /usr/src.p19/sys/sys/vnode.h 2007-07-09 19:28:14.000000000 +0900 +++ /usr/src/sys/sys/vnode.h 2007-07-12 19:48:27.000000000 +0900 @@ -162,6 +162,7 @@ struct lock *v_vnlock; /* u pointer to vnode lock */ int v_holdcnt; /* i prevents recycling. */ int v_usecount; /* i ref count of users */ + int v_kernusecount; /* i ref count of kernel */ u_long v_iflag; /* i vnode flags (see below) */ u_long v_vflag; /* v vnode flags */ int v_writecount; /* v ref count of writers */ @@ -706,6 +707,8 @@ #define VOP_LOCK(vp, flags, td) VOP_LOCK1(vp, flags, td, __FILE__, __LINE__) +void vkernrele(struct vnode *vp); +void vkernref(struct vnode *vp); void vput(struct vnode *vp); void vrele(struct vnode *vp); void vref(struct vnode *vp); --------------070007080303020601050807-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 05:38:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2643716A417 for ; Tue, 18 Sep 2007 05:38:47 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id C663813C48E for ; Tue, 18 Sep 2007 05:38:46 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (cran1.demon.co.uk [80.177.26.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id 97703303CB; Tue, 18 Sep 2007 06:38:08 +0100 (BST) Message-ID: <46EF6385.2000002@cran.org.uk> Date: Tue, 18 Sep 2007 06:35:01 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: w0lfie@clear.net.nz References: <46ef08a7.39.4605.24269@clear.net.nz> In-Reply-To: <46ef08a7.39.4605.24269@clear.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Sam Fourman Jr." , Ali Mashtizadeh , freebsd-current@freebsd.org, Stefan Ehmann Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 05:38:47 -0000 Sam Banks wrote: > Out of interest, what USB host controller are each of you > running? UHCI or OHCI? > > Sam. > I tried connecting the same keyboard to my Dell Inspiron 1501 laptop, with similar results. Interestingly the built-in keyboard indicator lights on the laptop changed and worked as expected when I pressed the keys on the USB keyboard, but the ones on the USB keyboard didn't - the caps lock button came on once and then none of the lights changed after that. usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 uhub0: 2 ports with 2 removable, self powered ukbd0: on uhub0 kbd2 at ukbd0 -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 06:44:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C95016A41B for ; Tue, 18 Sep 2007 06:44:59 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: from marklar.blazingdot.com (marklar.blazingdot.com [207.154.84.83]) by mx1.freebsd.org (Postfix) with SMTP id 2FCFE13C45B for ; Tue, 18 Sep 2007 06:44:59 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: (qmail 87852 invoked by uid 503); 18 Sep 2007 06:18:06 -0000 Date: Mon, 17 Sep 2007 23:18:06 -0700 From: Marcus Reid To: Roman Bogorodskiy Message-ID: <20070918061806.GA85425@blazingdot.com> References: <20070916061932.GA93480@underworld.novel.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070916061932.GA93480@underworld.novel.ru> X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.6i Cc: freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 06:44:59 -0000 On Sun, Sep 16, 2007 at 10:19:32AM +0400, Roman Bogorodskiy wrote: > Hello, > > I'm curious if SCHED_ULE is designed to be used on a desktop system. I'm > running -CURRENT at home and tried to use SCHED_ULE for some time. It > works alright while the load is not very high. But once I start > compiling something (running 'make buildworld' or 'portupgrade -a' for > example), the machine comes almost unusable - X11's windows takes a lot > of time to redraw, changing virtual desktop in window manager may take > a several seconds. And it's nearly impossible to watch some movie with > mplayer. I find SCHED_ULE to provide much better interactivity than SCHED_BSD on my desktop. Normally, I can have a couple of compiles and a bunch of other stuff going on in the background and I can't even feel it, and I'm on a UP p4. I can, however, reproduce what you're talking about. It's always something graphically intensive that gets it going, and it only happens when there's a couple of compiles running in the background. I tried to trigger it for hours doing a ton of stuff non-graphical, including running a couple of jobs that made it go a gig into swap. It handled everything nicely. However, every time I do something like start an opengl app and drag it around or start xlock, with compiles in the background, things get very stuttery. After closing the offending app, it continues to be like that for a while, and eventually corrects itself and goes back to normal. I suspected xorg was maybe blocking on some writes to something but looking at the kdump of xorg didn't reveal anything to me. > However, when I switch to SCHED_4BSD, system's reaction time gets lower > and I even can watch a movie with mplayer when compiling something. I haven't tried SCHED_4BSD yet. I'll have more time tomorrow. Marcus From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 19:25:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4951B16A421 for ; Mon, 17 Sep 2007 19:25:08 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.freebsd.org (Postfix) with ESMTP id E255213C457 for ; Mon, 17 Sep 2007 19:25:07 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (obsolete.xs4all.nl [82.95.250.254]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id l8HJD7mQ041153; Mon, 17 Sep 2007 21:13:07 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id l8HJD6f9013479; Mon, 17 Sep 2007 21:13:06 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id l8HJD6sN013478; Mon, 17 Sep 2007 21:13:06 +0200 (CEST) (envelope-from wb) Date: Mon, 17 Sep 2007 21:13:06 +0200 From: Wilko Bulte To: Hartmut Brandt Message-ID: <20070917191306.GA13449@freebie.xs4all.nl> References: <46EAA12D.4090207@ludd.ltu.se> <46EEC9AB.2010805@dlr.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46EEC9AB.2010805@dlr.de> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Tue, 18 Sep 2007 06:51:09 +0000 Cc: freebsd-current@freebsd.org, Anders Magnusson Subject: Re: Compiling with another compiler than gcc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 19:25:08 -0000 On Mon, Sep 17, 2007 at 08:38:35PM +0200, Hartmut Brandt wrote.. > Anders Magnusson wrote: > >It is not yet bug-free, but it can compile the i386 userspace. The big > >benefit of it > >(apart from that it's BSD licensed, for license geeks :-) is that it is > >fast, 5-10 times > >faster than gcc, while still producing reasonable code. The only > > When reading the name pcc my first thought was: isn't that the compiler > that was distributed on later Unix V7 tapes? And yes, the web-page says > it is based on that one. I'm quite sure that the original code had no > BSD copyright, so I wonder how it obtained one? For the rewritten code > there is no question, but what for the remaining original code? Has it > been relicensed by the original author? > > It's interesting that the compiler is so much faster than gcc. I > remember that it was around 3-5 times slower than the dmr compiler under > V7. This tells a lot about gcc's speed :-( Wanna try if that is still the case? I can drag the uPDP 11/73 from my basement. 2BSD on it and all that. 8-) -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Sep 17 23:34:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38C8816A419 for ; Mon, 17 Sep 2007 23:34:27 +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 1549813C481 for ; Mon, 17 Sep 2007 23:34:26 +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 1IXPrW-0003h7-O5 for freebsd-current@freebsd.org; Mon, 17 Sep 2007 16:18:42 -0700 Message-ID: <12747042.post@talk.nabble.com> Date: Mon, 17 Sep 2007 16:18:42 -0700 (PDT) From: Barnabas To: freebsd-current@freebsd.org In-Reply-To: <20070813204035.GA5338@stud.ntnu.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: barnabasdk@gmail.com References: <20070813204035.GA5338@stud.ntnu.no> X-Mailman-Approved-At: Tue, 18 Sep 2007 06:51:09 +0000 Subject: Re: Testers wanted: Gvinum patches of SoC 2007 work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 23:34:27 -0000 Hi Ulf I also use gvinum in a pretty complex setup, and would be happy to help in any testing, bug finding and whatever. I work as a developer - not exactly with kernel hacking - but I am not completely at a loss. I have had a lot of issues with the semi-finished version of gvinum that is currently available though the freebsd distro. I have had a lot of DMA read/write timeout issues lately. Especially under heavy load. But only on my ata drives - the scsi drives runs perfectly. First I thought it was a dead disk, but I have been seeing the issue on my new raid5 setup as well. The same issue on two disk at the same time is not very likely. If you have any info on how I am to patch the current vinum driver with the new changes you made it would be great. I really appreciate someone is looking at this exellent software. It has not really worked 100% since the port to geom was started. Heres my config: FreeBSD sauron.barnabas.dk 6.2-RELEASE-p6 FreeBSD 6.2-RELEASE-p6 #0: Wed Jul 18 23:33:58 CEST 2007 root@sauron.barnabas.dk:/usr/src/sys/i386/compile/KERNEL_6_2 i386 7 drives: D elben State: up /dev/da1s1h A: 0/7825 MB (0%) D donau State: up /dev/da0s1h A: 0/7825 MB (0%) D raid5_4 State: up /dev/ad11a A: 6/194480 MB (0%) D raid5_3 State: up /dev/ad10a A: 6/194480 MB (0%) D raid5_2 State: up /dev/ad9a A: 6/194480 MB (0%) D raid5_1 State: up /dev/ad8a A: 6/194480 MB (0%) D spree State: up /dev/ad4a A: 3/114473 MB (0%) 6 volumes: V raid5 State: up Plexes: 1 Size: 569 GB V data01 State: up Plexes: 1 Size: 111 GB V usr State: up Plexes: 2 Size: 5625 MB V home State: up Plexes: 2 Size: 1000 MB V tmp State: up Plexes: 2 Size: 600 MB V var State: up Plexes: 2 Size: 600 MB 10 plexes: P raid5.p0 R5 State: degraded Subdisks: 4 Size: 569 GB P data01.p0 C State: up Subdisks: 1 Size: 111 GB P usr.p1 C State: up Subdisks: 1 Size: 5625 MB P home.p1 C State: up Subdisks: 1 Size: 1000 MB P tmp.p1 C State: up Subdisks: 1 Size: 600 MB P var.p1 C State: up Subdisks: 1 Size: 600 MB P usr.p0 C State: up Subdisks: 1 Size: 5625 MB P home.p0 C State: up Subdisks: 1 Size: 1000 MB P tmp.p0 C State: up Subdisks: 1 Size: 600 MB P var.p0 C State: up Subdisks: 1 Size: 600 MB 13 subdisks: S raid5.p0.s3 State: stale D: raid5_4 Size: 189 GB S raid5.p0.s2 State: up D: raid5_3 Size: 189 GB S raid5.p0.s1 State: up D: raid5_2 Size: 189 GB S raid5.p0.s0 State: up D: raid5_1 Size: 189 GB S data01.p0.s0 State: up D: spree Size: 111 GB S usr.p1.s0 State: up D: elben Size: 5625 MB S home.p1.s0 State: up D: elben Size: 1000 MB S tmp.p1.s0 State: up D: elben Size: 600 MB S var.p1.s0 State: up D: elben Size: 600 MB S usr.p0.s0 State: up D: donau Size: 5625 MB S home.p0.s0 State: up D: donau Size: 1000 MB S tmp.p0.s0 State: up D: donau Size: 600 MB S var.p0.s0 State: up D: donau Size: 600 MB # Vinum configuration of sauron.barnabas.dk, saved at Tue Sep 18 01:11:49 2007 # Current configuration: # drive elben device /dev/da1s1h # drive donau device /dev/da0s1h # drive raid5_4 device /dev/ad11a # drive raid5_3 device /dev/ad10a # drive raid5_2 device /dev/ad9a # drive raid5_1 device /dev/ad8a # drive spree device /dev/ad4a # volume raid5 # volume data01 # volume usr # volume home # volume tmp # volume var # plex name raid5.p0 org raid5 2048s vol raid5 # plex name data01.p0 org concat vol data01 # plex name usr.p1 org concat vol usr # plex name home.p1 org concat vol home # plex name tmp.p1 org concat vol tmp # plex name var.p1 org concat vol var # plex name usr.p0 org concat vol usr # plex name home.p0 org concat vol home # plex name tmp.p0 org concat vol tmp # plex name var.p0 org concat vol var # sd name raid5.p0.s3 drive raid5_4 len 398282752s driveoffset 265s plex raid5.p0 plexoffset 6144s # sd name raid5.p0.s2 drive raid5_3 len 398282752s driveoffset 265s plex raid5.p0 plexoffset 4096s # sd name raid5.p0.s1 drive raid5_2 len 398282752s driveoffset 265s plex raid5.p0 plexoffset 2048s # sd name raid5.p0.s0 drive raid5_1 len 398282752s driveoffset 265s plex raid5.p0 plexoffset 0s # sd name data01.p0.s0 drive spree len 234434560s driveoffset 265s plex data01.p0 plexoffset 0s # sd name usr.p1.s0 drive elben len 11521427s driveoffset 4505865s plex usr.p1 plexoffset 0s # sd name home.p1.s0 drive elben len 2048000s driveoffset 2457865s plex home.p1 plexoffset 0s # sd name tmp.p1.s0 drive elben len 1228800s driveoffset 1229065s plex tmp.p1 plexoffset 0s # sd name var.p1.s0 drive elben len 1228800s driveoffset 265s plex var.p1 plexoffset 0s # sd name usr.p0.s0 drive donau len 11521427s driveoffset 4505865s plex usr.p0 plexoffset 0s # sd name home.p0.s0 drive donau len 2048000s driveoffset 2457865s plex home.p0 plexoffset 0s # sd name tmp.p0.s0 drive donau len 1228800s driveoffset 1229065s plex tmp.p0 plexoffset 0s # sd name var.p0.s0 drive donau len 1228800s driveoffset 265s plex var.p0 plexoffset 0s As you can tell the raid setup is not well. Here is some of the errors I have experienced: Sep 17 16:54:03 sauron kernel: subdisk10: detached Sep 17 16:54:03 sauron kernel: ad10: detached Sep 17 16:54:03 sauron kernel: ad11: FAILURE - device detached Sep 17 16:54:03 sauron kernel: subdisk11: detached Sep 17 16:54:03 sauron kernel: ad11: detached Sep 17 16:54:03 sauron kernel: GEOM_VINUM: subdisk raid5.p0.s3 state change: up -> down Sep 17 16:54:03 sauron kernel: GEOM_VINUM: plex raid5.p0 state change: up -> degraded Sep 17 16:54:03 sauron kernel: GEOM_VINUM: subdisk raid5.p0.s2 state change: up -> down Sep 17 16:54:03 sauron kernel: GEOM_VINUM: plex raid5.p0 state change: degraded -> down Sep 17 16:54:03 sauron kernel: GEOM_VINUM: lost drive 'raid5_3' Sep 17 23:20:58 sauron sshd[15009]: refused connect from host11-69-static.30-87-b.business.telecomitalia.it (87.30.69.11) Sep 17 23:22:12 sauron sshd[15039]: refused connect from host11-69-static.30-87-b.business.telecomitalia.it (87.30.69.11) Sep 18 00:00:42 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=536025710592, length=16384)]error = 6 Sep 18 00:00:42 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=536025726976, length=49152)]error = 6 Sep 18 00:00:42 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=536025776128, length=131072)]error = 6 Sep 18 00:00:44 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=535918395392, length=49152)]error = 6 Sep 18 00:00:53 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=536025710592, length=16384)]error = 6 Sep 18 00:00:53 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=536025726976, length=49152)]error = 6 Sep 18 00:00:53 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=536025776128, length=131072)]error = 6 Sep 18 00:00:53 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=535918395392, length=49152)]error = 6 Sep 18 00:01:00 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=528017391616, length=32768)]error = 6 Sep 18 00:01:00 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=528108421120, length=49152)]error = 6 Sep 18 00:01:10 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343853568, length=16384)]error = 6 Sep 18 00:01:10 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343869952, length=49152)]error = 6 Sep 18 00:01:10 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343919104, length=131072)]error = 6 Sep 18 00:01:11 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343853568, length=16384)]error = 6 Sep 18 00:01:11 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343869952, length=49152)]error = 6 Sep 18 00:01:11 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343919104, length=131072)]error = 6 Sep 18 00:01:11 sauron kernel: g_vfs_done():gvinum/raid5[WRITE(offset=511212584960, length=16384)]error = 6 Sep 18 00:01:11 sauron kernel: g_vfs_done():gvinum/raid5[WRITE(offset=527976808448, length=16384)]error = 6 Sep 18 00:01:11 sauron kernel: g_vfs_done():gvinum/raid5[WRITE(offset=535877189632, length=16384)]error = 6 Sep 18 00:01:13 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343853568, length=16384)]error = 6 Sep 18 00:01:13 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343869952, length=49152)]error = 6 Sep 18 00:01:13 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343919104, length=131072)]error = 6 Sep 18 00:01:15 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343853568, length=16384)]error = 6 Sep 18 00:01:15 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343869952, length=49152)]error = 6 Sep 18 00:01:15 sauron kernel: g_vfs_done():gvinum/raid5[READ(offset=511343919104, length=131072)]error = 6 I have seen exactly the same on the data01 disk that is stand alone. Hope I am able to help. Nikolaj Hansen Ulf Lilleengen-6 wrote: > > Hi, > > It's here! The new and hopefully better gvinum patch. This is perhaps my > final > patch of the work I've done during GSoC 2007 (the patch will be updated > when I > fix a bug). This doesn't mean I'll stop work on gvinum, but rather that > I'm not > adding more features until this gets into the tree. But, for this to get > into > the tree, I need people to test it. _ALL_ reports on how it works is good. > > So, what should you test? > > * Plain normal use. > > * Mirror synchronization, rebuild if raid-5 arrays, growing of raid-5 > arrays > etc. These should work, and probably is the most tested, but some weird > combinations that I have not forseen might show itself. > > * Try weird combinations to check if it crashes. > > * Test mirror, concat, stripe and raid5 commands. > > * If there are any issues with the usability aspect. E.g. if the > information > gvinum gives you is good enough for you to understand what it's doing, > if one > way to do things seems unnatural to you etc. I'd like to hear all of > this, no > matter how bikshedish it might sound, it might be something that have > been > overlooked. These things are hard to test for the people that have been > developing it, since we know how it "should" be used. > > Before you head on, beware that the new gvinum does not give messages back > to > the userland gvinum (so you won't get them into your terminal). This is > because > it's not very simple to do with the new event system. > !! This means you'll have to look after messages in /var/log/messages !! > > And thanks to people for comments and help that I've been getting during > the summer. > > -- > Ulf Lilleengen > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- View this message in context: http://www.nabble.com/Testers-wanted%3A-Gvinum-patches-of-SoC-2007-work-tf4263568.html#a12747042 Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 07:24:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6951D16A41A for ; Tue, 18 Sep 2007 07:24:43 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from martenvijn.nl (vijn.xs4all.nl [194.109.254.102]) by mx1.freebsd.org (Postfix) with ESMTP id D673C13C4D5 for ; Tue, 18 Sep 2007 07:24:42 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from [127.0.0.1] ([192.168.1.20]) by martenvijn.nl (8.13.8/8.13.4) with ESMTP id l8I7NHXJ091163; Tue, 18 Sep 2007 09:23:23 +0200 (CEST) (envelope-from info@martenvijn.nl) From: Marten Vijn To: Marinos Ilias In-Reply-To: <20070917151020.GA23939@ceid.upatras.gr> References: <20070917151020.GA23939@ceid.upatras.gr> Content-Type: text/plain Date: Tue, 18 Sep 2007 00:17:45 +0200 Message-Id: <1190067465.1246.3.camel@medion.martenvijn.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-3.0 (martenvijn.nl [192.168.1.2]); Tue, 18 Sep 2007 09:23:23 +0200 (CEST) Cc: freebsd-current@freebsd.org Subject: Re: crunchgen fials on sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 07:24:43 -0000 Thanks that helped I included these: %ldd -a /bin/sh /bin/sh: libedit.so.6 => /lib/libedit.so.6 (0x28095000) libncurses.so.7 => /lib/libncurses.so.7 (0x280aa000) libc.so.7 => /lib/libc.so.7 (0x280ec000) /lib/libedit.so.6: libncurses.so.7 => /lib/libncurses.so.7 (0x280aa000) Is there way to find to needed libs other than trail and error? Marten On Mon, 2007-09-17 at 18:10 +0300, Marinos Ilias wrote: > You may just need to link with flex library. ( -lfl for gcc). > For your case , try to add > libs -lfl > in your crunch.conf. > > > Hope that does the job for you, > > > Ilias Marinos > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 07:31:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 187A716A417 for ; Tue, 18 Sep 2007 07:31:46 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 4E61B13C48D for ; Tue, 18 Sep 2007 07:31:44 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 18 Sep 2007 07:31:41 -0000 Received: from h081217094222.dyn.cm.kabsi.at (EHLO taxman.pepperland) [81.217.94.222] by mail.gmx.net (mp018) with SMTP; 18 Sep 2007 09:31:41 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX19sCeEIICZsIXivhgZQT0D4y2haaRqaXDjaB/AJW0 noQ21f7L2Qg860 From: Stefan Ehmann To: freebsd-current@freebsd.org, w0lfie@clear.net.nz Date: Tue, 18 Sep 2007 09:31:39 +0200 User-Agent: KMail/1.9.7 References: <46ef08a7.39.4605.24269@clear.net.nz> In-Reply-To: <46ef08a7.39.4605.24269@clear.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709180931.40249.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: Bruce Cran , "Sam Fourman Jr." , Ali Mashtizadeh Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 07:31:46 -0000 On Tuesday 18 September 2007 01:07:19 Sam Banks wrote: > Out of interest, what USB host controller are each of you > running? UHCI or OHCI? UHCI here: uhci2: port 0x1860-0x187f irq 18 at device 29.2 on pci0 From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 07:42:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FCFA16A419; Tue, 18 Sep 2007 07:42:15 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id A98BB13C4A5; Tue, 18 Sep 2007 07:42:14 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8I7fwfC046494 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 03:41:59 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 18 Sep 2007 00:44:52 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Marcus Reid In-Reply-To: <20070918061806.GA85425@blazingdot.com> Message-ID: <20070918004027.G558@10.0.0.1> References: <20070916061932.GA93480@underworld.novel.ru> <20070918061806.GA85425@blazingdot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Roman Bogorodskiy Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 07:42:15 -0000 On Mon, 17 Sep 2007, Marcus Reid wrote: > On Sun, Sep 16, 2007 at 10:19:32AM +0400, Roman Bogorodskiy wrote: >> Hello, >> >> I'm curious if SCHED_ULE is designed to be used on a desktop system. I'm >> running -CURRENT at home and tried to use SCHED_ULE for some time. It >> works alright while the load is not very high. But once I start >> compiling something (running 'make buildworld' or 'portupgrade -a' for >> example), the machine comes almost unusable - X11's windows takes a lot >> of time to redraw, changing virtual desktop in window manager may take >> a several seconds. And it's nearly impossible to watch some movie with >> mplayer. > > I find SCHED_ULE to provide much better interactivity than SCHED_BSD on > my desktop. Normally, I can have a couple of compiles and a bunch of > other stuff going on in the background and I can't even feel it, and > I'm on a UP p4. I can, however, reproduce what you're talking about. > It's always something graphically intensive that gets it going, and it > only happens when there's a couple of compiles running in the background. > I tried to trigger it for hours doing a ton of stuff non-graphical, > including running a couple of jobs that made it go a gig into swap. > It handled everything nicely. However, every time I do something like > start an opengl app and drag it around or start xlock, with compiles > in the background, things get very stuttery. After closing the offending > app, it continues to be like that for a while, and eventually corrects > itself and goes back to normal. > Marcus, What has happened is that you have run an x application that is so expensive we no longer consider it interactive. Unfortunately, due to the nature of the x server architecture, much of the compute time is spent in x11 rather than the offending application. There really isn't anything to be done in this case other than mark X as real-time. You can try to tune up the interactivity heuristic limit by setting kern.sched.interact to a higher value. This will help with short term bursts of x server cpu utilization, however, sustained, expensive x windows processing will always trigger poorer interactive behavior. Thanks, Jeff > I suspected xorg was maybe blocking on some writes to something but > looking at the kdump of xorg didn't reveal anything to me. > >> However, when I switch to SCHED_4BSD, system's reaction time gets lower >> and I even can watch a movie with mplayer when compiling something. > > I haven't tried SCHED_4BSD yet. I'll have more time tomorrow. > > Marcus > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 09:34:10 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5ED816A420 for ; Tue, 18 Sep 2007 09:34:10 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6375113C4A6 for ; Tue, 18 Sep 2007 09:34:10 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from doc.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IXYwN-000Ijl-5j for current@FreeBSD.org; Tue, 18 Sep 2007 13:00:19 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IXYxo-000Bk3-6N for current@FreeBSD.org; Tue, 18 Sep 2007 13:01:48 +0400 To: current@FreeBSD.org From: Boris Samorodov Date: Tue, 18 Sep 2007 13:01:48 +0400 Message-ID: <41601395@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: twa: Request Requeued and Retrying Command X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 09:34:10 -0000 Hi! With recent -CURRENT I have (many): ----- ... (da1:twa0:0:1:0): Request Requeued (da1:twa0:0:1:0): Retrying Command (da1:twa0:0:1:0): Request Requeued (da1:twa0:0:1:0): Retrying Command (da0:twa0:0:0:0): Request Requeued (da0:twa0:0:0:0): Retrying Command ... ---- The kernel is GENERIC without INVARIANT* and WITNESS*. The controller: twa0: <3ware 9000 series Storage Controller> port 0x3000-0x30ff mem 0xd8000000-0xd9ffffff,0xda300000-0xda300fff irq 16 at device 0.0 on pci8 twa0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xda300000 twa0: [GIANT-LOCKED] twa0: [ITHREAD] twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 ports, Firmware FE9X 3.06.00.005, BIOS BE9X 3.06.00.002 Is it a hardware or a software problem? Thanks. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 09:47:37 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AD0E16A417 for ; Tue, 18 Sep 2007 09:47:37 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3C65D13C45E for ; Tue, 18 Sep 2007 09:47:37 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 297952219F5 for ; Tue, 18 Sep 2007 11:35:18 +0200 (CEST) Received: from fw.reifenberger.com (ppp-82-135-4-73.dynamic.mnet-online.de [82.135.4.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTP id 1E738903C8 for ; Tue, 18 Sep 2007 11:35:18 +0200 (CEST) Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.8/8.13.8/Submit) with ESMTP id l8I9ZHXK023153 for ; Tue, 18 Sep 2007 11:35:17 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Tue, 18 Sep 2007 11:35:17 +0200 (CEST) From: Michael Reifenberger To: FreeBSD-Current Message-ID: <20070918112947.P23117@fw.reifenberger.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: increase maxdsiz in jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 09:47:37 -0000 Hi, my amd64 host has the following limits: ... datasize 33554432 kB stacksize 1048576 kB ... but in jail/chroot i386 allways (seems to be fixed): ... datasize 524288 kB stacksize 65536 kB ... How can this limit be increased? Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 09:50:51 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ADD216A417 for ; Tue, 18 Sep 2007 09:50:51 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0B87213C461 for ; Tue, 18 Sep 2007 09:50:50 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 5B0DC221B0F; Tue, 18 Sep 2007 11:50:34 +0200 (CEST) Received: from fw.reifenberger.com (ppp-82-135-4-73.dynamic.mnet-online.de [82.135.4.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTP id 4C96B9032D; Tue, 18 Sep 2007 11:50:34 +0200 (CEST) Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.8/8.13.8/Submit) with ESMTP id l8I9oXxG023207; Tue, 18 Sep 2007 11:50:34 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Tue, 18 Sep 2007 11:50:33 +0200 (CEST) From: Michael Reifenberger To: Doug Ambrisko In-Reply-To: <200709172109.l8HL9uiZ015951@ambrisko.com> Message-ID: <20070918114357.F23171@fw.reifenberger.com> References: <200709172109.l8HL9uiZ015951@ambrisko.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Current Subject: Re: i386 package building on an amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 09:50:51 -0000 Hi, have you tried to recompile java/jdk15 under a i386 jail on amd64 host? I tried to use an formely i386 natively compiled jdk15 to recompile inside an jail. Using java '-server' failed early with an null pointer exception and '-client' later with an segmentation violation. (Probably running out of the default 512MB MAXDSIZ inside the jail) Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 12:27:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C283F16A417 for ; Tue, 18 Sep 2007 12:27:45 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.freebsd.org (Postfix) with ESMTP id 4835913C48D for ; Tue, 18 Sep 2007 12:27:45 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.14.1/8.13.1) with ESMTP id l8IBmuC6097943 for ; Tue, 18 Sep 2007 07:48:57 -0400 (EDT) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.14.1/8.13.1/Submit) id l8IBmpTX097942 for freebsd-current@freebsd.org; Tue, 18 Sep 2007 07:48:51 -0400 (EDT) (envelope-from bv) Date: Tue, 18 Sep 2007 07:48:51 -0400 From: Bill Vermillion To: freebsd-current@freebsd.org Message-ID: <20070918114851.GA95132@wjv.com> References: <20070918093418.88FC516A4E7@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070918093418.88FC516A4E7@hub.freebsd.org> User-Agent: Mutt/1.4.2.2i Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com Subject: Re: Compiling with another compiler than gcc - OT reply X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 12:27:45 -0000 On Tue, Sep 18, 2007 at 09:34 , freebsd-current-request@freebsd.org exclaimed "Las Cucarachas entran, Pero no pueden salir", and then rambled on saying with: > Date: Mon, 17 Sep 2007 23:30:06 +0200 > From: Hartmut Brandt > Subject: Re: Compiling with another compiler than gcc. > To: Wilko Bulte > Cc: freebsd-current@freebsd.org, Anders Magnusson > Wilko Bulte wrote: > > On Mon, Sep 17, 2007 at 08:38:35PM +0200, Hartmut Brandt wrote.. > >> Anders Magnusson wrote: [mucho deletia - wjv] > I've wrote an emulator for the KDJ11A (11/73 I think) more than 10 years > ago before I gave my machine to Grog. It runs RSX11M[+], RT11, v[567], > 2.11BSD at light speed :-) It's on people.freebsd.org/~harti. Compiles > 2.11BSD in less than an hour. It's probably easier than to put up your > 11/73 :-) > About pcc: I've a z8000 based computer with a Unix System III on which > uses pcc as the system compiler. It's so buggy that I wonder how the > system even runs. But I suppose these bugs are mostly in the z8000 > backend (no sources to check, though). pcc rang a bell. And was the Z8000 based computer with Unix Sysstem III running on it and Onyx. I had to do so many things to get things to compile correctly. For some reason it or the pre-processor like to sign extend commands even when parity was off, as it would set the parity bit and sign extend 8 bit commands to 16 bit - so instead of returning the correct info from the device which I was querying I would get all sorts of errors on SOME codes I sent. I found the sign extend by noting than only every other character in the ASCII set returned with an error. I got that fixed by masking the data sent or returned - I forget which - and I never had fond memories of that machine. There was no serial communications built it, so I took a Radio Shack Model 4 portable - with an early version of Kermit - running about 40K compiled - and set the transmission to pause 1 second between each line transmitted. That was because the only way to get things in was to use the 4 as a terminal, bring up vi, transfer at the slow rate, exit vi, and them compile kermit. THe next step was to transfer hundreds of update COBOL code into the machine. The only input to that was a 40MB tape and I think when I worked on this the machine was no longer supported. Bill -- Bill Vermillion - bv @ wjv . com From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 13:03:13 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B246716A419 for ; Tue, 18 Sep 2007 13:03:13 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6FD2B13C46B for ; Tue, 18 Sep 2007 13:03:13 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from doc.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IXcjQ-000JXz-DA for current@FreeBSD.org; Tue, 18 Sep 2007 17:03:12 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IXcks-000Btp-1b for current@FreeBSD.org; Tue, 18 Sep 2007 17:04:42 +0400 To: current@FreeBSD.org References: <41601395@srv.sem.ipt.ru> From: Boris Samorodov Date: Tue, 18 Sep 2007 17:04:42 +0400 In-Reply-To: <41601395@srv.sem.ipt.ru> (Boris Samorodov's message of "Tue\, 18 Sep 2007 13\:01\:48 +0400") Message-ID: <88003429@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: twa: Request Requeued and Retrying Command X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 13:03:13 -0000 On Tue, 18 Sep 2007 13:01:48 +0400 Boris Samorodov wrote: > With recent -CURRENT I have (many): > ----- > ... > (da1:twa0:0:1:0): Request Requeued > (da1:twa0:0:1:0): Retrying Command > (da1:twa0:0:1:0): Request Requeued > (da1:twa0:0:1:0): Retrying Command > (da0:twa0:0:0:0): Request Requeued > (da0:twa0:0:0:0): Retrying Command > ... > ---- > The kernel is GENERIC without INVARIANT* and WITNESS*. The same was with plain GENERIC. Hm, but *IFF* use a verbose logging. The last time the machine auto-booted and none of those messages did appear... Is it a known behaviour? > The controller: > twa0: <3ware 9000 series Storage Controller> port 0x3000-0x30ff mem 0xd8000000-0xd9ffffff,0xda300000-0xda300fff irq 16 at device 0.0 on pci8 > twa0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xda300000 > twa0: [GIANT-LOCKED] > twa0: [ITHREAD] > twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: > twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 ports, Firmware FE9X 3.06.00.005, BIOS BE9X 3.06.00.002 > Is it a hardware or a software problem? Apparently, the verbose mode has some effects on twa init. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 13:59:45 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D653916A421 for ; Tue, 18 Sep 2007 13:59:45 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 6303213C4CA for ; Tue, 18 Sep 2007 13:59:44 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l8IDxbDd012893 for ; Tue, 18 Sep 2007 17:59:37 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Tue, 18 Sep 2007 17:59:37 +0400 (MSD) From: Dmitry Morozovsky To: current@FreeBSD.org Message-ID: <20070918175749.I97108@woozle.rinet.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Tue, 18 Sep 2007 17:59:37 +0400 (MSD) Cc: Subject: Misterious tar errors on today's current/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 13:59:45 -0000 Hi there colleagues. marck@n5600:/usr/ports/archivers/rpm> uname -a FreeBSD n5600.rinet.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #4: Tue Sep 18 17:23:00 MSD 2007 marck@n5600.rinet.ru:/usr/obj/usr/src/sys/MINI amd64 (freshly built system) marck@n5600:/usr/ports/archivers/rpm> make ===> Patching for rpm-3.0.6_13 ===> Applying FreeBSD patches for rpm-3.0.6_13 1 out of 1 hunks failed--saving rejects to aclocal.m4.rej => Patch patch-av failed to apply cleanly. *** Error code 1 Stop in /usr/ports/archivers/rpm. marck@n5600:/usr/ports/archivers/rpm> l work/rpm-3.0.6/aclocal.m4* -rw-rw-r-- 1 marck wheel 6657 Sep 18 17:48 work/rpm-3.0.6/aclocal.m4 -rw-rw-r-- 1 marck wheel 6656 Sep 13 2000 work/rpm-3.0.6/aclocal.m4.orig -rw-rw-r-- 1 marck wheel 324 Sep 18 17:48 work/rpm-3.0.6/aclocal.m4.rej marck@n5600:/usr/ports/archivers/rpm> cd work/ marck@n5600:/usr/ports/archivers/rpm/work> rm -rf rpm-3.0.6/ marck@n5600:/usr/ports/archivers/rpm/work> tar tvzf /usr/ports/distfiles/rpm-3.0.6.tar.gz |grep aclocal -rw-rw-r-- 0 2161 2161 34470 Sep 13 2000 rpm-3.0.6/aclocal.m4 -rw-rw-r-- 0 2161 2161 34044 Sep 13 2000 rpm-3.0.6/popt/aclocal.m4 marck@n5600:/usr/ports/archivers/rpm/work> tar xzf /usr/ports/distfiles/rpm-3.0.6.tar.gz marck@n5600:/usr/ports/archivers/rpm/work> l rpm-3.0.6/acl* -rw-rw-r-- 1 marck wheel 6656 Sep 13 2000 rpm-3.0.6/aclocal.m4 So, aclocal.m4 does not extracted correctly. WTF? I'm out of ideas. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 15:11:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1ADC16A41B for ; Tue, 18 Sep 2007 15:11:16 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 8179213C4CE for ; Tue, 18 Sep 2007 15:11:16 +0000 (UTC) (envelope-from rrs@cisco.com) X-IronPort-AV: E=Sophos;i="4.20,269,1186383600"; d="scan'208";a="525164155" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 18 Sep 2007 08:11:04 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8IFB42b013467; Tue, 18 Sep 2007 08:11:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8IFB4pV016308; Tue, 18 Sep 2007 15:11:04 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 08:11:04 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 08:11:03 -0700 Message-ID: <46EFEA6D.20609@cisco.com> Date: Tue, 18 Sep 2007 11:10:37 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Atkinson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Sep 2007 15:11:03.0528 (UTC) FILETIME=[21176E80:01C7FA06] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6270; t=1190128264; x=1190992264; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20sctp=20panic=3A=20Huh, =20its=20non=20zero=20and=20not hing=20on=20control? |Sender:=20; bh=z2uVJmkrjxTvsYmv8+cjnp7iVqaa1kUM2D1nFqF5exA=; b=fGuoVM25vPtPyStaf4hHPYlohLRAhwUk3gn0g3EPpfAiTSHgoKJ2ISpdpQ37Z1qqQHJiO6Dq h9i0Ybs+Szr1edMaUXox7eaG6vJir+ygbdCKovPAAAl3FuB+rPrI5/Pt; Authentication-Results: sj-dkim-3; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Cc: freebsd-current@freebsd.org Subject: Re: sctp panic: Huh, its non zero and nothing on control? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 15:11:16 -0000 Mark: How old of version are you running? One of these type of panic's was removed a bit ago.. but there is still one case that will panic like this... And you should be able to run invariants and have it run (although a lot slower of course)... If your current to within say the end of the SCTP interop (which would have been the end of Aug) then lets speak offline and let me see if I can get a core from you and the kernel...etc.. this is one I would like to look at. If its quite old.. then can you sup and rerun? The case this flags can be repaired .. but it should NOT happen.. at least in theory.. if its the one occurance of this thats left. I am running on an 8 core machine (AMD64) and don't see this.. but thats not to say its not a problem :-) Let me know Thanks R Mark Atkinson wrote: > I got this panic today while testing sctp on a different target with this > box as a client, although the version of current is a little crusty (maybe > I should be running sctp without INVARIANTS?) > > FreeBSD 7.0-CURRENT #1: Fri Aug 10 08:14:46 PDT 2007 > > panic: Huh, its non zero and nothing on control? > cpuid = 1 > KDB: enter: panic > [thread pid 8815 tid 100130 ] > Stopped at kdb_enter+0x32: leave > db> > db> where > Tracing pid 8815 tid 100130 td 0xc5992000 > kdb_enter(c0aa11be,1,c0ab6a33,e83e8930,1,...) at kdb_enter+0x32 > panic(c0ab6a33,0,c0ab68a2,130b,c70c3b48,...) at panic+0x124 > sctp_sorecvmsg(c70c3ad4,e83e8bf4,0,e83e8a8c,100,...) at sctp_sorecvmsg+0x3e4 > sctp_soreceive(c70c3ad4,e83e8be8,e83e8bf4,0,0,...) at sctp_soreceive+0x9e > soreceive(c70c3ad4,e83e8be8,e83e8bf4,0,0,...) at soreceive+0x4d > kern_recvit(c5992000,3,e83e8c60,0,0,...) at kern_recvit+0x153 > recvit(0,c0aa2cd4,83b,bfbcdec8,3e8,0,0,e83e8c58,1,0,281aceb8,0) at > recvit+0x31 > recvfrom(c5992000,e83e8cfc,18,c0aa6ebd,c0b4ec18,...) at recvfrom+0x76 > syscall(e83e8d38) at syscall+0x2b3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (29, FreeBSD ELF32, recvfrom), eip = 0x281558e7, esp = > 0xbfbcddfc, ebp = 0xbfbcde28 --- > db> call doadump > Physical memory: 2034 MB > Dumping 278 MB: 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 > Dump complete > = 0xf > > > [root@marka-k8we K8WE]$ kgdb kernel.debug /var/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: > Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > panic: Huh, its non zero and nothing on control? > cpuid = 1 > KDB: enter: panic > Physical memory: 2034 MB > Dumping 278 MB: 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 > > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc048cbc9 in db_fncall (dummy1=-1065925454, dummy2=0, dummy3=-1, > dummy4=0xe83e8708 "") at /usr/src/sys/ddb/db_command.c:486 > #2 0xc048d135 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 > #3 0xc048e8b5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 > #4 0xc0774335 in kdb_trap (type=3, code=0, tf=0xe83e88b0) > at /usr/src/sys/kern/subr_kdb.c:502 > #5 0xc0a0a88f in trap (frame=0xe83e88b0) > at /usr/src/sys/i386/i386/trap.c:621 > #6 0xc09f0edb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc07744b2 in kdb_enter (msg=0xc0aa11be "panic") at cpufunc.h:60 > #8 0xc074bb54 in panic ( > fmt=0xc0ab6a33 "Huh, its non zero and nothing on control?") > at /usr/src/sys/kern/kern_shutdown.c:547 > #9 0xc0880114 in sctp_sorecvmsg (so=0xc70c3ad4, uio=0xe83e8bf4, mp=0x0, > from=0xe83e8a8c, fromlen=256, msg_flags=0xe83e8c78, sinfo=0xe83e8a0c, > filling_sinfo=0) at /usr/src/sys/netinet/sctputil.c:4881 > #10 0xc088186e in sctp_soreceive (so=0xc70c3ad4, psa=0xe83e8be8, > uio=0xe83e8bf4, mp0=0x0, controlp=0x0, flagsp=0xe83e8c78) > at /usr/src/sys/netinet/sctputil.c:5687 > #11 0xc07a240d in soreceive (so=0xc70c3ad4, psa=0xe83e8be8, uio=0xe83e8bf4, > mp0=0x0, controlp=0x0, flagsp=0xe83e8c78) > at /usr/src/sys/kern/uipc_socket.c:1853 > #12 0xc07a8763 in kern_recvit (td=0xc5992000, s=3, mp=0xe83e8c60, > ---Type to continue, or q to quit--- > fromseg=UIO_USERSPACE, controlp=0x0) > at /usr/src/sys/kern/uipc_syscalls.c:986 > #13 0xc07a8951 in recvit (td=Variable "td" is not available. > ) at /usr/src/sys/kern/uipc_syscalls.c:1093 > #14 0xc07a8ac6 in recvfrom (td=0xc5992000, uap=0xe83e8cfc) > at /usr/src/sys/kern/uipc_syscalls.c:1137 > #15 0xc0a0a063 in syscall (frame=0xe83e8d38) > at /usr/src/sys/i386/i386/trap.c:1008 > #16 0xc09f0f40 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:196 > #17 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > (kgdb) frame 9 > #9 0xc0880114 in sctp_sorecvmsg (so=0xc70c3ad4, uio=0xe83e8bf4, mp=0x0, > from=0xe83e8a8c, fromlen=256, msg_flags=0xe83e8c78, sinfo=0xe83e8a0c, > filling_sinfo=0) at /usr/src/sys/netinet/sctputil.c:4881 > 4881 panic("Huh, its non zero and nothing on > control?"); > (kgdb) list > 4876 hold_rlock = 1; > 4877 } > 4878 control = TAILQ_FIRST(&inp->read_queue); > 4879 if ((control == NULL) && (so->so_rcv.sb_cc != 0)) { > 4880 #ifdef INVARIANTS > 4881 panic("Huh, its non zero and nothing on > control?"); > 4882 #endif > 4883 so->so_rcv.sb_cc = 0; > 4884 } > 4885 SCTP_INP_READ_UNLOCK(inp); > (kgdb) -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 15:29:15 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A638416A468 for ; Tue, 18 Sep 2007 15:29:15 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1A18713C4A5 for ; Tue, 18 Sep 2007 15:29:14 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id l8IFRq87022851; Tue, 18 Sep 2007 17:27:57 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id l8IFRqH0022850; Tue, 18 Sep 2007 17:27:52 +0200 (CEST) (envelope-from olli) Date: Tue, 18 Sep 2007 17:27:52 +0200 (CEST) Message-Id: <200709181527.l8IFRqH0022850@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, mike@reifenberger.com In-Reply-To: <20070918112947.P23117@fw.reifenberger.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (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]); Tue, 18 Sep 2007 17:27:57 +0200 (CEST) Cc: Subject: Re: increase maxdsiz in jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, mike@reifenberger.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 15:29:15 -0000 Michael Reifenberger wrote: > my amd64 host has the following limits: > ... > datasize 33554432 kB > stacksize 1048576 kB > ... > > but in jail/chroot i386 allways (seems to be fixed): > ... > datasize 524288 kB > stacksize 65536 kB > ... > > How can this limit be increased? Have you checked etc/login.conf within the chroot? 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 I suggested holding a "Python Object Oriented Programming Seminar", but the acronym was unpopular. -- Joseph Strout From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 15:52:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E25C516A41B for ; Tue, 18 Sep 2007 15:52:27 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from mail.renet.ru (mail-local.renet.ru [82.116.32.21]) by mx1.freebsd.org (Postfix) with ESMTP id 0299C13C4A8 for ; Tue, 18 Sep 2007 15:52:26 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from localhost (dcss-08.dialup.virtual.int [172.19.101.8]) by mail.renet.ru (8.14.0/8.14.0) with ESMTP id l8IFqUg0033936; Tue, 18 Sep 2007 19:52:32 +0400 (MSD) (envelope-from novel@FreeBSD.org) Date: Tue, 18 Sep 2007 19:52:45 +0400 From: Roman Bogorodskiy To: Jeff Roberson Message-ID: <20070918155244.GA1336@underworld.novel.ru> References: <20070916061932.GA93480@underworld.novel.ru> <20070915234855.G531@10.0.0.1> <20070916071421.GA1320@underworld.novel.ru> <20070916003323.U4507@10.0.0.1> <20070917044351.GA17565@underworld.novel.ru> <20070917162400.GA42669@underworld.novel.ru> <20070917141820.M558@10.0.0.1> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <20070917141820.M558@10.0.0.1> X-PGP: http://people.freebsd.org/~novel/novel.key.asc Cc: freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 15:52:28 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jeff Roberson wrote: > On Mon, 17 Sep 2007, Roman Bogorodskiy wrote: >=20 >> Roman Bogorodskiy wrote: >>=20 >>> Jeff Roberson wrote: >>>=20 >>>> On Sun, 16 Sep 2007, Roman Bogorodskiy wrote: >>>>=20 >>>>> Jeff Roberson wrote: >>>>>=20 >>>>>> This is contrary to the experiences of many others. Can you send me= =20 >>>>>> your >>>>>> dmesg? There may be something about your particular hardware that is >>>>>> triggering a bug. ULE is definitely designed to be responsive on the >>>>>> desktop. >>>>>=20 >>>>> Thanks for the quick answer! >>>>>=20 >>>>> Here's my dmesg: http://people.freebsd.org/~novel/misc/dmesg.txt >>>>=20 >>>> Roman, >>>>=20 >>>> The enclosed patch helps things on my system, however, there are still= =20 >>>> some >>>> delays due to IO issues. Let me know if this helps. >>>=20 >>> This patch seems to make my system react faster. However I need some >>> time to test it more carefully. >>=20 >> It looks like it's not really so, it's still very slow under load. :( >=20 > Roman, >=20 > Can you please verify that you are not swapping. If you are, try the pat= ch=20 > that I sent. Otherwise, can you try getting KTR_SCHED output for me? Pu= t=20 > the following in your kernel config file: Swap is not used at all (and I don't use WITNESS, etc). I will run through the steps you wrote ASAP. > options KTR > options KTR_COMPILE=3DKTR_SCHED > options KTR_MASK=3DKTR_SCHED > options KTR_ENTRIES=3D65536 >=20 >=20 > Then run the load that exhibits the problem. compile, play a movie, etc.= =20 > wait for a particularly bad pause and then run the following: >=20 > sysctl debug.ktr.mask=3D0 && ktrdump -ct > out && sysctl=20 > debug.ktr.mask=3D536870 >=20 > It's best to have the command ready in a shell so you can run it in the= =20 > closest proximity to the incident. Then gzip the results and email them = to=20 > me. >=20 > On my system I'm not able to play a movie while running buildworld due to= =20 > long disk waits. However, if I use a dvd driver, mplayer and x windows= =20 > both get enough cpu time to play the movie skip free. So this is not a c= pu=20 > scheduler problem as such. IO scheduling does feel less responsive than= =20 > 6.x but I have not done a side by side comparison. >=20 > Jeff >=20 >>=20 >>>> Thanks, >>>> Jeff >>>>=20 >>>>>=20 >>>>> Roman Bogorodskiy >>>>>=20 >>>=20 >>>=20 >>> Roman Bogorodskiy >>=20 >>=20 >> Roman Bogorodskiy >>=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Roman Bogorodskiy --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iQCVAwUBRu/0TIB0WzgdqspGAQJzUAQAyiIIaBV5U1qqACdmSgUVmiT+7R0hxZs5 KaoORGrBtfI/YQc7drAkWf/B2cET36wlkjdZwQKA5abkMq/89dP9cOxnwJR+wAbc V9/jBamA6CF5IZV5/jWiGasGCbMsMyYmBsLX4Zd5SWykBEyaLGZOj4HSuzK/VARt hPic2AnI/T0= =+jVC -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 16:06:31 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A94816A41B for ; Tue, 18 Sep 2007 16:06:31 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 0675813C45B for ; Tue, 18 Sep 2007 16:06:30 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.storspeed.com (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l8IFshFK032975; Tue, 18 Sep 2007 10:54:46 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46EFF4C0.7070301@freebsd.org> Date: Tue, 18 Sep 2007 10:54:40 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Dmitry Morozovsky References: <20070918175749.I97108@woozle.rinet.ru> In-Reply-To: <20070918175749.I97108@woozle.rinet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: current@freebsd.org Subject: Re: Misterious tar errors on today's current/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 16:06:31 -0000 Dmitry Morozovsky wrote: > Hi there colleagues. > > > marck@n5600:/usr/ports/archivers/rpm> uname -a > FreeBSD n5600.rinet.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #4: Tue Sep 18 17:23:00 MSD 2007 marck@n5600.rinet.ru:/usr/obj/usr/src/sys/MINI amd64 > > (freshly built system) > > marck@n5600:/usr/ports/archivers/rpm> make > ===> Patching for rpm-3.0.6_13 > ===> Applying FreeBSD patches for rpm-3.0.6_13 > 1 out of 1 hunks failed--saving rejects to aclocal.m4.rej > => Patch patch-av failed to apply cleanly. > *** Error code 1 > > Stop in /usr/ports/archivers/rpm. > > marck@n5600:/usr/ports/archivers/rpm> l work/rpm-3.0.6/aclocal.m4* > -rw-rw-r-- 1 marck wheel 6657 Sep 18 17:48 work/rpm-3.0.6/aclocal.m4 > -rw-rw-r-- 1 marck wheel 6656 Sep 13 2000 work/rpm-3.0.6/aclocal.m4.orig > -rw-rw-r-- 1 marck wheel 324 Sep 18 17:48 work/rpm-3.0.6/aclocal.m4.rej > > marck@n5600:/usr/ports/archivers/rpm> cd work/ > marck@n5600:/usr/ports/archivers/rpm/work> rm -rf rpm-3.0.6/ > marck@n5600:/usr/ports/archivers/rpm/work> tar tvzf /usr/ports/distfiles/rpm-3.0.6.tar.gz |grep aclocal > -rw-rw-r-- 0 2161 2161 34470 Sep 13 2000 rpm-3.0.6/aclocal.m4 > -rw-rw-r-- 0 2161 2161 34044 Sep 13 2000 rpm-3.0.6/popt/aclocal.m4 > marck@n5600:/usr/ports/archivers/rpm/work> tar xzf /usr/ports/distfiles/rpm-3.0.6.tar.gz > marck@n5600:/usr/ports/archivers/rpm/work> l rpm-3.0.6/acl* > -rw-rw-r-- 1 marck wheel 6656 Sep 13 2000 rpm-3.0.6/aclocal.m4 > > So, aclocal.m4 does not extracted correctly. > > WTF? I'm out of ideas. Maybe try rolling these back: http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libarchive/archive_write_disk.c.diff?&r1=1.14&r2=1.15&f=h http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libarchive/test/test_write_disk.c.diff?&r1=1.3&r2=1.4&f=h Eric From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 16:24:32 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFF5E16A417 for ; Tue, 18 Sep 2007 16:24:32 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9298C13C46A for ; Tue, 18 Sep 2007 16:24:32 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 52EA022DE8A; Tue, 18 Sep 2007 18:24:31 +0200 (CEST) Received: from fw.reifenberger.com (ppp-82-135-4-73.dynamic.mnet-online.de [82.135.4.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTP id 47A6690383; Tue, 18 Sep 2007 18:24:31 +0200 (CEST) Received: from localhost (mike@localhost) by fw.reifenberger.com (8.13.8/8.13.8/Submit) with ESMTP id l8IGOUl6024516; Tue, 18 Sep 2007 18:24:30 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Tue, 18 Sep 2007 18:24:30 +0200 (CEST) From: Michael Reifenberger To: freebsd-current@FreeBSD.ORG, mike@reifenberger.com In-Reply-To: <200709181527.l8IFRqH0022850@lurza.secnetix.de> Message-ID: <20070918182013.P24397@fw.reifenberger.com> References: <200709181527.l8IFRqH0022850@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: increase maxdsiz in jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 16:24:32 -0000 On Tue, 18 Sep 2007, Oliver Fromme wrote: ... > Have you checked etc/login.conf within the chroot? > Yes. But now I found the sysctl: compat.ia32.maxdsiz This seems to work. (but doesn't solve the "compile jdk15 inside the i386/jail problem"). Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 16:42:39 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5DA716A419 for ; Tue, 18 Sep 2007 16:42:39 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id B3BEA13C46E for ; Tue, 18 Sep 2007 16:42:39 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.68] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l8IGgUcQ018491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 09:42:31 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <46EFFF96.1040101@FreeBSD.org> Date: Tue, 18 Sep 2007 09:40:54 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dmitry Morozovsky References: <20070914124630.D14000@woozle.rinet.ru> <46EEC481.5010503@FreeBSD.org> <20070918011258.L96165@woozle.rinet.ru> In-Reply-To: <20070918011258.L96165@woozle.rinet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: i386 package building on an amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 16:42:40 -0000 Dmitry Morozovsky wrote: > On Mon, 17 Sep 2007, Maxim Sobolev wrote: > > MS> > possibly stupid question: it there a way to fool jail (real, not > MS> > "tinderbox" one) that it's working under i386 kernel? This would be > MS> > extremely useful for local package building. > MS> > > MS> > Quick googling does not reveal anything, or did I miss something obvious? > MS> > > MS> > Thanks in advance. > MS> > MS> Works here like a charm. The only thing is that you need to set UNAME_p=i386 > MS> UNAME_m=i386 and CPUTYPE=i686 variables in the chroot/jail. > > I know aboot uname tricks ;-) > > What about sysctls revealing amd64 system internals? Did you compare packages > built by this jailed system with native? Any package that uses some sysctls from build machine to somehow alter build process should be considered b0rken. -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 17:07:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59E8216A417 for ; Tue, 18 Sep 2007 17:07:57 +0000 (UTC) (envelope-from tmseck-lists@netcologne.de) Received: from smtp2.netcologne.de (smtp2.netcologne.de [194.8.194.112]) by mx1.freebsd.org (Postfix) with ESMTP id 1AF0113C461 for ; Tue, 18 Sep 2007 17:07:56 +0000 (UTC) (envelope-from tmseck-lists@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-213-196-225-204.netcologne.de [213.196.225.204]) by smtp2.netcologne.de (Postfix) with SMTP id 8DA835503 for ; Tue, 18 Sep 2007 19:07:55 +0200 (MEST) Received: (qmail 1139 invoked from network); 18 Sep 2007 17:07:55 -0000 Received: from unknown (HELO hardy.tmseck.homedns.org) (192.168.1.2) by 0 with SMTP; 18 Sep 2007 17:07:55 -0000 Received: from hardy.tmseck.homedns.org (localhost [127.0.0.1]) by hardy.tmseck.homedns.org (8.14.1/8.14.1) with ESMTP id l8IH7sv7001521; Tue, 18 Sep 2007 19:07:54 +0200 (CEST) (envelope-from tmseck-lists@netcologne.de) Received: (from thomas@localhost) by hardy.tmseck.homedns.org (8.14.1/8.14.1/Submit) id l8IH7rpD001520; Tue, 18 Sep 2007 19:07:53 +0200 (CEST) (envelope-from tmseck-lists@netcologne.de) X-Authentication-Warning: hardy.tmseck.homedns.org: thomas set sender to tmseck-lists@netcologne.de using -f Date: Tue, 18 Sep 2007 19:07:53 +0200 From: Thomas-Martin Seck To: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Message-ID: <20070918170753.GA1483@hardy.tmseck.homedns.org> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-ports@freebsd.org References: <20070910172221.GA6504@bledge.tmseck.homedns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070910172221.GA6504@bledge.tmseck.homedns.org> User-Agent: Mutt/1.4.2.3i Organization: a private site in Germany X-PGP-KeyID: DF46EE05 X-PGP-Fingerprint: A38F AE66 6B11 6EB9 5D1A B67D 2444 2FE1 DF46 EE05 X-Attribution: tms Cc: Subject: Re: Odd segfault during Squid-2.6.16 compilation on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 17:07:57 -0000 I wrote: > [x-post to freebsd-current@ and freebsd-ports@, replies should probably > go to freebsd-current only since I only observe this issue on 7-CURRENT] > > All, > > I am currently struggling with an odd issue that keeps me (or rather > miwi@) from updating www/squid to 2.6.16: This issue has been resolved (it turned out to be a bug in the crashing application's code that was only obvious on CURRENT). Please see ports/116165 for the update to 2.6.16 and the necessary patch. Sorry that I wasted more than a week on this by blaming the problem on the messenger. From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 17:08:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34D9716A419 for ; Tue, 18 Sep 2007 17:08:51 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id A71F513C46E for ; Tue, 18 Sep 2007 17:08:50 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 18 Sep 2007 17:08:49 -0000 Received: from h081217094222.dyn.cm.kabsi.at (EHLO taxman.pepperland) [81.217.94.222] by mail.gmx.net (mp036) with SMTP; 18 Sep 2007 19:08:49 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX19VgWtJNLlVkQfGyM51wQl7IsdWEZsYQlivT1DNl9 i+jYnsV2AE+zRo From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Tue, 18 Sep 2007 19:08:47 +0200 User-Agent: KMail/1.9.7 References: <20070918175749.I97108@woozle.rinet.ru> <46EFF4C0.7070301@freebsd.org> In-Reply-To: <46EFF4C0.7070301@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709181908.47832.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: Dmitry Morozovsky Subject: Re: Misterious tar errors on today's current/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 17:08:51 -0000 On Tuesday 18 September 2007 17:54:40 Eric Anderson wrote: > Dmitry Morozovsky wrote: > > Hi there colleagues. > > > > > > marck@n5600:/usr/ports/archivers/rpm> uname -a > > FreeBSD n5600.rinet.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #4: Tue Sep 18 > > 17:23:00 MSD 2007 marck@n5600.rinet.ru:/usr/obj/usr/src/sys/MINI > > amd64 > > > > (freshly built system) > > > > marck@n5600:/usr/ports/archivers/rpm> make > > ===> Patching for rpm-3.0.6_13 > > ===> Applying FreeBSD patches for rpm-3.0.6_13 > > 1 out of 1 hunks failed--saving rejects to aclocal.m4.rej > > => Patch patch-av failed to apply cleanly. > > *** Error code 1 > > > > Stop in /usr/ports/archivers/rpm. > > > > marck@n5600:/usr/ports/archivers/rpm> l work/rpm-3.0.6/aclocal.m4* > > -rw-rw-r-- 1 marck wheel 6657 Sep 18 17:48 work/rpm-3.0.6/aclocal.m4 > > -rw-rw-r-- 1 marck wheel 6656 Sep 13 2000 > > work/rpm-3.0.6/aclocal.m4.orig -rw-rw-r-- 1 marck wheel 324 Sep 18 > > 17:48 work/rpm-3.0.6/aclocal.m4.rej > > > > marck@n5600:/usr/ports/archivers/rpm> cd work/ > > marck@n5600:/usr/ports/archivers/rpm/work> rm -rf rpm-3.0.6/ > > marck@n5600:/usr/ports/archivers/rpm/work> tar tvzf > > /usr/ports/distfiles/rpm-3.0.6.tar.gz |grep aclocal -rw-rw-r-- 0 2161 > > 2161 34470 Sep 13 2000 rpm-3.0.6/aclocal.m4 -rw-rw-r-- 0 2161 2161 > > 34044 Sep 13 2000 rpm-3.0.6/popt/aclocal.m4 > > marck@n5600:/usr/ports/archivers/rpm/work> tar xzf > > /usr/ports/distfiles/rpm-3.0.6.tar.gz > > marck@n5600:/usr/ports/archivers/rpm/work> l rpm-3.0.6/acl* > > -rw-rw-r-- 1 marck wheel 6656 Sep 13 2000 rpm-3.0.6/aclocal.m4 > > > > So, aclocal.m4 does not extracted correctly. > > > > WTF? I'm out of ideas. > > Maybe try rolling these back: > > http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libarchive/archive_write_disk >.c.diff?&r1=1.14&r2=1.15&f=h > http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libarchive/test/test_write_di >sk.c.diff?&r1=1.3&r2=1.4&f=h I also just got bitten by this on a freshly installed current. Reverting those files and rebuilding/reinstalling libarchive helps here. -- Stefan From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 17:11:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5115D16A475 for ; Tue, 18 Sep 2007 17:11:29 +0000 (UTC) (envelope-from acousticvan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id DB47313C483 for ; Tue, 18 Sep 2007 17:11:28 +0000 (UTC) (envelope-from acousticvan@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so171361ugf for ; Tue, 18 Sep 2007 10:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type; bh=5stg0cwgePyerewjVjK4zRmIiWhDIYx3gukayHEW9Y4=; b=QHOCnMzlG2wCgPJFe2JyUpLCw6KMMS6ISqaTG78UqfubnvSspP2DvTMA3tDcgQAg3JNqq5sUu36WieN6XeLN5QiraKR9w4PrMPQ7qHvdhFXjzCAQ1uRz64teskA8JXnkMgRgsalgWImF7c6YbaXUbtgnL4upGywDoSBgi+o7EWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=UIQj1sNJ01YZNuuJ3ch95LhwneHxg5h86frIv+WX2qd391J0RLXb0AuJJezD8oMh2+BChsOh0Xn4MYbQXjt6OLsEwm6nQGZm429ih8NHHD4PHigDKc8gaaFGpVUc4y+UxHbOZFgxb7ym0Qk0Yw5U7AwzM7YBAGC+A7gNgCoFHCQ= Received: by 10.78.122.16 with SMTP id u16mr2548820huc.1190133903553; Tue, 18 Sep 2007 09:45:03 -0700 (PDT) Received: by 10.78.130.4 with HTTP; Tue, 18 Sep 2007 09:45:03 -0700 (PDT) Message-ID: <91729d710709180945r58f2d1d4vb6a4074e242cf2ab@mail.gmail.com> Date: Tue, 18 Sep 2007 11:45:03 -0500 From: "van nguyen" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ath driver source code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vxn9344@louisiana.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 17:11:29 -0000 Hi all, I would like to know if the source code for ath driver (wireless driver for atheros chipset) is available somewhere. I understand that HAL part is not available but other part should be available. Thank you very much, Van From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 17:31:46 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C48F216A419 for ; Tue, 18 Sep 2007 17:31:46 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 93F6813C459 for ; Tue, 18 Sep 2007 17:31:46 +0000 (UTC) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <46F0072F.6010906@intersonic.se> Date: Tue, 18 Sep 2007 19:13:19 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: no apps builds on today's -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 17:31:46 -0000 at least the ones I've tried... I assume we are in the middle of something right now? Anyone have an idea what is going on or is it just me? Example: ===> Building file daemon only. ===> Vulnerability check disabled, database not found ===> Found saved configuration for bacula-client-2.0.3 ===> Extracting for bacula-client-2.2.4 => MD5 Checksum OK for bacula-2.2.4.tar.gz. => SHA256 Checksum OK for bacula-2.2.4.tar.gz. ===> Patching for bacula-client-2.2.4 ===> Applying FreeBSD patches for bacula-client-2.2.4 1 out of 1 hunks failed--saving rejects to src/console/Makefile.in.rej => Patch patch-src-console-Makefile.in failed to apply cleanly. => Patch(es) patch-scripts-Makefile.in applied cleanly. *** Error code 1 or ===> Vulnerability check disabled, database not found => gmp-4.2.2.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch from http://ftp.gnu.org/gnu/gmp/. gmp-4.2.2.tar.gz 100% of 2226 kB 990 kBps ===> Extracting for libgmp-4.2.2 => MD5 Checksum OK for gmp-4.2.2.tar.gz. => SHA256 Checksum OK for gmp-4.2.2.tar.gz. ===> Patching for libgmp-4.2.2 ===> libgmp-4.2.2 depends on file: /usr/local/bin/libtool - found ===> Configuring for libgmp-4.2.2 ./configure: 128: Syntax error: Unterminated quoted string ===> Script "configure" failed unexpectedly. Please report the problem to ale@FreeBSD.org [maintainer] and attach the "/usr/ports/math/libgmp4/work/gmp-4.2.2/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/math/libgmp4. From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 17:43:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E296216A417 for ; Tue, 18 Sep 2007 17:43:26 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.de [194.25.134.19]) by mx1.freebsd.org (Postfix) with ESMTP id 84E5713C480 for ; Tue, 18 Sep 2007 17:43:26 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from fwd28.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1IXh6a-00006V-02; Tue, 18 Sep 2007 19:43:24 +0200 Received: from localhost (SmC70ZZLwtcHWobf19GTmFlM8KIxREF38Iup01ivvcPYA1zTMZLMhKT34ZoGOW73LIGeRmfBsO@[84.165.71.68]) by fwd28.t-online.de with esmtp id 1IXh6J-0Cd9Hs0; Tue, 18 Sep 2007 19:43:07 +0200 Date: Tue, 18 Sep 2007 19:43:06 +0200 From: Oliver Herold To: freebsd-current@freebsd.org, current@freebsd.org Message-ID: <20070918174306.GA70714@olymp.home> Mail-Followup-To: freebsd-current@freebsd.org, current@freebsd.org References: <46F0072F.6010906@intersonic.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <46F0072F.6010906@intersonic.se> User-Agent: Mutt/1.5.16 (2007-06-09) X-ID: SmC70ZZLwtcHWobf19GTmFlM8KIxREF38Iup01ivvcPYA1zTMZLMhKT34ZoGOW73LIGeRmfBsO X-TOI-MSGID: 0c34de20-a87b-4828-8937-962971f470df Cc: Subject: Re: no apps builds on today's -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 17:43:27 -0000 So I'm not alone :-) todays current and I have got the same problem with OR= Bit2 and libIDL. I can compile these on another machine (Current from yesterday). Oliver On Tue, Sep 18, 2007 at 07:13:19PM +0200, Per olof Ljungmark wrote: > at least the ones I've tried... I assume we are in the middle of somethin= g=20 > right now? >=20 > Anyone have an idea what is going on or is it just me? >=20 > Example: > =3D=3D=3D> Building file daemon only. > =3D=3D=3D> Vulnerability check disabled, database not found > =3D=3D=3D> Found saved configuration for bacula-client-2.0.3 > =3D=3D=3D> Extracting for bacula-client-2.2.4 > =3D> MD5 Checksum OK for bacula-2.2.4.tar.gz. > =3D> SHA256 Checksum OK for bacula-2.2.4.tar.gz. > =3D=3D=3D> Patching for bacula-client-2.2.4 > =3D=3D=3D> Applying FreeBSD patches for bacula-client-2.2.4 > 1 out of 1 hunks failed--saving rejects to src/console/Makefile.in.rej > =3D> Patch patch-src-console-Makefile.in failed to apply cleanly. > =3D> Patch(es) patch-scripts-Makefile.in applied cleanly. > *** Error code 1 >=20 > or >=20 > =3D=3D=3D> Vulnerability check disabled, database not found > =3D> gmp-4.2.2.tar.gz doesn't seem to exist in /usr/ports/distfiles/. > =3D> Attempting to fetch from http://ftp.gnu.org/gnu/gmp/. > gmp-4.2.2.tar.gz 100% of 2226 kB 990 kBps > =3D=3D=3D> Extracting for libgmp-4.2.2 > =3D> MD5 Checksum OK for gmp-4.2.2.tar.gz. > =3D> SHA256 Checksum OK for gmp-4.2.2.tar.gz. > =3D=3D=3D> Patching for libgmp-4.2.2 > =3D=3D=3D> libgmp-4.2.2 depends on file: /usr/local/bin/libtool - found > =3D=3D=3D> Configuring for libgmp-4.2.2 > ./configure: 128: Syntax error: Unterminated quoted string > =3D=3D=3D> Script "configure" failed unexpectedly. > Please report the problem to ale@FreeBSD.org [maintainer] and attach the > "/usr/ports/math/libgmp4/work/gmp-4.2.2/config.log" including the output = of > the failure of your make command. Also, it might be a good idea to provide > an overview of all packages installed on your system (e.g. an `ls > /var/db/pkg`). > *** Error code 1 >=20 > Stop in /usr/ports/math/libgmp4. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --=20 The distinction between Jewish and goyish can be quite subtle, as the following quote from Lenny Bruce illustrates: "I'm Jewish. Count Basie's Jewish. Ray Charles is Jewish. Eddie Cantor's goyish. The B'nai Brith is goyish. The Hadassah is Jewish. Marine Corps -- heavy goyish, dangerous. "Kool-Aid is goyish. All Drake's Cakes are goyish. Pumpernickel is Jewish and, as you know, white bread is very goyish. Instant potatoes -- goyish. Black cherry soda's very Jewish. Macaroons are ____=08=08=08=08very Jewish. Fruit salad is Jewish. Lime Je= ll-O is goyish. Lime soda is ____=08=08=08=08very goyish. Trailer parks are so go= yish that Jews won't go near them ..." -- Arthur Naiman, "Every Goy's Guide to Yiddish" From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 18:04:47 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE5916A418 for ; Tue, 18 Sep 2007 18:04:47 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 85CB113C45D for ; Tue, 18 Sep 2007 18:04:47 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 18 Sep 2007 10:59:19 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id l8II4eq6085231; Tue, 18 Sep 2007 11:04:40 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id l8II4dlg085230; Tue, 18 Sep 2007 11:04:39 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200709181804.l8II4dlg085230@ambrisko.com> In-Reply-To: <20070918114357.F23171@fw.reifenberger.com> To: Michael Reifenberger Date: Tue, 18 Sep 2007 11:04:39 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD-Current Subject: Re: i386 package building on an amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 18:04:47 -0000 Michael Reifenberger writes: | Hi, | have you tried to recompile java/jdk15 under a i386 jail on amd64 host? | | I tried to use an formely i386 natively compiled jdk15 to recompile | inside an jail. | | Using java '-server' failed early with an null pointer exception | and '-client' later with an segmentation violation. | (Probably running out of the default 512MB MAXDSIZ inside the jail) Currently, we don't do that on a regular basis so I'm not sure. I recall jhb adding some code that might deal with that for i386 mode. Doug A. From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 18:09:08 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5266716A41A for ; Tue, 18 Sep 2007 18:09:08 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3381313C48A for ; Tue, 18 Sep 2007 18:09:08 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 46978 invoked from network); 18 Sep 2007 18:09:06 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 18 Sep 2007 18:09:06 -0000 Message-ID: <46F01440.5050508@root.org> Date: Tue, 18 Sep 2007 11:09:04 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: William References: <46E0777A.8070901@root.org> <46E07AAF.2060000@root.org> <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> <46E6DF34.1060304@root.org> <632825b40709140426s466e20afkc410c56aa4f1dae9@mail.gmail.com> In-Reply-To: <632825b40709140426s466e20afkc410c56aa4f1dae9@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------080704040001030502050209" Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 18:09:08 -0000 This is a multi-part message in MIME format. --------------080704040001030502050209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit William wrote: > On 9/11/07, *Nate Lawson* wrote: > > William Grzybowski wrote: > > I tested this patch on my acer notebook (intel chipset) and i did not > > notice any changes, unless some errors on dmesg, like: > > acpi_ec0: EcCommand: no response to 0x84 > > acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE > > acpi_ec0: EcCommand: no response to 0x82 > > acpi_ec0: EcCommand: no response to 0x80 > > ACPI Error (psparse-0626): Method parse/execution failed > > [\\_TZ_.THRM._TMP] (Node 0xc3bbdcc0), AE_NO_HARDWARE_RESPONSE > > ACPI Error (psparse-0626): Method parse/execution failed > > [\\_SB_.ACAD._PSR] (Node 0xc3bc02a0), AE_NO_HARDWARE_RESPONSE > > As I noted before, your system enters the poll loop with the status > appearing to be already complete. Can you get back to me on my previous > questions, especially whether forcing polled mode works for you? I > didn't see any errors in that dmesg case. > > I've updated the patches to do one final check if the interrupt-driven > mode gets a timeout. If the status is complete, it will force the > system back into polled mode since interrupt mode doesn't work. It also > has a case for polled mode during boot where the status appears to be > already complete. It waits a short while before actually checking the > status, just in case the EC is really slow and hasn't gotten to work on > the new request yet. > > Give it a try also, with no tunables set. > > Nate, > > Yesterday I send to you privately the answers which you asked for, annoy > me if you didn't receive... > Today I recompiled the kernel from a today's cvs without modules with > KTR and recompiled the acpi module without any patches, > without any debug option on boot, the system can initialize the battery > and the thermal, when i enable any debug (polled or burst or even both) > the battery get ready after 2 tries. > > Tonight I will remake some testes with your patches to make sure about > things which I told you. There was one other change needed. I was too aggressive in trying to hold the lock over the _Qxx method evaluation. Some BIOSes apparently try to read/write from EC space in that method. So I reverted that part of the patch and added a comment explaining it to future maintainers. Attached are revised patches, version D. Please try them without any debug.acpi.ec tunables set in loader.conf. If your battery status fails with this patch, add: debug.acpi.ec.polled="1" You should also keep jkim's OsdSynch patch in your tree. It fixes different problems but ones that are needed to test my EC patches. Thanks, Nate --------------080704040001030502050209 Content-Type: text/x-patch; name="ecng-6d.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-6d.diff" Index: sys/dev/acpica/acpi_ec.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v retrieving revision 1.65.2.3 diff -u -r1.65.2.3 acpi_ec.c --- sys/dev/acpica/acpi_ec.c 4 Sep 2007 22:40:39 -0000 1.65.2.3 +++ sys/dev/acpica/acpi_ec.c 18 Sep 2007 18:07:52 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -142,9 +33,9 @@ #include #include #include +#include #include #include -#include #include #include @@ -171,7 +62,7 @@ #define EC_COMMAND_BURST_DISABLE ((EC_COMMAND) 0x83) #define EC_COMMAND_QUERY ((EC_COMMAND) 0x84) -/* +/* * EC_STATUS: * ---------- * The encoding of the EC status register is illustrated below. @@ -188,15 +79,15 @@ * | | | +--------- Burst Mode Enabled? * | | +----------- SCI Event? * | +------------- SMI Event? - * +--------------- + * +--------------- * */ typedef UINT8 EC_STATUS; #define EC_FLAG_OUTPUT_BUFFER ((EC_STATUS) 0x01) #define EC_FLAG_INPUT_BUFFER ((EC_STATUS) 0x02) +#define EC_FLAG_DATA_IS_CMD ((EC_STATUS) 0x08) #define EC_FLAG_BURST_MODE ((EC_STATUS) 0x10) -#define EC_FLAG_SCI ((EC_STATUS) 0x20) /* * EC_EVENT: @@ -208,6 +99,10 @@ #define EC_EVENT_OUTPUT_BUFFER_FULL ((EC_EVENT) 0x01) #define EC_EVENT_INPUT_BUFFER_EMPTY ((EC_EVENT) 0x02) #define EC_EVENT_SCI ((EC_EVENT) 0x20) +#define EC_EVENT_SMI ((EC_EVENT) 0x40) + +/* Data byte returned after burst enable indicating it was successful. */ +#define EC_BURST_ACK 0x90 /* * Register access primitives @@ -227,11 +122,11 @@ /* Embedded Controller Boot Resources Table (ECDT) */ typedef struct { ACPI_TABLE_HEADER header; - ACPI_GENERIC_ADDRESS control; - ACPI_GENERIC_ADDRESS data; - UINT32 uid; - UINT8 gpe_bit; - char ec_id[0]; + ACPI_GENERIC_ADDRESS Control; + ACPI_GENERIC_ADDRESS Data; + UINT32 Uid; + UINT8 Gpe; + char Id[0]; } ACPI_TABLE_ECDT; /* Additional params to pass from the probe routine */ @@ -243,7 +138,7 @@ }; /* Indicate that this device has already been probed via ECDT. */ -#define DEV_ECDT(x) (acpi_get_magic(x) == (int)&acpi_ec_devclass) +#define DEV_ECDT(x) (acpi_get_magic(x) == (uintptr_t)&acpi_ec_devclass) /* * Driver softc. @@ -254,8 +149,7 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; - + int ec_data_rid; struct resource *ec_data_res; bus_space_tag_t ec_data_tag; @@ -268,6 +162,9 @@ int ec_glk; int ec_glkhandle; + int ec_burstactive; + int ec_sci_pend; + u_int ec_gencount; }; /* @@ -277,11 +174,11 @@ */ #define EC_LOCK_TIMEOUT 1000 -/* Default interval in microseconds for the status polling loop. */ -#define EC_POLL_DELAY 10 +/* Default delay in microseconds between each run of the status polling loop. */ +#define EC_POLL_DELAY 5 -/* Total time in ms spent in the poll loop waiting for a response. */ -#define EC_POLL_TIMEOUT 100 +/* Total time in ms spent waiting for a response from EC. */ +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -289,46 +186,57 @@ ((event) == EC_EVENT_INPUT_BUFFER_EMPTY && \ ((status) & EC_FLAG_INPUT_BUFFER) == 0)) -static int ec_poll_timeout = EC_POLL_TIMEOUT; -TUNABLE_INT("hw.acpi.ec.poll_timeout", &ec_poll_timeout); - ACPI_SERIAL_DECL(ec, "ACPI embedded controller"); -static __inline ACPI_STATUS +SYSCTL_DECL(_debug_acpi); +SYSCTL_NODE(_debug_acpi, OID_AUTO, ec, CTLFLAG_RD, NULL, "EC debugging"); + +static int ec_burst_mode; +TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, + "Enable use of burst mode (faster for nearly all systems)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); +static int ec_timeout = EC_TIMEOUT; +TUNABLE_INT("debug.acpi.ec.timeout", &ec_timeout); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, timeout, CTLFLAG_RW, &ec_timeout, + EC_TIMEOUT, "Total time spent waiting for a response (poll+sleep)"); + +static ACPI_STATUS EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; - /* Always acquire the exclusive lock. */ + /* If _GLK is non-zero, acquire the global lock. */ status = AE_OK; - ACPI_SERIAL_BEGIN(ec); - - /* If _GLK is non-zero, also acquire the global lock. */ if (sc->ec_glk) { status = AcpiAcquireGlobalLock(EC_LOCK_TIMEOUT, &sc->ec_glkhandle); if (ACPI_FAILURE(status)) - ACPI_SERIAL_END(ec); + return (status); } - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); - ACPI_SERIAL_END(ec); } static uint32_t EcGpeHandler(void *Context); -static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, +static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, void *Context, void **return_Context); static ACPI_STATUS EcSpaceHandler(UINT32 Function, ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -366,10 +274,12 @@ MODULE_DEPEND(acpi_ec, acpi, 1, 1, 1); /* - * Look for an ECDT and if we find one, set up default GPE and + * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -387,20 +297,20 @@ status = AcpiGetFirmwareTable("ECDT", 1, ACPI_LOGICAL_ADDRESSING, &hdr); ecdt = (ACPI_TABLE_ECDT *)hdr; if (ACPI_FAILURE(status) || - ecdt->control.RegisterBitWidth != 8 || - ecdt->data.RegisterBitWidth != 8) { + ecdt->Control.RegisterBitWidth != 8 || + ecdt->Data.RegisterBitWidth != 8) { return; } /* Create the child device with the given unit number. */ - child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->uid); + child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->Uid); if (child == NULL) { printf("%s: can't add child\n", __func__); return; } /* Find and save the ACPI handle for this device. */ - status = AcpiGetHandle(NULL, ecdt->ec_id, &h); + status = AcpiGetHandle(NULL, ecdt->Id, &h); if (ACPI_FAILURE(status)) { device_delete_child(parent, child); printf("%s: can't get handle\n", __func__); @@ -409,9 +319,9 @@ acpi_set_handle(child, h); /* Set the data and CSR register addresses. */ - bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->data.Address, + bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->Data.Address, /*count*/1); - bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->control.Address, + bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->Control.Address, /*count*/1); /* @@ -423,11 +333,11 @@ */ params = malloc(sizeof(struct acpi_ec_params), M_TEMP, M_WAITOK | M_ZERO); params->gpe_handle = NULL; - params->gpe_bit = ecdt->gpe_bit; - params->uid = ecdt->uid; + params->gpe_bit = ecdt->Gpe; + params->uid = ecdt->Uid; acpi_GetInteger(h, "_GLK", ¶ms->glk); acpi_set_private(child, params); - acpi_set_magic(child, (int)&acpi_ec_devclass); + acpi_set_magic(child, (uintptr_t)&acpi_ec_devclass); /* Finish the attach process. */ if (device_probe_and_attach(child) != 0) @@ -601,7 +511,7 @@ goto error; } - /* + /* * Install address space handler */ ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES, "attaching address space handler\n")); @@ -636,7 +546,7 @@ AcpiRemoveAddressSpaceHandler(sc->ec_handle, ACPI_ADR_SPACE_EC, EcSpaceHandler); if (sc->ec_csr_res) - bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, + bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, sc->ec_csr_res); if (sc->ec_data_res) bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_data_rid, @@ -688,100 +598,95 @@ struct acpi_ec_softc *sc = (struct acpi_ec_softc *)Context; UINT8 Data; ACPI_STATUS Status; - EC_STATUS EcStatus; char qxx[5]; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); + /* Serialize user access with EcSpaceHandler(). */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - */ - EcStatus = EC_GET_CSR(sc); - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was not SCI, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - EcUnlock(sc); - goto re_enable; - } - - /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); + + /* + * We have to unlock before running the _Qxx method below since that + * method may attempt to read/write from EC address space, causing + * recursive acquisition of the lock. + */ EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); if (Data == 0) - goto re_enable; + return; /* Evaluate _Qxx to respond to the controller. */ - sprintf(qxx, "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } - -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_NOT_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) { struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; + EC_STATUS EcStatus; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (which could - * potentially sleep.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); - /* Schedule the GPE query handler. */ - Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, - Context); - if (ACPI_FAILURE(Status)) { - printf("Queuing GPE query handler failed.\n"); - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableEvent failed\n"); + /* + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. + */ + EcStatus = EC_GET_CSR(sc); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); + Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, + Context); + if (ACPI_SUCCESS(Status)) + sc->ec_sci_pend = TRUE; + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - return (0); } @@ -825,6 +730,18 @@ EcAddr = Address; Status = AE_ERROR; + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold || rebooting) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -856,187 +773,258 @@ } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcCheckStatus(struct acpi_ec_softc *sc, const char *msg, EC_EVENT event) +{ + ACPI_STATUS status; + EC_STATUS ec_status; + + status = AE_NO_HARDWARE_RESPONSE; + ec_status = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(ec_status & EC_FLAG_BURST_MODE)) { + CTR1(KTR_ACPI, "ec burst disabled in waitevent (%s)", msg); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(event, ec_status)) { + CTR2(KTR_ACPI, "ec %s wait ready, status %#x", msg, ec_status); + status = AE_OK; + } + return (status); +} + +static ACPI_STATUS +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { - EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, period, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - /* - * Wait for 1 us before checking the CSR. Testing shows about - * 50% of requests complete in 1 us and 90% of them complete - * in 5 us or less. - */ - AcpiOsStall(1); - /* - * Poll the EC status register for up to 1 ms in chunks of 10 us - * to detect completion of the last command. + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. + * + * If this occurs, we add an additional delay before actually entering + * the status checking loop, hopefully to allow the EC to go to work + * and produce a non-stale status. */ - for (i = 0; i < 1000 / EC_POLL_DELAY; i++) { - EcStatus = EC_GET_CSR(sc); - if (EVENT_READY(Event, EcStatus)) { - Status = AE_OK; - break; + if (cold || rebooting || ec_polled_mode) { + static int once; + + if (EcCheckStatus(sc, "pre-check", Event) == AE_OK) { + if (!once) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; + } + AcpiOsStall(10); } - AcpiOsStall(EC_POLL_DELAY); } - period = i * EC_POLL_DELAY; - /* - * If we still don't have a response and we're up and running, wait up - * to ec_poll_timeout ms for completion, sleeping for chunks of 10 ms. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - count = ec_poll_timeout / 10; + /* Wait for event by polling or GPE (interrupt). */ + if (cold || rebooting || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; if (count == 0) count = 1; - slp_ival = hz / 100; - if (slp_ival == 0) - slp_ival = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; - if (EVENT_READY(Event, EcStatus)) { - Status = AE_OK; + Status = EcCheckStatus(sc, "poll", Event); + if (Status == AE_OK) break; - } - if (!cold) - retval = tsleep(&sc->ec_csrvalue, PZERO, "ecpoll", slp_ival); - else - AcpiOsStall(10000); + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout; + } else { + /* hz has less than 1 ms resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); } - } - /* Calculate new delay and log it. */ - if (slp_ival > 0) - period += i * 10000; - CTR2(KTR_ACPI, "ec got event %#x after %d us", EcStatus, period); + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time we get one. It's possible to get a + * GPE for an event we're not interested in here (i.e., SCI for + * EC query). + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + Status = EcCheckStatus(sc, "sleep", Event); + if (Status == AE_OK) + break; + } + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); + } + /* + * We finished waiting for the GPE and it never arrived. Try to + * read the register once and trust whatever value we got. This is + * the best we can do at this point. Then, force polled mode on + * since this system doesn't appear to generate GPEs. + */ + if (Status != AE_OK) { + Status = EcCheckStatus(sc, "sleep_end", Event); + device_printf(sc->ec_dev, + "wait timed out (%sresponse), forcing polled mode\n", + Status == AE_OK ? "" : "no "); + ec_polled_mode = TRUE; + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) { - ACPI_STATUS Status; - EC_EVENT Event; + ACPI_STATUS status; + EC_EVENT event; + EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); + /* Don't use burst mode if user disabled it. */ + if (!ec_burst_mode && cmd == EC_COMMAND_BURST_ENABLE) + return (AE_ERROR); + /* Decide what to wait for based on command type. */ switch (cmd) { case EC_COMMAND_READ: case EC_COMMAND_WRITE: case EC_COMMAND_BURST_DISABLE: - Event = EC_EVENT_INPUT_BUFFER_EMPTY; + event = EC_EVENT_INPUT_BUFFER_EMPTY; break; case EC_COMMAND_QUERY: case EC_COMMAND_BURST_ENABLE: - Event = EC_EVENT_OUTPUT_BUFFER_FULL; + event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ + CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - Status = EcWaitEvent(sc, Event); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - - return (Status); + status = EcWaitEvent(sc, event, gen_count); + if (ACPI_SUCCESS(status)) { + /* If we succeeded, burst flag should now be present. */ + if (cmd == EC_COMMAND_BURST_ENABLE) { + ec_status = EC_GET_CSR(sc); + if ((ec_status & EC_FLAG_BURST_MODE) == 0) + status = AE_ERROR; + } + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); + return (status); } static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_READ); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_READ); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); + return (status); } - *Data = EC_GET_DATA(sc); -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); -} +} static ACPI_STATUS EcWrite(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_WRITE); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_WRITE); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); + return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); + return (status); } -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); } --------------080704040001030502050209 Content-Type: text/x-patch; name="ecng-7d.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-7d.diff" Index: sys/dev/acpica/acpi_ec.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v retrieving revision 1.75 diff -u -r1.75 acpi_ec.c --- sys/dev/acpica/acpi_ec.c 15 Jun 2007 18:02:33 -0000 1.75 +++ sys/dev/acpica/acpi_ec.c 18 Sep 2007 18:17:23 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -171,7 +62,7 @@ #define EC_COMMAND_BURST_DISABLE ((EC_COMMAND) 0x83) #define EC_COMMAND_QUERY ((EC_COMMAND) 0x84) -/* +/* * EC_STATUS: * ---------- * The encoding of the EC status register is illustrated below. @@ -248,8 +139,7 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; - + int ec_data_rid; struct resource *ec_data_res; bus_space_tag_t ec_data_tag; @@ -260,11 +150,11 @@ bus_space_tag_t ec_csr_tag; bus_space_handle_t ec_csr_handle; - struct mtx ec_mtx; int ec_glk; int ec_glkhandle; int ec_burstactive; int ec_sci_pend; + u_int ec_gencount; }; /* @@ -275,13 +165,10 @@ #define EC_LOCK_TIMEOUT 1000 /* Default delay in microseconds between each run of the status polling loop. */ -#define EC_POLL_DELAY 10 - -/* Default time in microseconds spent polling before sleep waiting. */ -#define EC_POLL_TIME 500 +#define EC_POLL_DELAY 5 /* Total time in ms spent waiting for a response from EC. */ -#define EC_TIMEOUT 500 +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -298,17 +185,17 @@ TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, "Enable use of burst mode (faster for nearly all systems)"); -static int ec_poll_time = EC_POLL_TIME; -TUNABLE_INT("debug.acpi.ec.poll_time", &ec_poll_time); -SYSCTL_INT(_debug_acpi_ec, OID_AUTO, poll_time, CTLFLAG_RW, &ec_poll_time, - EC_POLL_TIME, "Time spent polling vs. sleeping (CPU intensive)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); static int ec_timeout = EC_TIMEOUT; TUNABLE_INT("debug.acpi.ec.timeout", &ec_timeout); SYSCTL_INT(_debug_acpi_ec, OID_AUTO, timeout, CTLFLAG_RW, &ec_timeout, EC_TIMEOUT, "Total time spent waiting for a response (poll+sleep)"); -static __inline ACPI_STATUS -EcLock(struct acpi_ec_softc *sc, int serialize) +static ACPI_STATUS +EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; @@ -319,37 +206,27 @@ if (ACPI_FAILURE(status)) return (status); } - - /* - * If caller is executing a series of commands, acquire the exclusive lock - * to serialize with other users. - * To sync with bottom-half interrupt handler, always acquire the mutex. - */ - if (serialize) - ACPI_SERIAL_BEGIN(ec); - mtx_lock(&sc->ec_mtx); - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { - mtx_unlock(&sc->ec_mtx); - if (sx_xlocked(&ec_sxlock)) - ACPI_SERIAL_END(ec); + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); } static uint32_t EcGpeHandler(void *Context); -static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, +static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, void *Context, void **return_Context); static ACPI_STATUS EcSpaceHandler(UINT32 Function, ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -387,10 +264,12 @@ MODULE_DEPEND(acpi_ec, acpi, 1, 1, 1); /* - * Look for an ECDT and if we find one, set up default GPE and + * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -578,7 +457,6 @@ params = acpi_get_private(dev); sc->ec_dev = dev; sc->ec_handle = acpi_get_handle(dev); - mtx_init(&sc->ec_mtx, "ACPI EC lock", NULL, MTX_DEF); /* Retrieve previously probed values via device ivars. */ sc->ec_glk = params->glk; @@ -621,7 +499,7 @@ goto error; } - /* + /* * Install address space handler */ ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES, "attaching address space handler\n")); @@ -656,12 +534,11 @@ AcpiRemoveAddressSpaceHandler(sc->ec_handle, ACPI_ADR_SPACE_EC, EcSpaceHandler); if (sc->ec_csr_res) - bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, + bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, sc->ec_csr_res); if (sc->ec_data_res) bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_data_rid, sc->ec_data_res); - mtx_destroy(&sc->ec_mtx); return (ENXIO); } @@ -715,57 +592,55 @@ KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); /* Serialize user access with EcSpaceHandler(). */ - Status = EcLock(sc, TRUE); + Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); - sc->ec_sci_pend = FALSE; - /* Drop locks before evaluating _Qxx method since it may trigger GPEs. */ + /* + * We have to unlock before running the _Qxx method below since that + * method may attempt to read/write from EC address space, causing + * recursive acquisition of the lock. + */ EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); if (Data == 0) - goto re_enable; + return; /* Evaluate _Qxx to respond to the controller. */ - snprintf(qxx, sizeof(qxx), "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } - -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) @@ -773,68 +648,32 @@ struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; EC_STATUS EcStatus; - int query_pend; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (although - * sleeping would be ok since we're in an ithread.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - - /* For interrupt (GPE) handler, don't acquire serialization lock. */ - Status = EcLock(sc, FALSE); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); - return (-1); - } + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); /* - * If burst was active, but the status bit was cleared, the EC had to - * exit burst mode for some reason. Record this for later. + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. */ EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in query handler"); - sc->ec_burstactive = FALSE; - } - - /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - * If it is set, queue a query handler. - */ - query_pend = FALSE; - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was IBE/OBF, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - } else if (!sc->ec_sci_pend) { - /* SCI bit set and no pending query handler, so schedule one. */ - CTR0(KTR_ACPI, "ec queueing gpe handler"); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); Status = AcpiOsExecute(OSL_GPE_HANDLER, EcGpeQueryHandler, Context); - if (ACPI_SUCCESS(Status)) { + if (ACPI_SUCCESS(Status)) sc->ec_sci_pend = TRUE; - query_pend = TRUE; - } else - printf("Queuing GPE query handler failed.\n"); - } - - /* - * If we didn't queue a query handler, which will eventually re-enable - * the GPE, re-enable it right now so we can get more events. - */ - if (!query_pend) { - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableGpe failed\n"); + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - - EcUnlock(sc); return (0); } @@ -878,8 +717,19 @@ EcAddr = Address; Status = AE_ERROR; - /* Grab serialization lock to hold across command sequence. */ - Status = EcLock(sc, TRUE); + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold || rebooting) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ + Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -910,83 +760,119 @@ } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcCheckStatus(struct acpi_ec_softc *sc, const char *msg, EC_EVENT event) +{ + ACPI_STATUS status; + EC_STATUS ec_status; + + status = AE_NO_HARDWARE_RESPONSE; + ec_status = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(ec_status & EC_FLAG_BURST_MODE)) { + CTR1(KTR_ACPI, "ec burst disabled in waitevent (%s)", msg); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(event, ec_status)) { + CTR2(KTR_ACPI, "ec %s wait ready, status %#x", msg, ec_status); + status = AE_OK; + } + return (status); +} + +static ACPI_STATUS +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { - EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - EcStatus = 0; /* - * Poll for up to ec_poll_time microseconds since many ECs complete - * the command quickly, especially if in burst mode. - */ -#if 0 /* Enable this as a possible workaround if EC times out. */ - AcpiOsStall(EC_POLL_DELAY); -#endif - count = ec_poll_time / EC_POLL_DELAY; - if (count <= 0) - count = 1; - for (i = 0; i < count; i++) { - EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); - sc->ec_burstactive = FALSE; - } - if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); - Status = AE_OK; - break; + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. + * + * If this occurs, we add an additional delay before actually entering + * the status checking loop, hopefully to allow the EC to go to work + * and produce a non-stale status. + */ + if (cold || rebooting || ec_polled_mode) { + static int once; + + if (EcCheckStatus(sc, "pre-check", Event) == AE_OK) { + if (!once) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; + } + AcpiOsStall(10); } - AcpiOsStall(EC_POLL_DELAY); } - /* - * If we still don't have a response and we're up and running, wait up - * to ec_timeout ms for completion, sleeping for chunks of 1 ms or the - * smallest resolution hz supports. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - if (!cold) { - slp_ival = hz / 1000; - if (slp_ival != 0) { - count = ec_timeout / slp_ival; - } else { - /* hz has less than 1000 Hz resolution so scale timeout. */ - slp_ival = 1; - count = ec_timeout / (1000 / hz); - } - } else - count = ec_timeout; + /* Wait for event by polling or GPE (interrupt). */ + if (cold || rebooting || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; + if (count == 0) + count = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (slp)"); - sc->ec_burstactive = FALSE; - } - if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); - Status = AE_OK; + Status = EcCheckStatus(sc, "poll", Event); + if (Status == AE_OK) break; + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout; + } else { + /* hz has less than 1 ms resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); + } + + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time we get one. It's possible to get a + * GPE for an event we're not interested in here (i.e., SCI for + * EC query). + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + Status = EcCheckStatus(sc, "sleep", Event); + if (Status == AE_OK) + break; } - if (!cold) { - retval = msleep(&sc->ec_csrvalue, &sc->ec_mtx, PZERO, "ecpoll", - slp_ival); - } else - AcpiOsStall(1000); + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); } - } + /* + * We finished waiting for the GPE and it never arrived. Try to + * read the register once and trust whatever value we got. This is + * the best we can do at this point. Then, force polled mode on + * since this system doesn't appear to generate GPEs. + */ + if (Status != AE_OK) { + Status = EcCheckStatus(sc, "sleep_end", Event); + device_printf(sc->ec_dev, + "wait timed out (%sresponse), forcing polled mode\n", + Status == AE_OK ? "" : "no "); + ec_polled_mode = TRUE; + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) @@ -994,6 +880,7 @@ ACPI_STATUS status; EC_EVENT event; EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); @@ -1013,15 +900,15 @@ event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - status = EcWaitEvent(sc, event); + status = EcWaitEvent(sc, event, gen_count); if (ACPI_SUCCESS(status)) { /* If we succeeded, burst flag should now be present. */ if (cmd == EC_COMMAND_BURST_ENABLE) { @@ -1029,11 +916,8 @@ if ((ec_status & EC_FLAG_BURST_MODE) == 0) status = AE_ERROR; } - } else { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); return (status); } @@ -1042,6 +926,7 @@ { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); @@ -1060,32 +945,32 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); return (status); } - *Data = EC_GET_DATA(sc); if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } return (AE_OK); -} +} static ACPI_STATUS EcWrite(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); @@ -1104,27 +989,27 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); return (status); } if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } --------------080704040001030502050209-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 18:20:27 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 532B016A419 for ; Tue, 18 Sep 2007 18:20:27 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id D3BB713C458 for ; Tue, 18 Sep 2007 18:20:26 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l8IIKPBa017429; Tue, 18 Sep 2007 22:20:25 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Tue, 18 Sep 2007 22:20:25 +0400 (MSD) From: Dmitry Morozovsky To: Eric Anderson In-Reply-To: <46EFF4C0.7070301@freebsd.org> Message-ID: <20070918221856.V17236@woozle.rinet.ru> References: <20070918175749.I97108@woozle.rinet.ru> <46EFF4C0.7070301@freebsd.org> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Tue, 18 Sep 2007 22:20:25 +0400 (MSD) Cc: kientzle@freebsd.org, current@freebsd.org Subject: Re: Misterious tar errors on today's current/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 18:20:27 -0000 On Tue, 18 Sep 2007, Eric Anderson wrote: EA> > marck@n5600:/usr/ports/archivers/rpm> uname -a EA> > FreeBSD n5600.rinet.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #4: Tue Sep 18 EA> > 17:23:00 MSD 2007 marck@n5600.rinet.ru:/usr/obj/usr/src/sys/MINI EA> > amd64 EA> > EA> > (freshly built system) [snip] EA> > marck@n5600:/usr/ports/archivers/rpm/work> tar tvzf EA> > /usr/ports/distfiles/rpm-3.0.6.tar.gz |grep aclocal EA> > -rw-rw-r-- 0 2161 2161 34470 Sep 13 2000 rpm-3.0.6/aclocal.m4 EA> > -rw-rw-r-- 0 2161 2161 34044 Sep 13 2000 rpm-3.0.6/popt/aclocal.m4 EA> > marck@n5600:/usr/ports/archivers/rpm/work> tar xzf EA> > /usr/ports/distfiles/rpm-3.0.6.tar.gz EA> > marck@n5600:/usr/ports/archivers/rpm/work> l rpm-3.0.6/acl* EA> > -rw-rw-r-- 1 marck wheel 6656 Sep 13 2000 rpm-3.0.6/aclocal.m4 EA> > EA> > So, aclocal.m4 does not extracted correctly. EA> > EA> > WTF? I'm out of ideas. EA> EA> Maybe try rolling these back: EA> EA> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libarchive/archive_write_disk.c.diff?&r1=1.14&r2=1.15&f=h EA> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libarchive/test/test_write_disk.c.diff?&r1=1.3&r2=1.4&f=h Yes it does help. Tim, would you please look at the problem? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 18:31:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70F6C16A469 for ; Tue, 18 Sep 2007 18:31:51 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 29FD513C46B for ; Tue, 18 Sep 2007 18:31:51 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 76F911CC26; Wed, 19 Sep 2007 06:31:49 +1200 (NZST) Date: Wed, 19 Sep 2007 06:31:49 +1200 From: Andrew Thompson To: vxn9344@louisiana.edu Message-ID: <20070918183149.GA11096@heff.fud.org.nz> References: <91729d710709180945r58f2d1d4vb6a4074e242cf2ab@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91729d710709180945r58f2d1d4vb6a4074e242cf2ab@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org Subject: Re: ath driver source code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 18:31:51 -0000 On Tue, Sep 18, 2007 at 11:45:03AM -0500, van nguyen wrote: > Hi all, > > I would like to know if the source code for ath driver (wireless driver for > atheros chipset) is available somewhere. > I understand that HAL part is not available but other part should be > available. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ath/ regards, Andrew From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 18:35:03 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C132A16A418 for ; Tue, 18 Sep 2007 18:35:03 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.de [194.25.134.19]) by mx1.freebsd.org (Postfix) with ESMTP id 644F013C4B5 for ; Tue, 18 Sep 2007 18:35:03 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from fwd28.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1IXh6a-00006V-02; Tue, 18 Sep 2007 19:43:24 +0200 Received: from localhost (SmC70ZZLwtcHWobf19GTmFlM8KIxREF38Iup01ivvcPYA1zTMZLMhKT34ZoGOW73LIGeRmfBsO@[84.165.71.68]) by fwd28.t-online.de with esmtp id 1IXh6J-0Cd9Hs0; Tue, 18 Sep 2007 19:43:07 +0200 Date: Tue, 18 Sep 2007 19:43:06 +0200 From: Oliver Herold To: freebsd-current@freebsd.org, current@freebsd.org Message-ID: <20070918174306.GA70714@olymp.home> Mail-Followup-To: freebsd-current@freebsd.org, current@freebsd.org References: <46F0072F.6010906@intersonic.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <46F0072F.6010906@intersonic.se> User-Agent: Mutt/1.5.16 (2007-06-09) X-ID: SmC70ZZLwtcHWobf19GTmFlM8KIxREF38Iup01ivvcPYA1zTMZLMhKT34ZoGOW73LIGeRmfBsO X-TOI-MSGID: 0c34de20-a87b-4828-8937-962971f470df Cc: Subject: Re: no apps builds on today's -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 18:35:03 -0000 So I'm not alone :-) todays current and I have got the same problem with OR= Bit2 and libIDL. I can compile these on another machine (Current from yesterday). Oliver On Tue, Sep 18, 2007 at 07:13:19PM +0200, Per olof Ljungmark wrote: > at least the ones I've tried... I assume we are in the middle of somethin= g=20 > right now? >=20 > Anyone have an idea what is going on or is it just me? >=20 > Example: > =3D=3D=3D> Building file daemon only. > =3D=3D=3D> Vulnerability check disabled, database not found > =3D=3D=3D> Found saved configuration for bacula-client-2.0.3 > =3D=3D=3D> Extracting for bacula-client-2.2.4 > =3D> MD5 Checksum OK for bacula-2.2.4.tar.gz. > =3D> SHA256 Checksum OK for bacula-2.2.4.tar.gz. > =3D=3D=3D> Patching for bacula-client-2.2.4 > =3D=3D=3D> Applying FreeBSD patches for bacula-client-2.2.4 > 1 out of 1 hunks failed--saving rejects to src/console/Makefile.in.rej > =3D> Patch patch-src-console-Makefile.in failed to apply cleanly. > =3D> Patch(es) patch-scripts-Makefile.in applied cleanly. > *** Error code 1 >=20 > or >=20 > =3D=3D=3D> Vulnerability check disabled, database not found > =3D> gmp-4.2.2.tar.gz doesn't seem to exist in /usr/ports/distfiles/. > =3D> Attempting to fetch from http://ftp.gnu.org/gnu/gmp/. > gmp-4.2.2.tar.gz 100% of 2226 kB 990 kBps > =3D=3D=3D> Extracting for libgmp-4.2.2 > =3D> MD5 Checksum OK for gmp-4.2.2.tar.gz. > =3D> SHA256 Checksum OK for gmp-4.2.2.tar.gz. > =3D=3D=3D> Patching for libgmp-4.2.2 > =3D=3D=3D> libgmp-4.2.2 depends on file: /usr/local/bin/libtool - found > =3D=3D=3D> Configuring for libgmp-4.2.2 > ./configure: 128: Syntax error: Unterminated quoted string > =3D=3D=3D> Script "configure" failed unexpectedly. > Please report the problem to ale@FreeBSD.org [maintainer] and attach the > "/usr/ports/math/libgmp4/work/gmp-4.2.2/config.log" including the output = of > the failure of your make command. Also, it might be a good idea to provide > an overview of all packages installed on your system (e.g. an `ls > /var/db/pkg`). > *** Error code 1 >=20 > Stop in /usr/ports/math/libgmp4. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --=20 The distinction between Jewish and goyish can be quite subtle, as the following quote from Lenny Bruce illustrates: "I'm Jewish. Count Basie's Jewish. Ray Charles is Jewish. Eddie Cantor's goyish. The B'nai Brith is goyish. The Hadassah is Jewish. Marine Corps -- heavy goyish, dangerous. "Kool-Aid is goyish. All Drake's Cakes are goyish. Pumpernickel is Jewish and, as you know, white bread is very goyish. Instant potatoes -- goyish. Black cherry soda's very Jewish. Macaroons are ____=08=08=08=08very Jewish. Fruit salad is Jewish. Lime Je= ll-O is goyish. Lime soda is ____=08=08=08=08very goyish. Trailer parks are so go= yish that Jews won't go near them ..." -- Arthur Naiman, "Every Goy's Guide to Yiddish" From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 19:16:15 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B028716A418; Tue, 18 Sep 2007 19:16:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5C67913C428; Tue, 18 Sep 2007 19:16:14 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8IJGDaa016093; Tue, 18 Sep 2007 15:16:13 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Tue, 18 Sep 2007 15:16:07 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709181516.11207.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4326/Tue Sep 18 14:30:43 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: [PATCH] OsdSynch.c modernization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 19:16:15 -0000 I have rewritten sys/dev/acpica/Osd/OsdSynch.c to match the modern ACPI-CA and -CURRENT: http://people.freebsd.org/~jkim/acpica/OsdSynch.diff Major changes are: 1. Semaphore is reimplemented with convar(9) instead of mutex(9). 2. Semaphore with ACPI_WAIT_FOREVER option actually waits forever now. 3. Obsolete and/or hidden debugging knobs and macros are removed. 4. ACPI-CA introduced AcpiOs*Mutex() to complement AcpiOs*Semaphore(): http://bugzilla.kernel.org/show_bug.cgi?id=6634 These functions are implemented and turned on by default. 5. Spinlock is reimplemented with sx lock and more closely implements the intended behaviour (e.g., save/restore interrupts). It is orthogonal to Nate's effort of rewriting acpi_ec.c but I'd like get more feedback *with* his last patch (revision D) because his patch will be committed sooner or later. ;-) Please test/review and let us know if there is any regression or not. Thanks! Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 20:22:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B037D16A46E for ; Tue, 18 Sep 2007 20:22:59 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id F37CA13C4B0 for ; Tue, 18 Sep 2007 20:22:58 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1520780nfb for ; Tue, 18 Sep 2007 13:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=IoiYFbMKieWHWmAvwq530lFhpUJjcxGGloLsp0qA4eY=; b=EYAFRagqPf9cpVWY/4ddpJl6M8SrB5TFMY1BcJHPijYiDDDupLNeWnlcVlOtVHDww+iSdieL6MSARR2lYWYRmrGmXzAgsZ0viMXXwJyg2Aa9bMB9fHywhqxVVUEIvHdtFpTBuvE+CH8O/c/C3Jn1AO9XI+1mFFVjde7AM1+ti44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=BbUIELtpnrghbQ6nKtqWpxB1f2CnL83oY/LOJM7lveWbEYjFOlFS7r6yZiLho07YmJKN/K4kKaE8E2/Q06mCHV3//3LMRsW2Qvn6xQBOl0w/GAoqrI0TdbFFquFNy7GjuxHe4KwRpiGTVWMOqFg7oQBt2bM87eX62T2gPmLtd1g= Received: by 10.86.80.5 with SMTP id d5mr4934642fgb.1190146977585; Tue, 18 Sep 2007 13:22:57 -0700 (PDT) Received: from roadrunner.spoerlein.net ( [85.180.172.144]) by mx.google.com with ESMTPS id b17sm11033940fka.2007.09.18.13.22.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2007 13:22:57 -0700 (PDT) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id l8IKMpKB001445; Tue, 18 Sep 2007 22:22:51 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id l8IKMopD001444; Tue, 18 Sep 2007 22:22:50 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Tue, 18 Sep 2007 22:22:50 +0200 From: Ulrich Spoerlein To: Scott Long Message-ID: <20070918202250.GA1403@roadrunner.spoerlein.net> Mail-Followup-To: Scott Long , freebsd-scsi@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, njl@FreeBSD.ORG References: <46E615C4.1010605@samsco.org> <20070916115427.GA1427@roadrunner.spoerlein.net> <46ED6C50.4040104@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46ED6C50.4040104@samsco.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-scsi@FreeBSD.ORG, njl@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Retirement of CAM_QUIRK_NOSERIAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 20:22:59 -0000 On Sun, 16.09.2007 at 11:48:00 -0600, Scott Long wrote: > Ulrich Spoerlein wrote: > > On Mon, 10.09.2007 at 22:12:52 -0600, Scott Long wrote: > >> All, > >> > >> The attached patch should make CAM behave properly with regard to > >> probing device serial numbers only when the device advertises that > >> it supports it. It will hopefully eliminate the need for the > >> CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated > >> legacy problem that may or may not be possible to fix). This should > >> especially benefit USB-UMASS devices, where the console output should > >> be less noisy. It might even make more devices work out-of-the-box. > > While this patch is working fine with my USB/FW HDD enclosure, it breaks > > my MP3 USB stick > > kernel: umass0: on uhub5 > > kernel: umass0: BBB reset failed, IOERROR > > kernel: umass0: BBB bulk-in clear stall failed, IOERROR > > kernel: umass0: BBB bulk-out clear stall failed, IOERROR > > Is this a regression of something that works without the patch, or is > it something that has never worked? What happens if you use the > NO_INQUIRY_EVPD quirk instead? Ok, I played around a bit and with your patch applied, I have to *remove* the quirk for my Samsung device, then it starts attaching again. That's a good thing, right? :) umass0: on uhub3 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 999MB (511616 2048 byte sectors: 64H 32S/T 249C) There are only two other devices right now, that require a SHUTTLE_INIT quirk, perhaps they are broken by your patch, too. Btw, why are there devices in umass.c with NO_QUIRKS set? Shouldn't those entries be removed? Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 20:29:40 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 910B916A417; Tue, 18 Sep 2007 20:29:40 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id 61BFE13C457; Tue, 18 Sep 2007 20:29:40 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from dhcp-1-248.packetdesign.com (firewall-gw-dirty-n.packetdesign.com [65.87.20.98]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l8IKTevZ022624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 13:29:40 -0700 Message-ID: <46F0351E.4080009@freebsd.org> Date: Tue, 18 Sep 2007 13:29:18 -0700 From: "Bruce A. Mah" User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Dmitry Morozovsky References: <20070918175749.I97108@woozle.rinet.ru> <46EFF4C0.7070301@freebsd.org> <20070918221856.V17236@woozle.rinet.ru> In-Reply-To: <20070918221856.V17236@woozle.rinet.ru> X-Enigmail-Version: 0.95.3 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig929893194203414616695C8D" Cc: kientzle@freebsd.org, current@freebsd.org Subject: Re: Misterious tar errors on today's current/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 20:29:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig929893194203414616695C8D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Dmitry Morozovsky wrote: > On Tue, 18 Sep 2007, Eric Anderson wrote: >=20 > EA> > marck@n5600:/usr/ports/archivers/rpm> uname -a > EA> > FreeBSD n5600.rinet.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #4: Tue Se= p 18 > EA> > 17:23:00 MSD 2007 marck@n5600.rinet.ru:/usr/obj/usr/src/sys/M= INI > EA> > amd64 > EA> >=20 > EA> > (freshly built system) >=20 > [snip] >=20 > EA> > marck@n5600:/usr/ports/archivers/rpm/work> tar tvzf > EA> > /usr/ports/distfiles/rpm-3.0.6.tar.gz |grep aclocal > EA> > -rw-rw-r-- 0 2161 2161 34470 Sep 13 2000 rpm-3.0.6/aclocal= =2Em4 > EA> > -rw-rw-r-- 0 2161 2161 34044 Sep 13 2000 rpm-3.0.6/popt/ac= local.m4 > EA> > marck@n5600:/usr/ports/archivers/rpm/work> tar xzf > EA> > /usr/ports/distfiles/rpm-3.0.6.tar.gz > EA> > marck@n5600:/usr/ports/archivers/rpm/work> l rpm-3.0.6/acl* > EA> > -rw-rw-r-- 1 marck wheel 6656 Sep 13 2000 rpm-3.0.6/aclocal.m= 4 > EA> >=20 > EA> > So, aclocal.m4 does not extracted correctly. > EA> >=20 > EA> > WTF? I'm out of ideas.=20 > EA>=20 > EA> Maybe try rolling these back: > EA>=20 > EA> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libarchive/archive_wr= ite_disk.c.diff?&r1=3D1.14&r2=3D1.15&f=3Dh > EA> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libarchive/test/test_= write_disk.c.diff?&r1=3D1.3&r2=3D1.4&f=3Dh >=20 > Yes it does help. Tim, would you please look at the problem? With my RE hat on, I've backed out these changes, to give Tim a chance to fix the original problem without pressure. Bruce. --------------enig929893194203414616695C8D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFG8DUe2MoxcVugUsMRAqG7AKCExmTV3A70IfNzDkmm23ZIPa4XrACXYs/S Lx2yXfEg28kZU1n3rKdw+A== =lQg3 -----END PGP SIGNATURE----- --------------enig929893194203414616695C8D-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 20:33:46 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22DC116A46B for ; Tue, 18 Sep 2007 20:33:46 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id E305A13C480 for ; Tue, 18 Sep 2007 20:33:45 +0000 (UTC) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <46F03625.3060906@intersonic.se> Date: Tue, 18 Sep 2007 22:33:41 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: current@freebsd.org References: <46F0072F.6010906@intersonic.se> <20070918174306.GA70714@olymp.home> In-Reply-To: <20070918174306.GA70714@olymp.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: no apps builds on today's -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 20:33:46 -0000 Oliver Herold wrote: > So I'm not alone :-) todays current and I have got the same problem with ORBit2 and > libIDL. I can compile these on another machine (Current from yesterday). > > Oliver > > On Tue, Sep 18, 2007 at 07:13:19PM +0200, Per olof Ljungmark wrote: >> at least the ones I've tried... I assume we are in the middle of something >> right now? >> Look for a post earlier today "Misterious tar errors on today's current/amd64", there's your answer, libarchive is hosed. From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 20:39:25 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B31716A418 for ; Tue, 18 Sep 2007 20:39:25 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id 3534513C45B for ; Tue, 18 Sep 2007 20:39:25 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from dhcp-1-248.packetdesign.com (firewall-gw-dirty-n.packetdesign.com [65.87.20.98]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l8IKdOWP027174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 13:39:24 -0700 Message-ID: <46F03766.8030707@freebsd.org> Date: Tue, 18 Sep 2007 13:39:02 -0700 From: "Bruce A. Mah" User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Per olof Ljungmark References: <46F0072F.6010906@intersonic.se> <20070918174306.GA70714@olymp.home> <46F03625.3060906@intersonic.se> In-Reply-To: <46F03625.3060906@intersonic.se> X-Enigmail-Version: 0.95.3 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4B9AFB285880EFABCFFAD562" Cc: current@freebsd.org Subject: Re: no apps builds on today's -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 20:39:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B9AFB285880EFABCFFAD562 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Per olof Ljungmark wrote: > Oliver Herold wrote: >> So I'm not alone :-) todays current and I have got the same problem wi= th ORBit2 and >> libIDL. I can compile these on another machine (Current from yesterday= ). >> >> Oliver >> >> On Tue, Sep 18, 2007 at 07:13:19PM +0200, Per olof Ljungmark wrote: >>> at least the ones I've tried... I assume we are in the middle of some= thing=20 >>> right now? >>> >=20 > Look for a post earlier today "Misterious tar errors on today's=20 > current/amd64", there's your answer, libarchive is hosed. I backed the change out a few minutes ago...if you grab these revisions you should be good to go: src/lib/libarchive/archive_write_disk.c,v 1.16 src/lib/libarchive/test/test_write_disk.c,v 1.5 Bruce. --------------enig4B9AFB285880EFABCFFAD562 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8Ddm2MoxcVugUsMRArvvAKDTAuM36QR9oTz1WJtP4LKdt2w1KACfUKjx ifRcQfNHRlcdRfox9GKadUY= =77tY -----END PGP SIGNATURE----- --------------enig4B9AFB285880EFABCFFAD562-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 20:42:45 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80D7516A418 for ; Tue, 18 Sep 2007 20:42:45 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4076513C457 for ; Tue, 18 Sep 2007 20:42:45 +0000 (UTC) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <46F03840.8020909@intersonic.se> Date: Tue, 18 Sep 2007 22:42:40 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: "Bruce A. Mah" References: <46F0072F.6010906@intersonic.se> <20070918174306.GA70714@olymp.home> <46F03625.3060906@intersonic.se> <46F03766.8030707@freebsd.org> In-Reply-To: <46F03766.8030707@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: no apps builds on today's -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 20:42:45 -0000 Bruce A. Mah wrote: > If memory serves me right, Per olof Ljungmark wrote: >> Oliver Herold wrote: >>> So I'm not alone :-) todays current and I have got the same problem with ORBit2 and >>> libIDL. I can compile these on another machine (Current from yesterday). >>> >>> Oliver >>> >>> On Tue, Sep 18, 2007 at 07:13:19PM +0200, Per olof Ljungmark wrote: >>>> at least the ones I've tried... I assume we are in the middle of something >>>> right now? >>>> >> Look for a post earlier today "Misterious tar errors on today's >> current/amd64", there's your answer, libarchive is hosed. > > I backed the change out a few minutes ago...if you grab these revisions > you should be good to go: > > src/lib/libarchive/archive_write_disk.c,v 1.16 > src/lib/libarchive/test/test_write_disk.c,v 1.5 Yes, I can confirm it works, thanks. From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 21:23:14 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FB0116A419; Tue, 18 Sep 2007 21:23:14 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (unknown [IPv6:2001:b30:5000:2:20e:cff:fe4b:ca01]) by mx1.freebsd.org (Postfix) with ESMTP id 04F3813C46C; Tue, 18 Sep 2007 21:23:14 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 9320A50884; Wed, 19 Sep 2007 00:23:12 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on local.mail.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDmnNXHqVpns; Wed, 19 Sep 2007 00:23:09 +0300 (EEST) Received: from [172.27.2.200] (c7.campus.utcluj.ro [193.226.6.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id 7307350873; Wed, 19 Sep 2007 00:23:09 +0300 (EEST) Message-ID: <46F041BC.6070604@net.utcluj.ro> Date: Wed, 19 Sep 2007 00:23:08 +0300 From: Cristian KLEIN User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Jung-uk Kim References: <200709181516.11207.jkim@FreeBSD.org> In-Reply-To: <200709181516.11207.jkim@FreeBSD.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [PATCH] OsdSynch.c modernization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 21:23:14 -0000 Jung-uk Kim wrote: > I have rewritten sys/dev/acpica/Osd/OsdSynch.c to match the modern > ACPI-CA and -CURRENT: > > http://people.freebsd.org/~jkim/acpica/OsdSynch.diff > > Major changes are: > > 1. Semaphore is reimplemented with convar(9) instead of mutex(9). > > 2. Semaphore with ACPI_WAIT_FOREVER option actually waits forever now. > > 3. Obsolete and/or hidden debugging knobs and macros are removed. > > 4. ACPI-CA introduced AcpiOs*Mutex() to complement AcpiOs*Semaphore(): > > http://bugzilla.kernel.org/show_bug.cgi?id=6634 > > These functions are implemented and turned on by default. > > 5. Spinlock is reimplemented with sx lock and more closely implements > the intended behaviour (e.g., save/restore interrupts). > > It is orthogonal to Nate's effort of rewriting acpi_ec.c but I'd like > get more feedback *with* his last patch (revision D) because his > patch will be committed sooner or later. ;-) > > Please test/review and let us know if there is any regression or not. Sorry for not being able to test the patch. May I assume this will fix: http://www.freebsd.org/cgi/query-pr.cgi?pr=114113 http://www.freebsd.org/cgi/query-pr.cgi?pr=114649 From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 21:29:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33FD516A417 for ; Tue, 18 Sep 2007 21:29:43 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from signal.itea.ntnu.no (signal.itea.ntnu.no [129.241.190.231]) by mx1.freebsd.org (Postfix) with ESMTP id B8E0213C428 for ; Tue, 18 Sep 2007 21:29:42 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by signal.itea.ntnu.no (Postfix) with ESMTP id 2121133711; Tue, 18 Sep 2007 23:26:33 +0200 (CEST) Received: from caracal.stud.ntnu.no (caracal.stud.ntnu.no [129.241.56.185]) by signal.itea.ntnu.no (Postfix) with ESMTP; Tue, 18 Sep 2007 23:26:32 +0200 (CEST) Received: by caracal.stud.ntnu.no (Postfix, from userid 2312) id CD45E6240EC; Tue, 18 Sep 2007 23:26:32 +0200 (CEST) Date: Tue, 18 Sep 2007 23:26:32 +0200 From: Ulf Lilleengen To: Barnabas Message-ID: <20070918212632.GA4411@stud.ntnu.no> References: <20070813204035.GA5338@stud.ntnu.no> <12747042.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12747042.post@talk.nabble.com> User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: freebsd-current@freebsd.org Subject: Re: Testers wanted: Gvinum patches of SoC 2007 work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 21:29:43 -0000 On man, sep 17, 2007 at 04:18:42 -0700, Barnabas wrote: > > Hi Ulf > [...] > I have had a lot of issues with the semi-finished version of gvinum that is > currently available though the freebsd distro. I have had a lot of DMA > read/write timeout issues lately. Especially under heavy load. But only on > my ata drives - the scsi drives runs perfectly. First I thought it was a > dead disk, but I have been seeing the issue on my new raid5 setup as well. > The same issue on two disk at the same time is not very likely. If you have > any info on how I am to patch the current vinum driver with the new changes > you made it would be great. > > I really appreciate someone is looking at this exellent software. It has not > really worked 100% since the port to geom was started. > > Heres my config: > > FreeBSD sauron.barnabas.dk 6.2-RELEASE-p6 FreeBSD 6.2-RELEASE-p6 #0: Wed Jul > 18 23:33:58 CEST 2007 > root@sauron.barnabas.dk:/usr/src/sys/i386/compile/KERNEL_6_2 i386 > > Here is some of the errors I have experienced: > [...] > Sep 17 16:54:03 sauron kernel: subdisk10: detached > Sep 17 16:54:03 sauron kernel: ad10: detached > Sep 17 16:54:03 sauron kernel: ad11: FAILURE - device detached > Sep 17 16:54:03 sauron kernel: subdisk11: detached > Sep 17 16:54:03 sauron kernel: ad11: detached Hi, I think this problem is not related to gvinum actually. As you can see, there are detach notices from ad11. This is most probably a problem with the hd controller, or the controller driver, or the drives (but highly unlikely since both fail), or a bug in the driver (since this only happens under heavy load). You can try to use atacontrol(8) to set the transfer mode of the ATA controller. This might indicate more specifically what's the problem. Other than that, giving information about your controller and harddrive hardware would help. Also, because of the ATA problem , applying the new gvinum patch wouldn't help you solve any of these issues. However, since you tried the patch and it failed (as you noted in the e-mail you sent privately), I'd like to know the output you got from that (dmesg, 'gvinum list', 'gvinum printconfig'). -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 21:35:01 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F34316A417; Tue, 18 Sep 2007 21:35:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id C55B813C428; Tue, 18 Sep 2007 21:35:00 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8ILYxXE028272; Tue, 18 Sep 2007 17:34:59 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Cristian KLEIN Date: Tue, 18 Sep 2007 17:34:54 -0400 User-Agent: KMail/1.6.2 References: <200709181516.11207.jkim@FreeBSD.org> <46F041BC.6070604@net.utcluj.ro> In-Reply-To: <46F041BC.6070604@net.utcluj.ro> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709181734.57392.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4330/Tue Sep 18 16:02:40 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [PATCH] OsdSynch.c modernization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 21:35:01 -0000 On Tuesday 18 September 2007 05:23 pm, Cristian KLEIN wrote: > Jung-uk Kim wrote: > > I have rewritten sys/dev/acpica/Osd/OsdSynch.c to match the > > modern ACPI-CA and -CURRENT: > > > > http://people.freebsd.org/~jkim/acpica/OsdSynch.diff > > > > Major changes are: > > > > 1. Semaphore is reimplemented with convar(9) instead of mutex(9). > > > > 2. Semaphore with ACPI_WAIT_FOREVER option actually waits forever > > now. > > > > 3. Obsolete and/or hidden debugging knobs and macros are removed. > > > > 4. ACPI-CA introduced AcpiOs*Mutex() to complement > > AcpiOs*Semaphore(): > > > > http://bugzilla.kernel.org/show_bug.cgi?id=6634 > > > > These functions are implemented and turned on by default. > > > > 5. Spinlock is reimplemented with sx lock and more closely > > implements the intended behaviour (e.g., save/restore > > interrupts). > > > > It is orthogonal to Nate's effort of rewriting acpi_ec.c but I'd > > like get more feedback *with* his last patch (revision D) because > > his patch will be committed sooner or later. ;-) > > > > Please test/review and let us know if there is any regression or > > not. > > Sorry for not being able to test the patch. May I assume this will > fix: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=114113 > http://www.freebsd.org/cgi/query-pr.cgi?pr=114649 I believe my patch AND Nate's patch will fix the problem. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 22:19:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84E5E16A417 for ; Tue, 18 Sep 2007 22:19:10 +0000 (UTC) (envelope-from Mathias.Picker@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DAA2E13C467 for ; Tue, 18 Sep 2007 22:19:09 +0000 (UTC) (envelope-from Mathias.Picker@gmx.de) Received: (qmail invoked by alias); 18 Sep 2007 21:52:26 -0000 Received: from dslb-084-056-056-176.pools.arcor-ip.net (EHLO [192.168.178.22]) [84.56.56.176] by mail.gmx.net (mp019) with SMTP; 18 Sep 2007 23:52:26 +0200 X-Authenticated: #23891974 X-Provags-ID: V01U2FsdGVkX19qK6Y4wZRqt3g0lg5V+hmNtVvwsQ8bBiJf1Cgj/g lynhJClfA7JPgO From: Mathias Picker To: freebsd-current@freebsd.org Content-Type: text/plain Date: Tue, 18 Sep 2007 23:51:05 +0200 Message-Id: <1190152265.4754.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: updated today, now I can't build ports?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 22:19:10 -0000 All ports I tried had problems with some patches, e.g. ===> Applying FreeBSD patches for abiword-gnome-2.4.6_1 3 out of 3 hunks failed--saving rejects to GNUmakefile.in.rej (which build fine yesterday) is patch broken? I really do not have the time to investigate, will fly to italy in a few hours (that's why I tried to install koffice right now && discovered this). Cheers, Mathias From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 22:19:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ABF416A419 for ; Tue, 18 Sep 2007 22:19:58 +0000 (UTC) (envelope-from trigves@yahoo.com) Received: from web52705.mail.re2.yahoo.com (web52705.mail.re2.yahoo.com [206.190.48.228]) by mx1.freebsd.org (Postfix) with SMTP id C4DFB13C491 for ; Tue, 18 Sep 2007 22:19:57 +0000 (UTC) (envelope-from trigves@yahoo.com) Received: (qmail 61969 invoked by uid 60001); 18 Sep 2007 21:53:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=1ixjM1ApY9Qc+EqjfbFleqh2ZYQ1LXfvqKtkdJb5pH+5Nc/IPcAu1GhTW0UG8GVtDuCUv/a2RhM321Ado4Br93fhwgvVW+1rTfGRIveCF7yXiFtca0DruGI0jpMG6hPrpJywli7KmE4z/1fqcdeFDiYwEMQMYZe0PCB//nTCaxo=; X-YMail-OSG: dZgz.FwVM1luG60KrVADy_KoAqHkGD9QJR6OVuidutXTZO6gTGTrNPF.GAbGOjU7FrlpT42UqhkTdWIzXW35TzV14DUARrhJYJSN9C059m6.5Q-- Received: from [209.73.178.43] by web52705.mail.re2.yahoo.com via HTTP; Tue, 18 Sep 2007 14:53:16 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Tue, 18 Sep 2007 14:53:16 -0700 (PDT) From: Trigve Siver To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <693209.58240.qm@web52705.mail.re2.yahoo.com> Subject: FAILURE - non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 22:19:58 -0000 Hi,=0A=0AWhen using vlc for playing DVD on -CURRENT I've got this errors:= =0A=0Aata1: FAILURE - non aligned DMA transfer attempted=0Aacd0: setting up= DMA failed =0A=0AThe DVD movie is choppy and can't be watch at all ... Whe= n using same vlc in 6.2 everythings works fine=0A=0ACan anyone tell me wher= e could be the problem?=0A=0Athank Trigve=0A=0AMy dmesg:=0A=0ACopyright (c)= 1992-2007 The FreeBSD Project.=0ACopyright (c) 1979, 1980, 1983, 1986, 198= 8, 1989, 1991, 1992, 1993, 1994=0A The Regents of the University of = California. All rights reserved.=0AFreeBSD is a registered trademark of The= FreeBSD Foundation.=0AFreeBSD 7.0-CURRENT #6: Tue Sep 18 23:17:46 CEST 200= 7=0A dodes@pentium4.domain:/usr/obj/usr/src/sys/CUSTOM=0ATimecounter "i8= 254" frequency 1193182 Hz quality 0=0ACPU: Intel(R) Pentium(R) 4 CPU 2.40GH= z (2410.84-MHz 686-class CPU)=0A Origin =3D "GenuineIntel" Id =3D 0xf27 = Stepping =3D 7=0A Features=3D0xbfebfbff=0A Features2=3D0x4400=0Areal memory =3D 536805= 376 (511 MB)=0Aavail memory =3D 507179008 (483 MB)=0AACPI APIC Table: =0Aioapic0 irqs 0-23 on motherboard=0Akbd1 at kbd= mux0=0Aath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, R= F5413)=0Aacpi0: on motherboard=0Aacpi0: [ITHREAD]=0Aacpi0= : Power Button (fixed)=0Aacpi0: reservation of 0, a0000 (3) failed=0Aacpi0:= reservation of 100000, 1fef0000 (3) failed=0ATimecounter "ACPI-fast" frequ= ency 3579545 Hz quality 1000=0Aacpi_timer0: <24-bit timer at 3.579545MHz> p= ort 0x408-0x40b on acpi0=0Acpu0: on acpi0=0Ap4tcc0: on cpu0=0Aacpi_button0: on acpi0=0Apcib0= : port 0xcf8-0xcff on acpi0=0Apci0: o= n pcib0=0Apcib1: at device 1.0 on pci0=0Apci1: o= n pcib1=0Anvidia0: mem 0xe4000000-0xe4ffffff,0xd0000000-0= xdfffffff irq 16 at device 0.0 on pci1=0Anvidia0: [GIANT-LOCKED]=0Anvidia0:= [ITHREAD]=0Auhci0: port 0xe300= -0xe31f irq 16 at device 29.0 on pci0=0Auhci0: [GIANT-LOCKED]=0Auhci0: [ITH= READ]=0Ausb0: on uhci0=0Ausb0: = USB revision 1.0=0Auhub0: on usb0=0Auhub0: 2 ports with 2 removable, self powered=0Auhci1: port 0xe000-0xe01f irq 19 at devic= e 29.1 on pci0=0Auhci1: [GIANT-LOCKED]=0Auhci1: [ITHREAD]=0Ausb1: on uhci1=0Ausb1: USB revision 1.0=0Auhub= 1: on usb1=0Auhub1:= 2 ports with 2 removable, self powered=0Auhci2: port 0xe100-0xe11f irq 18 at device 29.2 on pci0=0Auhci2:= [GIANT-LOCKED]=0Auhci2: [ITHREAD]=0Ausb2: on uhci2=0Ausb2: USB revision 1.0=0Auhub2: on usb2=0Auhub2: 2 ports with 2 removab= le, self powered=0Auhci3: port = 0xe200-0xe21f irq 16 at device 29.3 on pci0=0Auhci3: [GIANT-LOCKED]=0Auhci3= : [ITHREAD]=0Ausb3: on uhci3=0A= usb3: USB revision 1.0=0Auhub3: on usb3=0Auhub3: 2 ports with 2 removable, self powered=0Aehci= 0: mem 0xe8100000-0xe81003ff ir= q 23 at device 29.7 on pci0=0Aehci0: [GIANT-LOCKED]=0Aehci0: [ITHREAD]=0Aus= b4: EHCI version 1.0=0Ausb4: companion controllers, 2 ports each: usb0 usb1= usb2 usb3=0Ausb4: on ehci0=0Au= sb4: USB revision 2.0=0Auhub4: on usb4=0Auhub4: 8 ports with 8 removable, self powered=0Apcib2= : at device 30.0 on pci0=0Apci2: on pc= ib2=0Aath0: mem 0xe7000000-0xe700ffff irq 19 at device 2.0 o= n pci2=0Aath0: [ITHREAD]=0Aath0: using obsoleted if_watchdog interface=0Aat= h0: Ethernet address: 00:17:9a:af:62:da=0Aath0: mac 7.9 phy 4.5 radio 5.6= =0Aemu10kx0: port 0xd000-0xd01f irq 20 at devic= e 3.0 on pci2=0Aemu10kx0: [ITHREAD]=0Apcm0: on emu10kx0=0Apcm0: =0Apcm1: on emu10kx0=0Apci2: at device 3.1 (no driv= er attached)=0Apci2: at device 4.0 (no driver attached)= =0Apci2: at device 4.1 (no driver attached)=0Arl0: port 0xd200-0xd2ff mem 0xe7010000-0xe70100ff irq 22 at dev= ice 5.0 on pci2=0Amiibus0: on rl0=0Arlphy0: PHY 0 on miibus0=0Arlphy0: 10baseT, 10baseT-FDX, 100baseTX, = 100baseTX-FDX, auto=0Arl0: Ethernet address: 00:04:61:94:2f:19=0Arl0: [ITHR= EAD]=0Aisab0: at device 31.0 on pci0=0Aisa0: on = isab0=0Aatapci0: port 0x1f0-0x1f7,0x3f6,0x1= 70-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0=0Aata0: = on atapci0=0Aata0: [ITHREAD]=0Aata1: on atapci0=0Aata1: [I= THREAD]=0Aatapci1: port 0xe400-0xe407,0xe50= 0-0xe503,0xe600-0xe607,0xe700-0xe703,0xe800-0xe80f irq 18 at device 31.2 on= pci0=0Aatapci1: [ITHREAD]=0Aata2: on atapci1=0Aata2: [ITHR= EAD]=0Aata3: on atapci1=0Aata3: [ITHREAD]=0Apci0: at device 31.3 (no driver attached)=0Aacpi_tz0: o= n acpi0=0Afdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq = 2 on acpi0=0Afdc0: [FILTER]=0Afd0: <1440-KB 3.5" drive> on fdc0 drive 0=0As= io0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi= 0=0Asio0: type 16550A=0Asio0: [FILTER]=0Asio1: <16550A-compatible COM port>= port 0x2f8-0x2ff irq 3 on acpi0=0Asio1: type 16550A=0Asio1: [FILTER]=0Aatk= bdc0: port 0x60,0x64 irq 1 on acpi0=0Aatkbd0:= irq 1 on atkbdc0=0Akbd0 at atkbd0=0Aatkbd0: [GIANT-LOCKED]= =0Aatkbd0: [ITHREAD]=0Apsm0: irq 12 on atkbdc0=0Apsm0: [GIANT-= LOCKED]=0Apsm0: [ITHREAD]=0Apsm0: model MouseMan+, device ID 0=0Apmtimer0 o= n isa0=0Asc0: at flags 0x100 on isa0=0Asc0: VGA <16 virtua= l consoles, flags=3D0x300>=0Avga0: at port 0x3c0-0x3df io= mem 0xa0000-0xbffff on isa0=0Appc0: at port 0x378-0x37f irq= 7 on isa0=0Appc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode= =0Appc0: FIFO with 16/16/9 bytes threshold=0Appbus0: on= ppc0=0Aplip0: on ppbus0=0Alpt0: on ppbu= s0=0Alpt0: Interrupt-driven port=0Appi0: on ppbus0=0Appc0: [= GIANT-LOCKED]=0Appc0: [ITHREAD]=0Auhid0: on uhub1=0ATimecounter "TSC" frequ= ency 2410836792 Hz quality 800=0ATimecounters tick every 1.000 msec=0Aad0: = 114473MB at ata0-master UDMA100=0Aad1: 39266= MB at ata0-slave UDMA100=0Aacd0: DVDR = at ata1-master UDMA33=0Aacd1: DVDROM at ata1-slave UDMA33=0AGEOM_LABEL: Label for provider acd0= is iso9660/M000288.=0Aacd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 a= scq=3D0x00 =0Aacd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x0= 0 =0Aacd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 sks=3D0= x40 0x00 0x01=0Aacd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0= x00 sks=3D0x40 0x00 0x01=0Acd0 at ata1 bus 0 target 0 lun 0=0Acd0: Removable CD-ROM SCSI-0 device =0Acd0: 33.000MB/s = transfers=0Acd0: cd present [3967854 x 2048 byte records]=0Ahwpmc: TSC/1/0x= 20 P4/18/0xfff Removable CD-ROM SCSI-0 device =0Acd1: 33.000= MB/s transfers=0Acd1: Attempt to query device size failed: NOT READY, Mediu= m not present=0AEA,WRI,INV,QUA,PRC,TAG,CSC>=0ATrying to mount root from ufs= :/dev/ad0s1a=0ALoading configuration files.=0Akernel dumps on /dev/ad0s4b= =0AEntropy harvesting:=0A interrupts=0A ethernet=0A point_to_point=0A kicks= tart=0A.=0Aswapon: adding /dev/ad0s4b as swap device=0AStarting file system= checks:=0A/dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS=0A/dev/ad0s1a: c= lean, 84617 free (401 frags, 10527 blocks, 0.2% fragmentation)=0A/dev/ad0s1= e: FILE SYSTEM CLEAN; SKIPPING CHECKS=0A/dev/ad0s1e: clean, 253765 free (29= frags, 31717 blocks, 0.0% fragmentation)=0A/dev/ad0s1f: FILE SYSTEM CLEAN;= SKIPPING CHECKS=0A/dev/ad0s1f: clean, 10738103 free (81823 frags, 1332035 = blocks, 0.6% fragmentation)=0A/dev/ad0s1d: FILE SYSTEM CLEAN; SKIPPING CHEC= KS=0A/dev/ad0s1d: clean, 677755 free (5771 frags, 83998 blocks, 0.8% fragme= ntation)=0ASetting hostuuid: d76c6880-48fd-11dc-9917-00179aaf62da.=0ASettin= g hostid: 0x799f6634.=0AMounting local file systems:=0A.=0ASetting hostname= : pentium4.domain.=0Anet.inet6.ip6.auto_linklocal: =0A1=0A -> =0A0=0A=0ASta= rting wpa_supplicant.=0Alo0: flags=3D8049 me= tric 0 mtu 16384=0A inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 =0A = inet6 ::1 prefixlen 128 =0A inet 127.0.0.1 netmask 0xff000000 = =0Aath0: flags=3D8843 metric 0 mtu = 1500=0A ether 00:17:9a:af:62:da=0A inet 192.168.1.15 netmask = 0xffffff00 broadcast 192.168.1.255=0A media: IEEE 802.11 Wireless Et= hernet autoselect (autoselect)=0A status: no carrier=0A ssid = "" channel 6 (2437 Mhz 11g)=0A authmode WPA1+WPA2/802.11i privacy ON= deftxkey UNDEF txpowmax 36=0A bmiss 7 scanvalid 60 bgscan bgscanint= vl 300 bgscanidle 250=0A roam:rssi11g 14 roam:rate11g 5 protmode CTS= burst roaming MANUAL=0Aadd net default: gateway 192.168.1.1=0AAdditional r= outing options:=0A.=0AStarting devd.=0Ahw.acpi.cpu.cx_lowest: =0AC1=0A=0Asy= sctl: =0Ahw.acpi.cpu.cx_lowest=0A: =0AInvalid argument=0AAdditional IP opti= ons:=0A.=0AMounting NFS file systems:=0A.=0AELF ldconfig path: /lib /usr/li= b /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/c= ompat /usr/local/lib/compat/pkg /usr/local/lib/evolution/2.10 /usr/local/li= b/nss /usr/local/lib/pth=0Aa.out ldconfig path: /usr/lib/aout /usr/lib/comp= at/aout=0AClearing /tmp (X related).=0ACreating and/or trimming log files:= =0A.=0AStarting syslogd.=0AChecking for core dump on /dev/ad0s4b...=0Asavec= ore: no dumps found=0AInitial i386 initialization:=0A.=0AAdditional ABI sup= port:=0A linux=0A.=0AStarting dbus.=0AStarting system_tools_backends.=0ASta= rting polkitd.=0AStarting hald.=0AStarting default moused:=0A.=0AStarting l= ocal daemons:=0A.=0AUpdating motd=0A.=0AMounting late file systems:=0A.=0AS= tarting gdm.=0AStarting avahi-daemon.=0AStarting avahi-dnsconfd.=0AConfigur= ing syscons:=0A keyrate=0A blanktime=0A.=0AStarting sshd.=0Aath0: link stat= e changed to UP=0AStarting cron.=0ALocal package initialization:=0A.=0AStar= ting inetd.=0AStarting background file system checks in 60 seconds.=0A=0ATu= e Sep 18 23:37:00 CEST 2007=0Aata1: FAILURE - non aligned DMA transfer atte= mpted=0Aacd0: setting up DMA failed=0Aacd0: FAILURE - REPORT_KEY ILLEGAL RE= QUEST asc=3D0x6f ascq=3D0x04 =0Aata1: FAILURE - non aligned DMA transfer at= tempted=0Aacd0: setting up DMA failed=0Aata1: FAILURE - non aligned DMA tra= nsfer attempted=0Aacd0: setting up DMA failed=0Aacd0: FAILURE - REPORT_KEY = ILLEGAL REQUEST asc=3D0x6f ascq=3D0x04 =0Aata1: FAILURE - non aligned DMA t= ransfer attempted=0Aacd0: setting up DMA failed=0Aata1: FAILURE - non align= ed DMA transfer attempted=0Aacd0: setting up DMA failed=0Aacd0: FAILURE - R= EPORT_KEY ILLEGAL REQUEST asc=3D0x6f ascq=3D0x04 =0Aata1: FAILURE - non ali= gned DMA transfer attempted=0Aacd0: setting up DMA failed=0Aata1: FAILURE -= non aligned DMA transfer attempted=0Aacd0: setting up DMA failed=0Aacd0: F= AILURE - REPORT_KEY ILLEGAL REQUEST asc=3D0x6f ascq=3D0x04 =0Aata1: FAILURE= - non aligned DMA transfer attempted=0Aacd0: setting up DMA failed=0Aata1:= FAILURE - non aligned DMA transfer attempted=0Aacd0: setting up DMA failed= =0Aacd0: FAILURE - REPORT_KEY ILLEGAL REQUEST asc=3D0x6f ascq=3D0x04 =0Aata= 1: FAILURE - non aligned DMA transfer attempted=0Aacd0: setting up DMA fail= ed=0Aata1: FAILURE - non aligned DMA transfer attempted=0Aacd0: setting up = DMA failed=0Aacd0: FAILURE - REPORT_KEY ILLEGAL REQUEST asc=3D0x6f ascq=3D0= x04 =0Aata1: FAILURE - non aligned DMA transfer attempted=0Aacd0: setting u= p DMA failed=0Aata1: FAILURE - non aligned DMA transfer attempted=0Aacd0: s= etting up DMA failed=0Aacd0: FAILURE - REPORT_KEY ILLEGAL REQUEST asc=3D0x6= f ascq=3D0x04 =0Aata1: FAILURE - non aligned DMA transfer attempted=0Aacd0:= setting up DMA failed=0Aata1: FAILURE - non aligned DMA transfer attempted= =0Aacd0: setting up DMA failed=0Aacd0: FAILURE - REPORT_KEY ILLEGAL REQUEST= asc=3D0x6f ascq=3D0x04 =0Aata1: FAILURE - non aligned DMA transfer attempt= ed=0Aacd0: setting up DMA failed=0Aata1: FAILURE - non aligned DMA transfer= attempted=0Aacd0: setting up DMA failed=0Aacd0: FAILURE - REPORT_KEY ILLEG= AL REQUEST asc=3D0x6f ascq=3D0x04 =0Aata1: FAILURE - non aligned DMA transf= er attempted=0Aacd0: setting up DMA failed=0Aata1: FAILURE - non aligned DM= A transfer attempted=0Aacd0: setting up DMA failed=0Aacd0: FAILURE - REPORT= _KEY ILLEGAL REQUEST asc=3D0x6f ascq=3D0x04 =0Aata1: FAILURE - non aligned = DMA transfer attempted=0Aacd0: setting up DMA failed=0Aata1: FAILURE - non = aligned DMA transfer attempted=0Aacd0: setting up DMA failed=0Aacd0: FAILUR= E - REPORT_KEY ILLEGAL REQUEST asc=3D0x6f ascq=3D0x04 =0Aata1: FAILURE - no= n aligned DMA transfer attempted=0Aacd0: setting up DMA failed=0Aata1: FAIL= URE - non aligned DMA transfer attempted=0Aacd0: setting up DMA failed=0Aac= d0: FAILURE - REPORT_KEY ILLEGAL REQUEST asc=3D0x6f ascq=3D0x04 =0Aata1: FA= ILURE - non aligned DMA transfer attempted=0Aacd0: setting up DMA failed=0A= ata1: FAILURE - non aligned DMA transfer attempted=0Aacd0: setting up DMA f= ailed =0A=0A=0A=0A=0A=0A=0A __________________________________________= __________________________________________=0AFussy? Opinionated? Impossible= to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://sur= veylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=3D7 =0A From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 22:35:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA4016A417 for ; Tue, 18 Sep 2007 22:35:58 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.de [194.25.134.83]) by mx1.freebsd.org (Postfix) with ESMTP id B29B113C457 for ; Tue, 18 Sep 2007 22:35:58 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from fwd28.aul.t-online.de by mailout07.aul.t-online.de with smtp id 1IXlfh-0001Qd-02; Wed, 19 Sep 2007 00:35:57 +0200 Received: from localhost (bHklAkZXgtv2sGU3yDqz8Pg6e2RkGMNwz09b4heyxYZasKAMUga76-uAkJAw84KTGIllyFwASh@[84.165.71.68]) by fwd28.t-online.de with esmtp id 1IXlfc-1bjnpQ0; Wed, 19 Sep 2007 00:35:52 +0200 Date: Wed, 19 Sep 2007 00:35:51 +0200 From: Oliver Herold To: freebsd-current@freebsd.org Message-ID: <20070918223551.GA85954@olymp.home> Mail-Followup-To: freebsd-current@freebsd.org References: <1190152265.4754.5.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1190152265.4754.5.camel@localhost> User-Agent: Mutt/1.5.16 (2007-06-09) X-ID: bHklAkZXgtv2sGU3yDqz8Pg6e2RkGMNwz09b4heyxYZasKAMUga76-uAkJAw84KTGIllyFwASh X-TOI-MSGID: 09bd0d9d-51dd-4d75-b678-5c19ee23b112 Subject: Re: updated today, now I can't build ports?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 22:35:59 -0000 http://lists.freebsd.org/pipermail/freebsd-current/2007-September/077163.html This is the solution for the problem, you have to update your sources again. Cheers, Oliver On Tue, Sep 18, 2007 at 11:51:05PM +0200, Mathias Picker wrote: > All ports I tried had problems with some patches, e.g. > > ===> Applying FreeBSD patches for abiword-gnome-2.4.6_1 > 3 out of 3 hunks failed--saving rejects to GNUmakefile.in.rej > > (which build fine yesterday) > > is patch broken? I really do not have the time to investigate, will fly > to italy in a few hours (that's why I tried to install koffice right now > && discovered this). > > > Cheers, Mathias > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- The best that we can do is to be kindly and helpful toward our friends and fellow passengers who are clinging to the same speck of dirt while we are drifting side by side to our common doom. -- Clarence Darrow From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 02:06:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1811916A419; Wed, 19 Sep 2007 02:06:24 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 9708C13C48D; Wed, 19 Sep 2007 02:06:19 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.21.134] (helo=devil.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IXox2-000Dk2-DJ; Wed, 19 Sep 2007 11:06:04 +0900 Message-ID: <46F083C1.6000709@micom.mng.net> Date: Wed, 19 Sep 2007 10:04:49 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.4 (X11/20070705) MIME-Version: 1.0 To: Jeff Roberson References: <20070916225019.B921C4500C@ptavv.es.net> <46EDCC48.2090405@FreeBSD.org> <20070916202402.X4507@10.0.0.1> <46EE2C98.90802@micom.mng.net> <20070917141639.Q558@10.0.0.1> In-Reply-To: <20070917141639.Q558@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "David E. Thiel" , freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 02:06:24 -0000 Jeff Roberson wrote: > > On Mon, 17 Sep 2007, Ganbold wrote: > >> Jeff Roberson wrote: >>> On Mon, 17 Sep 2007, Kris Kennaway wrote: >>> >>>> Kevin Oberman wrote: >>>>>> Date: Sun, 16 Sep 2007 14:47:54 -0700 >>>>>> From: "David E. Thiel" >>>>>> Sender: owner-freebsd-current@freebsd.org >>>>>> >>>>>> On Sun, Sep 16, 2007 at 12:58:33AM -0700, vehemens wrote: >>>>>>> On Saturday 15 September 2007 11:19:32 pm Roman Bogorodskiy wrote: >>>>>>>> I'm curious if SCHED_ULE is designed to be used on a desktop >>>>>>>> system. I'm >>>>>>>> running -CURRENT at home and tried to use SCHED_ULE for some >>>>>>>> time. It >>>>>>>> works alright while the load is not very high. But once I start >>>>>>>> compiling something (running 'make buildworld' or 'portupgrade >>>>>>>> -a' for >>>>>>>> example), the machine comes almost unusable - X11's windows >>>>>>>> takes a lot >>>>>>>> of time to redraw, changing virtual desktop in window manager >>>>>>>> may take >>>>>>>> a several seconds. And it's nearly impossible to watch some >>>>>>>> movie with >>>>>>>> mplayer. >>>>>>> I also see something similar running -CURRENT with SCHED_4BSD, >>>>>>> but it shows up with X/gnome. Remote logins are still responsive >>>>>>> and running X/twm works fine. >>>>>> In my experience, both 4BSD and ULE are unresponsive on the desktop >>>>>> in -CURRENT, with ULE being somewhat worse. Compiling an application >>>>>> causes the mouse to be jerky, windows to draw slowly, audio to start >>>>>> skipping, and occasionally the whole desktop freezes for a minute at >>>>>> a time (with ULE only). This is with INVARIANTS and all the >>>>>> debugging >>>>>> kernel options disabled and malloc debugging turned off. I'll >>>>>> give running without PREEMPTION with 4BSD and the ULE patch a shot, >>>>>> but in its stock form, -CURRENT is definitely worse than -STABLE >>>>>> on the >>>>>> desktop for me in a UP configuration. Up till now, I've been working >>>>>> around it manually by juggling with rtprio. >>>>>> >>>>>> If it's of any use, dmesg is at: >>>>>> >>>>>> http://redundancy.redundancy.org/dmesg.txt >>>>> >>>>> I have been seeing this for quite some time and, while the >>>>> scheduler may >>>>> make a bit of difference, I suspect pager issues. As long as I have >>>>> available memory, interactivity is fine. If I run a big build and >>>>> I see >>>>> swap file use, things slow to a crawl. I see very slow re-draws of >>>>> the >>>>> screen and general lack of responsiveness. >>>>> >>>>> I run gkrellm and can tell at a glance when swap usage starts to >>>>> increase. The linkage is clear and not terribly surprising. It may be >>>>> that you need to add a bit more RAM. >>>> >>>> Yes, not surprising in the least. When your system touches swap, >>>> performance will drop to a tiny fraction of its normal performance. >>>> Depending on your disk this could be 1% or lower. Anyone who is >>>> seeing poor interactive performance needs to rule this out as the >>>> cause. >>> >>> Ah, I think I know why people are reporting worse problems with >>> ULE. ULE is not properly accounting swtime so different threads are >>> being chosen for swapout with ULE and 4BSD. My test systems all >>> have more than enough memory to do parallel buildworlds without >>> swapping. This is likely why I haven't run into this. >>> >>> I really need to fix p_swtime with ULE. Could the people reporting >>> bad behavior please verify whether or not you're seeing swapping >>> activity? Even just looking for swap used in top will help me verify >>> that this is the problem. >> >> I explained my problem in >> http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076450.html. >> >> This is a UP system and I have 1GB RAM and top results are shown >> there. > > Ganbold, > > Thank you for your report. I just sent a follow-up mail to current > with a patch that addresses this issue. Can you test and report back? Sorry Jeff, I'm away from office and probably can't test this patch until beginning of October :( But as long as I get a chance I will test it. thanks a lot, Ganbold > > Thanks! > Jeff > >> >> >> Ganbold >> >>> >>> Thanks, >>> Jeff >>> >>> >>>> >>>> Kris >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >>> >>> >>> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > > From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 02:12:10 2007 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A008916A417; Wed, 19 Sep 2007 02:12:10 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 2C94913C46A; Wed, 19 Sep 2007 02:12:10 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id E7C1210749; Wed, 19 Sep 2007 11:12:08 +0900 (JST) Received: from basalt.tackymt.homeip.net ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45232-02; Wed, 19 Sep 2007 11:12:07 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTP; Wed, 19 Sep 2007 11:12:07 +0900 (JST) Date: Wed, 19 Sep 2007 11:12:07 +0900 From: Taku YAMAMOTO To: Andrey Chernov Message-Id: <20070919111207.f37653fc.taku@tackymt.homeip.net> In-Reply-To: <20070917171633.GA31179@nagual.pp.ru> References: <20070916192924.GA12678@nagual.pp.ru> <20070917092130.GA24424@nagual.pp.ru> <20070918020100.d43beb0b.taku@tackymt.homeip.net> <20070917171633.GA31179@nagual.pp.ru> X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at tackymt.homeip.net Cc: i18n@FreeBSD.ORG, Petr Hroudn?? , perky@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 02:12:10 -0000 On Mon, 17 Sep 2007 21:16:33 +0400 Andrey Chernov wrote: > On Tue, Sep 18, 2007 at 02:01:00AM +0900, YAMAMOTO, Taku wrote: > > Checking for __mb_cur_max is not enough for certain locales. > > For example, SJIS has following range for JIS X0201 (a.k.a. HALFWIDTH KANA). > > > > /* > > * JIS X201 > > */ > > PUNCT 0xa1-0xa5 > > SPACE 0xa0 > > BLANK 0xa0 > > SPECIAL 0xa1-0xdf > > PHONOGRAM 0xa6-0xdf > > SWIDTH1 0xa0-0xdf > > I don't understand your remark. MSKanji have __mb_cur_max = 2 and so those > ranges are wchar_t ranges. My patch restrict unsigned char ranges only. These characters ARE single byte. The problem is that a byte >= 0x80 does not always mean it composes a multi-byte character in that locale. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 02:16:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79D9D16A417; Wed, 19 Sep 2007 02:16:45 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.c0mplx.org (home.c0mplx.org [IPv6:2001:14b0:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0FBC813C46E; Wed, 19 Sep 2007 02:16:45 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from pi by home.c0mplx.org with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1IXp7M-000CSZ-IX; Wed, 19 Sep 2007 04:16:44 +0200 Date: Wed, 19 Sep 2007 04:16:44 +0200 From: Kurt Jaeger To: Daichi GOTO Message-ID: <20070919021644.GG2061@home.c0mplx.org> References: <200709141103.18612.h.schmalzbauer@omnisec.de> <20070914110024.G14481@fledge.watson.org> <46EBEA18.3080800@ongs.co.jp> <20070915170104.GF2061@home.c0mplx.org> <46EF6386.9050700@ongs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46EF6386.9050700@ongs.co.jp> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Unionfs patchset p19 commit? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 02:16:45 -0000 Hi! > >>I have a big hope to get merged into FreeBSD until > >>7-RELEASE. Progress is step by step slowly, but going > >>forward absolutely. If you have interest in unionfs > >>improvements, push your passion to re@ and fs@ committers ;-) > > > >Did you have a chance to look into this ? > > > >http://lists.freebsd.org/pipermail/freebsd-stable/2007-June/035798.html > Already we have fixed above issue. [...] I'm compiling this patch on my test system right now. Another issue is userland support for unionfs, e.g. in fstat, as described on this page: http://c0mplx.org/src/fstat-unionfs-patch/ Do you plan to analyse/investigate this topic ? There's another topic if one uses unionfs in jail() setups: How to backup the files, and only those files that a different from the base ? If I traverse a mounted unionfs, how do I know where data is coming from, the lower mount or the higher mount ? If I can't tell the difference, I'll backup quite a lot of stuff multiple times. I've experimented a little and found no easy way to tell lower from upper unless I open the file (which sounds expensive). Have a look at http://c0mplx.org/src/isunionfs.c -- does this sound like a way to go ? -- pi@c0mplx.org +49 171 3101372 13 years to go ! From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 02:25:59 2007 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44D6D16A420; Wed, 19 Sep 2007 02:25:59 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 97AD113C465; Wed, 19 Sep 2007 02:25:58 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l8J2PuUf070749; Wed, 19 Sep 2007 06:25:56 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1190168757; bh=CgRSFAzMqKFQSJ78EIaFmOIkHIshvpmLzgqxhjX z5qk=; l=514; h=Date:From:To:Cc:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: Content-Transfer-Encoding:In-Reply-To:User-Agent; b=EomaGUh2DjV2yK RHickf//1nPnjQAfXqcx6gapz0voCQGMirs8OmBVXnX9/qQHe1rHsk4pA7NiXy+LmJ9 uCkZgKfyZdssSbM445Wl6QvQ+Vy77J/eAMFtlnjLS1ZDFfcVv22FiIA2/y0wzdOS8yu ywjt+bLNnucG/Se7HUoI74E= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l8J2PuTd070748; Wed, 19 Sep 2007 06:25:56 +0400 (MSD) (envelope-from ache) Date: Wed, 19 Sep 2007 06:25:55 +0400 From: Andrey Chernov To: Taku YAMAMOTO Message-ID: <20070919022555.GA70617@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Taku YAMAMOTO , Petr Hroudn?? , current@FreeBSD.ORG, perky@FreeBSD.ORG, i18n@FreeBSD.ORG References: <20070916192924.GA12678@nagual.pp.ru> <20070917092130.GA24424@nagual.pp.ru> <20070918020100.d43beb0b.taku@tackymt.homeip.net> <20070917171633.GA31179@nagual.pp.ru> <20070919111207.f37653fc.taku@tackymt.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20070919111207.f37653fc.taku@tackymt.homeip.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: i18n@FreeBSD.ORG, Petr Hroudn?? , perky@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 02:25:59 -0000 On Wed, Sep 19, 2007 at 11:12:07AM +0900, Taku YAMAMOTO wrote: > These characters ARE single byte. > The problem is that a byte >=3D 0x80 does not always mean it composes a > multi-byte character in that locale. Ah, I understand. =46rom mskanji(5): "Characters from the ASCII/JIS-Roman character set are encoded as single bytes between 0x00 and 0x7F (ASCII) or 0xA1 and 0xDF (Half-width katakana)." It means that test needs to be more comprehensive :( I'll think about... --=20 http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 02:36:28 2007 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76B5716A417; Wed, 19 Sep 2007 02:36:28 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id C83E413C459; Wed, 19 Sep 2007 02:36:27 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l8J2aQ0n070960; Wed, 19 Sep 2007 06:36:26 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1190169386; bh=Q+x0Gg5zbeDMCpXEXHDZRtuHkT1j+aApFOMtwYT bkNo=; l=357; h=Date:From:To:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent; b=ESYVl3keunDBINry99dX3jGBCA596h0XdiZHjDK7 TJ47ENrTb+831nuqmbvMMHV9vehxWpTMjX7yBGKHuJAe0+4to2AlK7iCbEgb/HqarK0 WuO7cNitp+vBD4azmTn0VoWDIIVCArcrZyL5+OKfihjCsgu1Esk3BK01JmHo2cFw= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l8J2aQaQ070959; Wed, 19 Sep 2007 06:36:26 +0400 (MSD) (envelope-from ache) Date: Wed, 19 Sep 2007 06:36:25 +0400 From: Andrey Chernov To: Taku YAMAMOTO , Petr Hroudn?? , current@FreeBSD.ORG, perky@FreeBSD.ORG, i18n@FreeBSD.ORG Message-ID: <20070919023625.GA70891@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Taku YAMAMOTO , Petr Hroudn?? , current@FreeBSD.ORG, perky@FreeBSD.ORG, i18n@FreeBSD.ORG References: <20070916192924.GA12678@nagual.pp.ru> <20070917092130.GA24424@nagual.pp.ru> <20070918020100.d43beb0b.taku@tackymt.homeip.net> <20070917171633.GA31179@nagual.pp.ru> <20070919111207.f37653fc.taku@tackymt.homeip.net> <20070919022555.GA70617@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070919022555.GA70617@nagual.pp.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 02:36:28 -0000 On Wed, Sep 19, 2007 at 06:25:55AM +0400, Andrey Chernov wrote: > I'll think about... It seems my first attempt was right, i.e. we need real UTF-8.src instead of UCS-4 mimic of it. All other locales keep their true wchar_t encodings, only UTF-8.src not following the rules. I'll send regenerated UTF-8.src a bit later. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 05:13:44 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EC6F16A41B for ; Wed, 19 Sep 2007 05:13:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id A567E13C48E for ; Wed, 19 Sep 2007 05:13:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 28062 invoked by uid 399); 19 Sep 2007 05:13:42 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 19 Sep 2007 05:13:42 -0000 X-Originating-IP: 127.0.0.1 Date: Tue, 18 Sep 2007 22:13:40 -0700 (PDT) From: Doug Barton To: "Constantine A. Murenin" In-Reply-To: <46E9FC0C.70607@FreeBSD.org> Message-ID: References: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> <46E9FC0C.70607@FreeBSD.org> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Leidinger , Shteryana Shopova , freebsd-current@FreeBSD.org Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 05:13:44 -0000 On Thu, 13 Sep 2007, Constantine A. Murenin wrote: > Dear freebsd-{arch,current,hackers}@, > > On this 256th day of 2007, it is my great pleasure to announce the completion > of my GSoC2007 project on porting the sysctl hardware sensors framework from > OpenBSD to FreeBSD. This works great on my C2D: hw.sensors.cpu0.temp0: 79.00 degC hw.sensors.cpu1.temp0: 82.00 degC Sensor Value Status Description cpu0.temp0 82.00 degC cpu1.temp0 84.00 degC (the temp went up because I was compiling something). Two small comments about the rc.d stuff. First, the empty _flags variable in defaults/rc.conf should be commented out. Second, the rc.d script needs the shutdown KEYWORD. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 05:18:34 2007 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F16E16A418; Wed, 19 Sep 2007 05:18:34 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 338CB13C457; Wed, 19 Sep 2007 05:18:32 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l8J5IV9Y072461; Wed, 19 Sep 2007 09:18:31 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1190179111; bh=853GFX1UkJzny0J3otxOiD/18/OckDGE67M6Gw1 rcWQ=; l=15943; h=Date:From:To:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent; b=nkgRAbDHMGAkdlAHTDwCV9s91WRLDRSNuR/8GB32 JJo4Chd0Qutr8p6gHukSISc1M4YJ9QOU0ypRIUOPrtpBWIpGrsM+0tILkkFfCctBJcZ fU/gvM9nqVq8bTfmRNIdoDOaxc2ZMFHQLk9kT6y185yPhf2YOe1a+GJ0Zsggp8KI= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l8J5IUXe072460; Wed, 19 Sep 2007 09:18:30 +0400 (MSD) (envelope-from ache) Date: Wed, 19 Sep 2007 09:18:30 +0400 From: Andrey Chernov To: Taku YAMAMOTO , Petr Hroudn?? , current@FreeBSD.ORG, perky@FreeBSD.ORG, i18n@FreeBSD.ORG Message-ID: <20070919051830.GA72429@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Taku YAMAMOTO , Petr Hroudn?? , current@FreeBSD.ORG, perky@FreeBSD.ORG, i18n@FreeBSD.ORG References: <20070916192924.GA12678@nagual.pp.ru> <20070917092130.GA24424@nagual.pp.ru> <20070918020100.d43beb0b.taku@tackymt.homeip.net> <20070917171633.GA31179@nagual.pp.ru> <20070919111207.f37653fc.taku@tackymt.homeip.net> <20070919022555.GA70617@nagual.pp.ru> <20070919023625.GA70891@nagual.pp.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20070919023625.GA70891@nagual.pp.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 05:18:34 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Sep 19, 2007 at 06:36:25AM +0400, Andrey Chernov wrote: > only UTF-8.src not following the rules. I'll send regenerated UTF-8.src > a bit later. I change my mind again, now I use new __mb_bit8_override flag specific to UTF-8 encoding (other bit8 overriding encodings could use it too). New patch attached. -- http://ache.pp.ru/ --OgqxwSJOaUobr8KG Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ctype.patch" --- _ctype.h.old 2007-09-16 21:13:59.000000000 +0400 +++ _ctype.h 2007-09-19 08:46:35.000000000 +0400 @@ -63,6 +63,7 @@ #define _CTYPE_I 0x00080000L /* Ideogram */ #define _CTYPE_T 0x00100000L /* Special */ #define _CTYPE_Q 0x00200000L /* Phonogram */ +#define _CTYPE_WID 0x10000000L /* wide character function */ #define _CTYPE_SW0 0x20000000L /* 0 width character */ #define _CTYPE_SW1 0x40000000L /* 1 width character */ #define _CTYPE_SW2 0x80000000L /* 2 width character */ @@ -87,6 +88,8 @@ #define __inline #endif +extern int __mb_bit8_override; + /* * Use inline functions if we are allowed to and the compiler supports them. */ @@ -98,8 +101,11 @@ static __inline int __maskrune(__ct_rune_t _c, unsigned long _f) { - return ((_c < 0 || _c >= _CACHED_RUNES) ? ___runetype(_c) : + return __mb_bit8_override && !(_f & _CTYPE_WID) && (_c >= 0x80) ? 0 : + ((_c < 0 || _c >= _CACHED_RUNES) ? ___runetype(_c) : _CurrentRuneLocale->__runetype[_c]) & _f; + /* We never set _CTYPE_WID in the locale data, */ + /* so can skip ... & (_f & ~_CTYPE_WID). */ } static __inline int @@ -111,8 +117,11 @@ static __inline int __isctype(__ct_rune_t _c, unsigned long _f) { - return (_c < 0 || _c >= _CACHED_RUNES) ? 0 : + return __mb_bit8_override && !(_f & _CTYPE_WID) && (_c >= 0x80) ? 0 : + (_c < 0 || _c >= _CACHED_RUNES) ? 0 : !!(_DefaultRuneLocale.__runetype[_c] & _f); + /* We never set _CTYPE_WID in the locale data, */ + /* so can skip ... & (_f & ~_CTYPE_WID). */ } static __inline __ct_rune_t @@ -129,6 +138,22 @@ _CurrentRuneLocale->__maplower[_c]; } +static __inline __ct_rune_t +__tosupper(__ct_rune_t _c) +{ + return __mb_bit8_override && (_c >= 0x80) ? _c : + (_c < 0 || _c >= _CACHED_RUNES) ? ___toupper(_c) : + _CurrentRuneLocale->__mapupper[_c]; +} + +static __inline __ct_rune_t +__toslower(__ct_rune_t _c) +{ + return __mb_bit8_override && (_c >= 0x80) ? _c : + (_c < 0 || _c >= _CACHED_RUNES) ? ___tolower(_c) : + _CurrentRuneLocale->__maplower[_c]; +} + static __inline int __wcwidth(__ct_rune_t _c) { @@ -150,6 +175,8 @@ int __isctype(__ct_rune_t, unsigned long); __ct_rune_t __toupper(__ct_rune_t); __ct_rune_t __tolower(__ct_rune_t); +__ct_rune_t __tosupper(__ct_rune_t); +__ct_rune_t __toslower(__ct_rune_t); int __wcwidth(__ct_rune_t); __END_DECLS #endif /* using inlines */ --- big5.c.old 2007-09-19 08:48:55.000000000 +0400 +++ big5.c 2007-09-19 08:56:12.000000000 +0400 @@ -49,6 +49,8 @@ #include #include "mblocal.h" +extern int __mb_bit8_override; + static size_t _BIG5_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _BIG5_mbsinit(const mbstate_t *); @@ -68,6 +70,7 @@ __mbsinit = _BIG5_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_bit8_override = 0; return (0); } --- ctype.h.old 2007-09-16 22:03:55.000000000 +0400 +++ ctype.h 2007-09-16 22:56:10.000000000 +0400 @@ -97,8 +97,8 @@ #define isspace(c) __istype((c), _CTYPE_S) #define isupper(c) __istype((c), _CTYPE_U) #define isxdigit(c) __isctype((c), _CTYPE_X) /* ANSI -- locale independent */ -#define tolower(c) __tolower(c) -#define toupper(c) __toupper(c) +#define tolower(c) __toslower(c) +#define toupper(c) __tosupper(c) #if __XSI_VISIBLE /* @@ -112,8 +112,8 @@ * * XXX isascii() and toascii() should similarly be undocumented. */ -#define _tolower(c) __tolower(c) -#define _toupper(c) __toupper(c) +#define _tolower(c) __toslower(c) +#define _toupper(c) __tosupper(c) #define isascii(c) (((c) & ~0x7F) == 0) #define toascii(c) ((c) & 0x7F) #endif @@ -128,7 +128,7 @@ #define isideogram(c) __istype((c), _CTYPE_I) #define isnumber(c) __istype((c), _CTYPE_D) #define isphonogram(c) __istype((c), _CTYPE_Q) -#define isrune(c) __istype((c), 0xFFFFFF00L) +#define isrune(c) __istype((c), 0xFFFFFF00L & ~_CTYPE_WID) #define isspecial(c) __istype((c), _CTYPE_T) #endif --- euc.c.old 2007-09-19 08:50:57.000000000 +0400 +++ euc.c 2007-09-19 08:56:12.000000000 +0400 @@ -49,6 +49,8 @@ #include #include "mblocal.h" +extern int __mb_bit8_override; + static size_t _EUC_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _EUC_mbsinit(const mbstate_t *); @@ -116,6 +118,7 @@ __mbrtowc = _EUC_mbrtowc; __wcrtomb = _EUC_wcrtomb; __mbsinit = _EUC_mbsinit; + __mb_bit8_override = 0; return (0); } --- gb18030.c.old 2007-09-19 08:59:01.000000000 +0400 +++ gb18030.c 2007-09-19 09:00:10.000000000 +0400 @@ -39,6 +39,8 @@ #include #include "mblocal.h" +extern int __mb_bit8_override; + static size_t _GB18030_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GB18030_mbsinit(const mbstate_t *); @@ -59,6 +61,7 @@ __mbsinit = _GB18030_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 4; + __mb_bit8_override = 0; return (0); } --- gb2312.c.old 2007-09-19 09:00:35.000000000 +0400 +++ gb2312.c 2007-09-19 09:01:05.000000000 +0400 @@ -35,6 +35,8 @@ #include #include "mblocal.h" +extern int __mb_bit8_override; + static size_t _GB2312_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GB2312_mbsinit(const mbstate_t *); @@ -55,6 +57,7 @@ __wcrtomb = _GB2312_wcrtomb; __mbsinit = _GB2312_mbsinit; __mb_cur_max = 2; + __mb_bit8_override = 0; return (0); } --- gbk.c.old 2007-09-19 09:01:33.000000000 +0400 +++ gbk.c 2007-09-19 09:02:03.000000000 +0400 @@ -42,6 +42,8 @@ #include #include "mblocal.h" +extern int __mb_bit8_override; + static size_t _GBK_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GBK_mbsinit(const mbstate_t *); @@ -61,6 +63,7 @@ __mbsinit = _GBK_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_bit8_override = 0; return (0); } --- isctype.c.old 2007-09-16 22:31:26.000000000 +0400 +++ isctype.c 2007-09-16 22:37:54.000000000 +0400 @@ -168,7 +168,7 @@ isrune(c) int c; { - return (__istype(c, 0xFFFFFF00L)); + return (__istype(c, 0xFFFFFF00L & ~_CTYPE_WID)); } #undef isspace @@ -216,7 +216,7 @@ tolower(c) int c; { - return (__tolower(c)); + return (__toslower(c)); } #undef toupper @@ -224,6 +224,6 @@ toupper(c) int c; { - return (__toupper(c)); + return (__tosupper(c)); } --- iswctype.c.old 2007-09-16 22:31:30.000000000 +0400 +++ iswctype.c 2007-09-16 22:41:39.000000000 +0400 @@ -45,7 +45,7 @@ iswalnum(wc) wint_t wc; { - return (__istype(wc, _CTYPE_A|_CTYPE_D)); + return (__istype(wc, _CTYPE_A|_CTYPE_D|_CTYPE_WID)); } #undef iswalpha @@ -53,7 +53,7 @@ iswalpha(wc) wint_t wc; { - return (__istype(wc, _CTYPE_A)); + return (__istype(wc, _CTYPE_A|_CTYPE_WID))); } #undef iswascii @@ -61,7 +61,7 @@ iswascii(wc) wint_t wc; { - return ((wc & ~0x7F) == 0); + return (wc < 0x80); } #undef iswblank @@ -69,7 +69,7 @@ iswblank(wc) wint_t wc; { - return (__istype(wc, _CTYPE_B)); + return (__istype(wc, _CTYPE_B|_CTYPE_WID))); } #undef iswcntrl @@ -77,7 +77,7 @@ iswcntrl(wc) wint_t wc; { - return (__istype(wc, _CTYPE_C)); + return (__istype(wc, _CTYPE_C|_CTYPE_WID))); } #undef iswdigit @@ -85,7 +85,7 @@ iswdigit(wc) wint_t wc; { - return (__isctype(wc, _CTYPE_D)); + return (__isctype(wc, _CTYPE_D|_CTYPE_WID))); } #undef iswgraph @@ -93,7 +93,7 @@ iswgraph(wc) wint_t wc; { - return (__istype(wc, _CTYPE_G)); + return (__istype(wc, _CTYPE_G|_CTYPE_WID))); } #undef iswhexnumber @@ -101,7 +101,7 @@ iswhexnumber(wc) wint_t wc; { - return (__istype(wc, _CTYPE_X)); + return (__istype(wc, _CTYPE_X|_CTYPE_WID))); } #undef iswideogram @@ -109,7 +109,7 @@ iswideogram(wc) wint_t wc; { - return (__istype(wc, _CTYPE_I)); + return (__istype(wc, _CTYPE_I|_CTYPE_WID))); } #undef iswlower @@ -117,7 +117,7 @@ iswlower(wc) wint_t wc; { - return (__istype(wc, _CTYPE_L)); + return (__istype(wc, _CTYPE_L|_CTYPE_WID))); } #undef iswnumber @@ -125,7 +125,7 @@ iswnumber(wc) wint_t wc; { - return (__istype(wc, _CTYPE_D)); + return (__istype(wc, _CTYPE_D|_CTYPE_WID))); } #undef iswphonogram @@ -133,7 +133,7 @@ iswphonogram(wc) wint_t wc; { - return (__istype(wc, _CTYPE_Q)); + return (__istype(wc, _CTYPE_Q|_CTYPE_WID))); } #undef iswprint @@ -141,7 +141,7 @@ iswprint(wc) wint_t wc; { - return (__istype(wc, _CTYPE_R)); + return (__istype(wc, _CTYPE_R|_CTYPE_WID))); } #undef iswpunct @@ -149,7 +149,7 @@ iswpunct(wc) wint_t wc; { - return (__istype(wc, _CTYPE_P)); + return (__istype(wc, _CTYPE_P|_CTYPE_WID))); } #undef iswrune @@ -157,7 +157,7 @@ iswrune(wc) wint_t wc; { - return (__istype(wc, 0xFFFFFF00L)); + return (__istype(wc, 0xFFFFFF00L)); /* already have _CTYPE_WID */ } #undef iswspace @@ -165,7 +165,7 @@ iswspace(wc) wint_t wc; { - return (__istype(wc, _CTYPE_S)); + return (__istype(wc, _CTYPE_S|_CTYPE_WID))); } #undef iswspecial @@ -173,7 +173,7 @@ iswspecial(wc) wint_t wc; { - return (__istype(wc, _CTYPE_T)); + return (__istype(wc, _CTYPE_T|_CTYPE_WID))); } #undef iswupper @@ -181,7 +181,7 @@ iswupper(wc) wint_t wc; { - return (__istype(wc, _CTYPE_U)); + return (__istype(wc, _CTYPE_U|_CTYPE_WID))); } #undef iswxdigit @@ -189,7 +189,7 @@ iswxdigit(wc) wint_t wc; { - return (__isctype(wc, _CTYPE_X)); + return (__isctype(wc, _CTYPE_X|_CTYPE_WID))); } #undef towlower --- mskanji.c.old 2007-09-19 09:02:56.000000000 +0400 +++ mskanji.c 2007-09-19 09:03:26.000000000 +0400 @@ -47,6 +47,8 @@ #include #include "mblocal.h" +extern int __mb_bit8_override; + static size_t _MSKanji_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _MSKanji_mbsinit(const mbstate_t *); @@ -66,6 +68,7 @@ __mbsinit = _MSKanji_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_bit8_override = 0; return (0); } --- none.c.old 2007-09-19 08:56:40.000000000 +0400 +++ none.c 2007-09-19 08:58:23.000000000 +0400 @@ -69,6 +69,7 @@ __wcsnrtombs = _none_wcsnrtombs; _CurrentRuneLocale = rl; __mb_cur_max = 1; + __mb_bit8_override = 0; return(0); } @@ -177,6 +178,7 @@ /* setup defaults */ int __mb_cur_max = 1; +int __mb_bit8_override = 0; size_t (*__mbrtowc)(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict) = _none_mbrtowc; int (*__mbsinit)(const mbstate_t *) = _none_mbsinit; --- setrunelocale.c.old 2007-09-19 09:03:59.000000000 +0400 +++ setrunelocale.c 2007-09-19 09:06:45.000000000 +0400 @@ -45,6 +45,8 @@ #include "mblocal.h" #include "setlocale.h" +extern int __mb_bit8_override; + extern _RuneLocale *_Read_RuneMagi(FILE *); static int __setrunelocale(const char *); @@ -59,6 +61,7 @@ static char ctype_encoding[ENCODING_LEN + 1]; static _RuneLocale *CachedRuneLocale; static int Cached__mb_cur_max; + static int Cached__mb_bit8_override; static size_t (*Cached__mbrtowc)(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static size_t (*Cached__wcrtomb)(char * __restrict, wchar_t, @@ -85,6 +88,7 @@ strcmp(encoding, ctype_encoding) == 0) { _CurrentRuneLocale = CachedRuneLocale; __mb_cur_max = Cached__mb_cur_max; + __mb_bit8_override = Cached__mb_bit8_override; __mbrtowc = Cached__mbrtowc; __mbsinit = Cached__mbsinit; __mbsnrtowcs = Cached__mbsnrtowcs; @@ -147,6 +151,7 @@ } CachedRuneLocale = _CurrentRuneLocale; Cached__mb_cur_max = __mb_cur_max; + Cached__mb_bit8_override = __mb_bit8_override; Cached__mbrtowc = __mbrtowc; Cached__mbsinit = __mbsinit; Cached__mbsnrtowcs = __mbsnrtowcs; --- utf8.c.old 2007-09-19 08:18:40.000000000 +0400 +++ utf8.c 2007-09-19 08:56:12.000000000 +0400 @@ -35,6 +35,8 @@ #include #include "mblocal.h" +extern int __mb_bit8_override; + static size_t _UTF8_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _UTF8_mbsinit(const mbstate_t *); @@ -63,6 +65,7 @@ __wcsnrtombs = _UTF8_wcsnrtombs; _CurrentRuneLocale = rl; __mb_cur_max = 6; + __mb_bit8_override = 1; return (0); } --- wctype.h.old 2007-09-16 21:59:37.000000000 +0400 +++ wctype.h 2007-09-16 22:56:44.000000000 +0400 @@ -89,30 +89,30 @@ #endif __END_DECLS -#define iswalnum(wc) __istype((wc), _CTYPE_A|_CTYPE_D) -#define iswalpha(wc) __istype((wc), _CTYPE_A) -#define iswblank(wc) __istype((wc), _CTYPE_B) -#define iswcntrl(wc) __istype((wc), _CTYPE_C) -#define iswctype(wc, charclass) __istype((wc), (charclass)) -#define iswdigit(wc) __isctype((wc), _CTYPE_D) -#define iswgraph(wc) __istype((wc), _CTYPE_G) -#define iswlower(wc) __istype((wc), _CTYPE_L) -#define iswprint(wc) __istype((wc), _CTYPE_R) -#define iswpunct(wc) __istype((wc), _CTYPE_P) -#define iswspace(wc) __istype((wc), _CTYPE_S) -#define iswupper(wc) __istype((wc), _CTYPE_U) -#define iswxdigit(wc) __isctype((wc), _CTYPE_X) +#define iswalnum(wc) __istype((wc), _CTYPE_A|_CTYPE_D|_CTYPE_WID) +#define iswalpha(wc) __istype((wc), _CTYPE_A|_CTYPE_WID) +#define iswblank(wc) __istype((wc), _CTYPE_B|_CTYPE_WID) +#define iswcntrl(wc) __istype((wc), _CTYPE_C|_CTYPE_WID) +#define iswctype(wc, charclass) __istype((wc), (charclass)|_CTYPE_WID) +#define iswdigit(wc) __isctype((wc), _CTYPE_D|_CTYPE_WID) +#define iswgraph(wc) __istype((wc), _CTYPE_G|_CTYPE_WID) +#define iswlower(wc) __istype((wc), _CTYPE_L|_CTYPE_WID) +#define iswprint(wc) __istype((wc), _CTYPE_R|_CTYPE_WID) +#define iswpunct(wc) __istype((wc), _CTYPE_P|_CTYPE_WID) +#define iswspace(wc) __istype((wc), _CTYPE_S|_CTYPE_WID) +#define iswupper(wc) __istype((wc), _CTYPE_U|_CTYPE_WID) +#define iswxdigit(wc) __isctype((wc), _CTYPE_X|_CTYPE_WID) #define towlower(wc) __tolower(wc) #define towupper(wc) __toupper(wc) #if __BSD_VISIBLE -#define iswascii(wc) (((wc) & ~0x7F) == 0) -#define iswhexnumber(wc) __istype((wc), _CTYPE_X) -#define iswideogram(wc) __istype((wc), _CTYPE_I) -#define iswnumber(wc) __istype((wc), _CTYPE_D) -#define iswphonogram(wc) __istype((wc), _CTYPE_Q) -#define iswrune(wc) __istype((wc), 0xFFFFFF00L) -#define iswspecial(wc) __istype((wc), _CTYPE_T) +#define iswascii(wc) ((wc) < 0x80) +#define iswhexnumber(wc) __istype((wc), _CTYPE_X|_CTYPE_WID) +#define iswideogram(wc) __istype((wc), _CTYPE_I|_CTYPE_WID) +#define iswnumber(wc) __istype((wc), _CTYPE_D|_CTYPE_WID) +#define iswphonogram(wc) __istype((wc), _CTYPE_Q|_CTYPE_WID) +#define iswrune(wc) __istype((wc), 0xFFFFFF00L) /* already have _CTYPE_WID */ +#define iswspecial(wc) __istype((wc), _CTYPE_T|_CTYPE_WID) #endif #endif /* _WCTYPE_H_ */ --OgqxwSJOaUobr8KG-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 07:22:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7075A16A418 for ; Wed, 19 Sep 2007 07:22:22 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4FF13C468 for ; Wed, 19 Sep 2007 07:22:21 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by rv-out-0910.google.com with SMTP id l15so96750rvb for ; Wed, 19 Sep 2007 00:22:21 -0700 (PDT) Received: by 10.115.77.1 with SMTP id e1mr181365wal.1190186541069; Wed, 19 Sep 2007 00:22:21 -0700 (PDT) Received: by 10.115.33.7 with HTTP; Wed, 19 Sep 2007 00:22:21 -0700 (PDT) Message-ID: Date: Wed, 19 Sep 2007 09:22:21 +0200 From: "TooMany Secrets" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Subject: Encoding in 7-CURRENT (next 7.0). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 07:22:22 -0000 SGkhCgpJIHdvdWxkIGxpa2UgdG8ga25vdyBpZiB0aGUgbmV4dCByZWxlYXNlICg3LVJFTEVORyks IHdpbGwgY29tZSB3aXRoCnRoZSBzeXN0ZW0gaW50byB1dGYtOCBlbmNvZGluZy4KSSBrbm93IHRo YXQgSSBjYW4gcHV0IG15IGhvbWUsIGFwcHMsIGV0YywgaW50byBVVEYtOCB3aXRob3V0IHByb2Js ZW1zLApidXQgaWYgSSB0cnkgdGhpcyB3aXRoIHRoZSBzeXN0ZW0sIGl0IGNvdWxkIGJlIG1vcmUg ImRhbmdlcm91cyIuCgpFeGN1c2UgbWUgbXkgYmFkIGVuZ2xpc2ggYW5kLCBhbHNvLCBpZiBJJ20g c2F5aW5nIHNvbWV0aGluZyAiZnVubnkiIG9yCndpdGhvdXQgYW55IHNlbnNlLgoKLS0gCkhhdmUg YSBuaWNlIGRheSAgOy0pClRvb01hbnlTZWNyZXRzCgo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09CkRpam8gQ29uZnVjaW86CiJFeMOtZ2V0ZSBtdWNobyBhIHRpIG1pc21vIHkgZXNwZXJhIHBv Y28gZGUgbG9zIGRlbcOhcy4gQXPDrSB0ZSBhaG9ycmFyw6FzCmRpc2d1c3Rvcy4iCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT0K From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 07:36:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA2EC16A419 for ; Wed, 19 Sep 2007 07:36:24 +0000 (UTC) (envelope-from freebsd-current@adam.gs) Received: from mail.adam.gs (mail.adam.gs [76.9.2.116]) by mx1.freebsd.org (Postfix) with ESMTP id 68D5D13C46A for ; Wed, 19 Sep 2007 07:36:24 +0000 (UTC) (envelope-from freebsd-current@adam.gs) Received: from [127.0.0.1] (localhost.adam.gs [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id 8C62CF353A6 for ; Wed, 19 Sep 2007 03:24:27 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mail; d=adam.gs; b=MqGB7+8yjZzCDYmneauRV+sAly/ywko2UX3/bSPpwx2x0Q+4bqQXyVqhl1n3WLXBp1NIfuI8Ty7oLEHr8TUYDOwcQfyAOuBR5bhDMqb0CRF9u5M9iy3kqiVQi5mDhfRiCUXiJOBHqWTVQnxCs5HcLDt3+nCSncXUg50488d8EZg=; Received: from [10.0.1.125] (unknown [64.111.192.110]) (Authenticated sender: adam@adam.gs) by mail.adam.gs (Postfix) with ESMTP id 229A6F34D64; Wed, 19 Sep 2007 03:24:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org From: Adam Jacob Muller Date: Wed, 19 Sep 2007 03:24:25 -0400 X-Mailer: Apple Mail (2.752.3) Cc: Subject: ZFS pool not working on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 07:36:24 -0000 Hello, I have a server with two ZFS pools, one is an internal raid0 using 2 drives connected via ahc. The other is an external storage array with 11 drives also using ahc, using raidz. (This is a dell 1650 and pv220s). On reboot, the pools do not come online on their own. Both pools consistently show as failed. the exact symptoms vary, however I have seen that many drives are marked as variously "corrupt" or "unavailable" most zpool operations fail with "pool is unavailable" errors. Here is the interesting part. Consistently, 100% of the time, a zpool export followed by a zpool import restores the arrays to an ONLINE status. Once the array is online, it's quite stable (I'm loving ZFS btw, thank you to everyone for the hard work on this, ZFS is fantastic) and works great. Anyone have any ideas why this might occur and what/if the solution is? Any additional information can be provided on-request, I am running current from approximately 1 week ago. -Adam From owner-freebsd-current@FreeBSD.ORG Tue Sep 18 22:29:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A35A716A41A for ; Tue, 18 Sep 2007 22:29:38 +0000 (UTC) (envelope-from phil@ultimate.com) Received: from mail.ultimate.com (mail.ultimate.com [199.201.145.150]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3B413C467 for ; Tue, 18 Sep 2007 22:29:38 +0000 (UTC) (envelope-from phil@ultimate.com) Received: from ultimate.com (localhost [127.0.0.1]) by mail.ultimate.com (8.14.1/8.14.1) with ESMTP id l8IMEsXh004876; Tue, 18 Sep 2007 18:14:54 -0400 (EDT) (envelope-from phil@ultimate.com) Received: (from phil@localhost) by ultimate.com (8.14.1/8.14.1/Submit) id l8IMEsTW004875; Tue, 18 Sep 2007 18:14:54 -0400 (EDT) (envelope-from phil) Date: Tue, 18 Sep 2007 18:14:54 -0400 (EDT) From: Phil Budne Message-Id: <200709182214.l8IMEsTW004875@ultimate.com> To: freebsd-current@freebsd.org X-Mailman-Approved-At: Wed, 19 Sep 2007 07:46:13 +0000 Cc: phil@ultimate.com Subject: X11 distribution sets for 7.0-CURRENT (i386)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 22:29:38 -0000 Is some place I can get a binary distribution of X11 for 7.0-current (i386)? That is an FTP server with "distribution sets" to point sysinstall at, or files for pkg_add? I just want basic clients, libraries and includes to build a few more clients, and virtual X11 server accessible via VNC, and don't want to have to build it all from scratch. Thanks in advance, Phil Budne From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 08:02:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 694DD16A41A for ; Wed, 19 Sep 2007 08:02:09 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: from web36612.mail.mud.yahoo.com (web36612.mail.mud.yahoo.com [209.191.85.29]) by mx1.freebsd.org (Postfix) with SMTP id F21E513C47E for ; Wed, 19 Sep 2007 08:02:08 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: (qmail 61634 invoked by uid 60001); 19 Sep 2007 08:02:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=5q2elfxmO7jjJ9N9XXLULDuim/fPu2xsnG7seBZsecCAi0j/eqwP15wczvjjtFL8YOfBnDk8yAUnAcQ4dz2llwoMW2FkYdzne7VFsXIJ8qYR2n1UDZXL22uEBZEe1+3aUfDgq/ScCSZ24pmajRFSSuyBGWtcNc4R2+MAvrA+CRg=; X-YMail-OSG: xr6DWI0VM1nXoFUre0EYpqyeirN1zkG3greioK5mw92a5LDCkSp4.3AEWjwnDVb1V8G9UJQrSnFb97enfPj7y9hu1aWjhk7oSQY9jQ3YvRKkanD0jQ09T2DkDmRtZw-- Received: from [213.147.110.159] by web36612.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2007 01:02:07 PDT Date: Wed, 19 Sep 2007 01:02:07 -0700 (PDT) From: Simun Mikecin To: Phil Budne MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <110518.61469.qm@web36612.mail.mud.yahoo.com> X-Mailman-Approved-At: Wed, 19 Sep 2007 08:24:29 +0000 Cc: freebsd-current@freebsd.org Subject: Re: X11 distribution sets for 7.0-CURRENT (i386)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 08:02:09 -0000 >Is some place I can get a binary distribution of X11 for 7.0-current >(i386)? That is an FTP server with "distribution sets" to point >sysinstall at, or files for pkg_add? 'pkg_add -rv' is your friend. But I'm not sure that you will get XOrg 7.3 instead of Xorg 7.2 (until someone builts required packages). ____________________________________________________________________________________ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 08:25:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1C2F16A417 for ; Wed, 19 Sep 2007 08:25:59 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE8D13C4D9 for ; Wed, 19 Sep 2007 08:25:58 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l8J8ES3N017361; Wed, 19 Sep 2007 17:44:28 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 19 Sep 2007 17:55:52 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 17:55:51 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l8J8PpGR056743; Wed, 19 Sep 2007 16:25:51 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l8J8Ppkr056742; Wed, 19 Sep 2007 16:25:51 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 19 Sep 2007 16:25:51 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20070919082551.GS55051@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 19 Sep 2007 08:25:51.0952 (UTC) FILETIME=[B0AD1500:01C7FA96] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1021-15432.002 X-TM-AS-Result: No--7.209800-0.000000-31 Content-Transfer-Encoding: 7bit Cc: Subject: Re: ZFS pool not working on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 08:26:00 -0000 0n Wed, Sep 19, 2007 at 03:24:25AM -0400, Adam Jacob Muller wrote: >I have a server with two ZFS pools, one is an internal raid0 using 2 drives >connected via ahc. The other is an external storage array with 11 drives >also using ahc, using raidz. (This is a dell 1650 and pv220s). >On reboot, the pools do not come online on their own. Both pools >consistently show as failed. Make sure your hostid doesn't change. If it does. Then ZFS will fail upon bootstrap. -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 09:33:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D22116A417 for ; Wed, 19 Sep 2007 09:33:06 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A3B1813C4B7 for ; Wed, 19 Sep 2007 09:33:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IXvvW-00039g-UF for freebsd-current@freebsd.org; Wed, 19 Sep 2007 11:32:58 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Sep 2007 11:32:58 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Sep 2007 11:32:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 19 Sep 2007 11:32:50 +0200 Lines: 33 Message-ID: References: <200709141103.18612.h.schmalzbauer@omnisec.de> <20070914110024.G14481@fledge.watson.org> <46EBEA18.3080800@ongs.co.jp> <20070915170104.GF2061@home.c0mplx.org> <46EF6386.9050700@ongs.co.jp> <20070919021644.GG2061@home.c0mplx.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig6D4B1CD219D7BA5047DF5F3E" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <20070919021644.GG2061@home.c0mplx.org> X-Enigmail-Version: 0.94.4.0 Sender: news Cc: freebsd-stable@freebsd.org Subject: Re: Unionfs patchset p19 commit? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 09:33:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6D4B1CD219D7BA5047DF5F3E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Kurt Jaeger wrote: > There's another topic if one uses unionfs in jail() setups: How to > backup the files, and only those files that a different from > the base ? If you have a reasonable number of files you can maybe get away with the = "brute force" approach - gather stat's for all files in the base FS,=20 gather stat's of all files "above" and calculate an intersection with=20 different inode numbers. --------------enig6D4B1CD219D7BA5047DF5F3E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG8OzCldnAQVacBcgRAympAJ9YRoP26rWSEuzb9hI1sbmWsQx+vwCgskRC TX7AdTVhbZHX+7mTZFwzaas= =xoTS -----END PGP SIGNATURE----- --------------enig6D4B1CD219D7BA5047DF5F3E-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 09:35:05 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7A6D16A41B for ; Wed, 19 Sep 2007 09:35:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4856113C4D9 for ; Wed, 19 Sep 2007 09:35:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IXvxW-0003Gb-S0 for freebsd-current@freebsd.org; Wed, 19 Sep 2007 11:35:02 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Sep 2007 11:35:02 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Sep 2007 11:35:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 19 Sep 2007 11:34:03 +0200 Lines: 33 Message-ID: References: <200709141103.18612.h.schmalzbauer@omnisec.de> <20070914110024.G14481@fledge.watson.org> <46EBEA18.3080800@ongs.co.jp> <20070915170104.GF2061@home.c0mplx.org> <46EF6386.9050700@ongs.co.jp> <20070919021644.GG2061@home.c0mplx.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig22D980DD5D43EDBD13058270" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: X-Enigmail-Version: 0.94.4.0 Sender: news Cc: freebsd-stable@freebsd.org Subject: Re: Unionfs patchset p19 commit? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 09:35:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig22D980DD5D43EDBD13058270 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > If you have a reasonable number of files you can maybe get away with th= e=20 > "brute force" approach - gather stat's for all files in the base FS,=20 > gather stat's of all files "above" and calculate an intersection with=20 > different inode numbers. Ok, I just looked at your .c file and this is exactly what you do, sorry = for the noise :) --------------enig22D980DD5D43EDBD13058270 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG8O0LldnAQVacBcgRAxnUAKD8sBblLi2Nny9cZ5ZaufY2evBU8wCeKJP6 Rc4tgtaGQFOPdg6DI05eYNw= =nCKh -----END PGP SIGNATURE----- --------------enig22D980DD5D43EDBD13058270-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 09:48:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B901916A419 for ; Wed, 19 Sep 2007 09:48:12 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id C91BB13C458; Wed, 19 Sep 2007 09:48:10 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F0F059.9060003@FreeBSD.org> Date: Wed, 19 Sep 2007 11:48:09 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Phil Budne References: <200709182214.l8IMEsTW004875@ultimate.com> In-Reply-To: <200709182214.l8IMEsTW004875@ultimate.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: X11 distribution sets for 7.0-CURRENT (i386)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 09:48:12 -0000 Phil Budne wrote: > Is some place I can get a binary distribution of X11 for 7.0-current > (i386)? That is an FTP server with "distribution sets" to point > sysinstall at, or files for pkg_add? > > I just want basic clients, libraries and includes to build a few more > clients, and virtual X11 server accessible via VNC, and don't want to > have to build it all from scratch. pkg_add -r or portinstall -PP Kris From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 09:49:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B447B16A421 for ; Wed, 19 Sep 2007 09:49:01 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id ED22213C4E1; Wed, 19 Sep 2007 09:48:58 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F0F088.3090409@FreeBSD.org> Date: Wed, 19 Sep 2007 11:48:56 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Simun Mikecin References: <110518.61469.qm@web36612.mail.mud.yahoo.com> In-Reply-To: <110518.61469.qm@web36612.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Phil Budne , freebsd-current@freebsd.org Subject: Re: X11 distribution sets for 7.0-CURRENT (i386)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 09:49:01 -0000 Simun Mikecin wrote: >> Is some place I can get a binary distribution of X11 for 7.0-current >> (i386)? That is an FTP server with "distribution sets" to point >> sysinstall at, or files for pkg_add? > > 'pkg_add -rv' is your friend. But I'm not sure that you will get XOrg 7.3 instead of Xorg 7.2 > (until someone builts required packages). Yeah, not yet for i386, those machines are slow. Kris From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 12:10:30 2007 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01D9716A41B; Wed, 19 Sep 2007 12:10:30 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 27F7313C48A; Wed, 19 Sep 2007 12:10:28 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l8JCARcc081816; Wed, 19 Sep 2007 16:10:27 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1190203827; bh=JL/Hv73FefsaA0z0rex6B157SVZKWSsrmb+tZ8R XV8w=; l=16576; h=Date:From:To:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent; b=dOXshvrv1dLWo+BK2XW++iPMZ58WM3dskWeXo21d 8s7nyfGQwmk7szxhyX3ffJonzcos5fYr2Sae2ykso/Twir/w5iArvqLchquBqasyJCL S8Ml9vfgb2xmaKsgRnacEZ4LdDC3YWrjPypjBmmUgcTkZ3lp/G5hLxZmH1FkTRe4= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l8JCAPpd081812; Wed, 19 Sep 2007 16:10:25 +0400 (MSD) (envelope-from ache) Date: Wed, 19 Sep 2007 16:10:24 +0400 From: Andrey Chernov To: Taku YAMAMOTO , Petr Hroudn?? , current@FreeBSD.ORG, perky@FreeBSD.ORG, i18n@FreeBSD.ORG Message-ID: <20070919121024.GA81606@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Taku YAMAMOTO , Petr Hroudn?? , current@FreeBSD.ORG, perky@FreeBSD.ORG, i18n@FreeBSD.ORG References: <20070916192924.GA12678@nagual.pp.ru> <20070917092130.GA24424@nagual.pp.ru> <20070918020100.d43beb0b.taku@tackymt.homeip.net> <20070917171633.GA31179@nagual.pp.ru> <20070919111207.f37653fc.taku@tackymt.homeip.net> <20070919022555.GA70617@nagual.pp.ru> <20070919023625.GA70891@nagual.pp.ru> <20070919051830.GA72429@nagual.pp.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <20070919051830.GA72429@nagual.pp.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 12:10:30 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Sep 19, 2007 at 09:18:30AM +0400, Andrey Chernov wrote: > I change my mind again, now I use new __mb_bit8_override flag specific to > UTF-8 encoding (other bit8 overriding encodings could use it too). New > patch attached. Improved vesrsion. Intoduce general __mb_sch_limit parameter instead for all locales specifying upper limit of single char range. It allows also fix the bug when ctype(3) functions called with arg > 0xFF for wide character locales and simplifies all checks. New patch is attached. Here is updated rationale again: ------------------------------------------------------------------------- The problem is: currently our single byte ctype(3) functions are broken for wide characters locales in the argument range >= 0x80 - they may return false positives. Example 1: for UTF-8 locale we currently have: iswspace(0xA0)==1 and isspace(0xA0)==1 (because iswspace() and isspace() are the same code) but must have iswspace(0xA0)==1 and isspace(0xA0)==0 (because there is no such character and all others in the range 0x80..0xff for the UTF-8 locale, it keeps ASCII only in the single byte range because our internal wchar_t representation for UTF-8 is UCS-4). Example 2: for all wide character locales isalpha(arg) when arg > 0xFF may return false positives (must be 0). (because iswalpha() and isalpha() are the same code) Attached patch address this issue and also fix iswascii() (currently iswascii() is broken for arguments > 0xFF). This patch is 100% binary compatible with old binaries. -- http://ache.pp.ru/ --0OAP2g/MAC+5xKAE Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ctype.patch" --- _ctype.h.old 2007-09-16 21:13:59.000000000 +0400 +++ _ctype.h 2007-09-19 15:29:41.000000000 +0400 @@ -63,6 +63,7 @@ #define _CTYPE_I 0x00080000L /* Ideogram */ #define _CTYPE_T 0x00100000L /* Special */ #define _CTYPE_Q 0x00200000L /* Phonogram */ +#define _CTYPE_WID 0x10000000L /* wide character function */ #define _CTYPE_SW0 0x20000000L /* 0 width character */ #define _CTYPE_SW1 0x40000000L /* 1 width character */ #define _CTYPE_SW2 0x80000000L /* 2 width character */ @@ -87,6 +88,8 @@ #define __inline #endif +extern int __mb_sch_limit; + /* * Use inline functions if we are allowed to and the compiler supports them. */ @@ -98,8 +101,11 @@ static __inline int __maskrune(__ct_rune_t _c, unsigned long _f) { - return ((_c < 0 || _c >= _CACHED_RUNES) ? ___runetype(_c) : + return (_c < 0 || (!(_f & _CTYPE_WID) && _c >= __mb_sch_limit)) ? 0 : + (_c >= _CACHED_RUNES ? ___runetype(_c) : _CurrentRuneLocale->__runetype[_c]) & _f; + /* We never set _CTYPE_WID in the locale data, */ + /* so can skip ... & (_f & ~_CTYPE_WID). */ } static __inline int @@ -111,7 +117,7 @@ static __inline int __isctype(__ct_rune_t _c, unsigned long _f) { - return (_c < 0 || _c >= _CACHED_RUNES) ? 0 : + return (_c < 0 || _c >= __mb_sch_limit) ? 0 : !!(_DefaultRuneLocale.__runetype[_c] & _f); } @@ -129,6 +135,20 @@ _CurrentRuneLocale->__maplower[_c]; } +static __inline __ct_rune_t +__tosupper(__ct_rune_t _c) +{ + return (_c < 0 || _c >= __mb_sch_limit) ? _c : + _CurrentRuneLocale->__mapupper[_c]; +} + +static __inline __ct_rune_t +__toslower(__ct_rune_t _c) +{ + return (_c < 0 || _c >= __mb_sch_limit) ? _c : + _CurrentRuneLocale->__maplower[_c]; +} + static __inline int __wcwidth(__ct_rune_t _c) { @@ -150,6 +170,8 @@ int __isctype(__ct_rune_t, unsigned long); __ct_rune_t __toupper(__ct_rune_t); __ct_rune_t __tolower(__ct_rune_t); +__ct_rune_t __tosupper(__ct_rune_t); +__ct_rune_t __toslower(__ct_rune_t); int __wcwidth(__ct_rune_t); __END_DECLS #endif /* using inlines */ --- big5.c.old 2007-09-19 08:48:55.000000000 +0400 +++ big5.c 2007-09-19 15:41:26.000000000 +0400 @@ -49,6 +49,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _BIG5_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _BIG5_mbsinit(const mbstate_t *); @@ -68,6 +70,7 @@ __mbsinit = _BIG5_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_sch_limit = 256; return (0); } --- ctype.h.old 2007-09-16 22:03:55.000000000 +0400 +++ ctype.h 2007-09-16 22:56:10.000000000 +0400 @@ -97,8 +97,8 @@ #define isspace(c) __istype((c), _CTYPE_S) #define isupper(c) __istype((c), _CTYPE_U) #define isxdigit(c) __isctype((c), _CTYPE_X) /* ANSI -- locale independent */ -#define tolower(c) __tolower(c) -#define toupper(c) __toupper(c) +#define tolower(c) __toslower(c) +#define toupper(c) __tosupper(c) #if __XSI_VISIBLE /* @@ -112,8 +112,8 @@ * * XXX isascii() and toascii() should similarly be undocumented. */ -#define _tolower(c) __tolower(c) -#define _toupper(c) __toupper(c) +#define _tolower(c) __toslower(c) +#define _toupper(c) __tosupper(c) #define isascii(c) (((c) & ~0x7F) == 0) #define toascii(c) ((c) & 0x7F) #endif @@ -128,7 +128,7 @@ #define isideogram(c) __istype((c), _CTYPE_I) #define isnumber(c) __istype((c), _CTYPE_D) #define isphonogram(c) __istype((c), _CTYPE_Q) -#define isrune(c) __istype((c), 0xFFFFFF00L) +#define isrune(c) __istype((c), 0xFFFFFF00L & ~_CTYPE_WID) #define isspecial(c) __istype((c), _CTYPE_T) #endif --- euc.c.old 2007-09-19 08:50:57.000000000 +0400 +++ euc.c 2007-09-19 15:41:26.000000000 +0400 @@ -49,6 +49,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _EUC_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _EUC_mbsinit(const mbstate_t *); @@ -116,6 +118,7 @@ __mbrtowc = _EUC_mbrtowc; __wcrtomb = _EUC_wcrtomb; __mbsinit = _EUC_mbsinit; + __mb_sch_limit = 256; return (0); } --- gb18030.c.old 2007-09-19 08:59:01.000000000 +0400 +++ gb18030.c 2007-09-19 15:41:26.000000000 +0400 @@ -39,6 +39,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _GB18030_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GB18030_mbsinit(const mbstate_t *); @@ -59,6 +61,7 @@ __mbsinit = _GB18030_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 4; + __mb_sch_limit = 256; return (0); } --- gb2312.c.old 2007-09-19 09:00:35.000000000 +0400 +++ gb2312.c 2007-09-19 15:41:26.000000000 +0400 @@ -35,6 +35,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _GB2312_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GB2312_mbsinit(const mbstate_t *); @@ -55,6 +57,7 @@ __wcrtomb = _GB2312_wcrtomb; __mbsinit = _GB2312_mbsinit; __mb_cur_max = 2; + __mb_sch_limit = 256; return (0); } --- gbk.c.old 2007-09-19 09:01:33.000000000 +0400 +++ gbk.c 2007-09-19 15:41:26.000000000 +0400 @@ -42,6 +42,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _GBK_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GBK_mbsinit(const mbstate_t *); @@ -61,6 +63,7 @@ __mbsinit = _GBK_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_sch_limit = 256; return (0); } --- isctype.c.old 2007-09-16 22:31:26.000000000 +0400 +++ isctype.c 2007-09-16 22:37:54.000000000 +0400 @@ -168,7 +168,7 @@ isrune(c) int c; { - return (__istype(c, 0xFFFFFF00L)); + return (__istype(c, 0xFFFFFF00L & ~_CTYPE_WID)); } #undef isspace @@ -216,7 +216,7 @@ tolower(c) int c; { - return (__tolower(c)); + return (__toslower(c)); } #undef toupper @@ -224,6 +224,6 @@ toupper(c) int c; { - return (__toupper(c)); + return (__tosupper(c)); } --- iswctype.c.old 2007-09-16 22:31:30.000000000 +0400 +++ iswctype.c 2007-09-19 15:45:26.000000000 +0400 @@ -45,7 +45,7 @@ iswalnum(wc) wint_t wc; { - return (__istype(wc, _CTYPE_A|_CTYPE_D)); + return (__istype(wc, _CTYPE_A|_CTYPE_D|_CTYPE_WID)); } #undef iswalpha @@ -53,7 +53,7 @@ iswalpha(wc) wint_t wc; { - return (__istype(wc, _CTYPE_A)); + return (__istype(wc, _CTYPE_A|_CTYPE_WID)); } #undef iswascii @@ -61,7 +61,7 @@ iswascii(wc) wint_t wc; { - return ((wc & ~0x7F) == 0); + return (wc < 0x80); } #undef iswblank @@ -69,7 +69,7 @@ iswblank(wc) wint_t wc; { - return (__istype(wc, _CTYPE_B)); + return (__istype(wc, _CTYPE_B|_CTYPE_WID)); } #undef iswcntrl @@ -77,7 +77,7 @@ iswcntrl(wc) wint_t wc; { - return (__istype(wc, _CTYPE_C)); + return (__istype(wc, _CTYPE_C|_CTYPE_WID)); } #undef iswdigit @@ -93,7 +93,7 @@ iswgraph(wc) wint_t wc; { - return (__istype(wc, _CTYPE_G)); + return (__istype(wc, _CTYPE_G|_CTYPE_WID)); } #undef iswhexnumber @@ -101,7 +101,7 @@ iswhexnumber(wc) wint_t wc; { - return (__istype(wc, _CTYPE_X)); + return (__istype(wc, _CTYPE_X|_CTYPE_WID)); } #undef iswideogram @@ -109,7 +109,7 @@ iswideogram(wc) wint_t wc; { - return (__istype(wc, _CTYPE_I)); + return (__istype(wc, _CTYPE_I|_CTYPE_WID)); } #undef iswlower @@ -117,7 +117,7 @@ iswlower(wc) wint_t wc; { - return (__istype(wc, _CTYPE_L)); + return (__istype(wc, _CTYPE_L|_CTYPE_WID)); } #undef iswnumber @@ -125,7 +125,7 @@ iswnumber(wc) wint_t wc; { - return (__istype(wc, _CTYPE_D)); + return (__istype(wc, _CTYPE_D|_CTYPE_WID)); } #undef iswphonogram @@ -133,7 +133,7 @@ iswphonogram(wc) wint_t wc; { - return (__istype(wc, _CTYPE_Q)); + return (__istype(wc, _CTYPE_Q|_CTYPE_WID)); } #undef iswprint @@ -141,7 +141,7 @@ iswprint(wc) wint_t wc; { - return (__istype(wc, _CTYPE_R)); + return (__istype(wc, _CTYPE_R|_CTYPE_WID)); } #undef iswpunct @@ -149,7 +149,7 @@ iswpunct(wc) wint_t wc; { - return (__istype(wc, _CTYPE_P)); + return (__istype(wc, _CTYPE_P|_CTYPE_WID)); } #undef iswrune @@ -157,7 +157,7 @@ iswrune(wc) wint_t wc; { - return (__istype(wc, 0xFFFFFF00L)); + return (__istype(wc, 0xFFFFFF00L)); /* already have _CTYPE_WID */ } #undef iswspace @@ -165,7 +165,7 @@ iswspace(wc) wint_t wc; { - return (__istype(wc, _CTYPE_S)); + return (__istype(wc, _CTYPE_S|_CTYPE_WID)); } #undef iswspecial @@ -173,7 +173,7 @@ iswspecial(wc) wint_t wc; { - return (__istype(wc, _CTYPE_T)); + return (__istype(wc, _CTYPE_T|_CTYPE_WID)); } #undef iswupper @@ -181,7 +181,7 @@ iswupper(wc) wint_t wc; { - return (__istype(wc, _CTYPE_U)); + return (__istype(wc, _CTYPE_U|_CTYPE_WID)); } #undef iswxdigit --- mskanji.c.old 2007-09-19 09:02:56.000000000 +0400 +++ mskanji.c 2007-09-19 15:41:26.000000000 +0400 @@ -47,6 +47,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _MSKanji_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _MSKanji_mbsinit(const mbstate_t *); @@ -66,6 +68,7 @@ __mbsinit = _MSKanji_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_sch_limit = 256; return (0); } --- none.c.old 2007-09-19 08:56:40.000000000 +0400 +++ none.c 2007-09-19 15:51:44.000000000 +0400 @@ -58,6 +58,11 @@ static size_t _none_wcsnrtombs(char * __restrict, const wchar_t ** __restrict, size_t, size_t, mbstate_t * __restrict); +/* setup defaults */ + +int __mb_cur_max = 1; +int __mb_sch_limit = 256; /* Expected to be <= _CACHED_RUNES */ + int _none_init(_RuneLocale *rl) { @@ -69,6 +74,7 @@ __wcsnrtombs = _none_wcsnrtombs; _CurrentRuneLocale = rl; __mb_cur_max = 1; + __mb_sch_limit = 256; return(0); } @@ -176,7 +182,6 @@ /* setup defaults */ -int __mb_cur_max = 1; size_t (*__mbrtowc)(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict) = _none_mbrtowc; int (*__mbsinit)(const mbstate_t *) = _none_mbsinit; --- setrunelocale.c.old 2007-09-19 09:03:59.000000000 +0400 +++ setrunelocale.c 2007-09-19 15:41:26.000000000 +0400 @@ -45,6 +45,8 @@ #include "mblocal.h" #include "setlocale.h" +extern int __mb_sch_limit; + extern _RuneLocale *_Read_RuneMagi(FILE *); static int __setrunelocale(const char *); @@ -59,6 +61,7 @@ static char ctype_encoding[ENCODING_LEN + 1]; static _RuneLocale *CachedRuneLocale; static int Cached__mb_cur_max; + static int Cached__mb_sch_limit; static size_t (*Cached__mbrtowc)(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static size_t (*Cached__wcrtomb)(char * __restrict, wchar_t, @@ -85,6 +88,7 @@ strcmp(encoding, ctype_encoding) == 0) { _CurrentRuneLocale = CachedRuneLocale; __mb_cur_max = Cached__mb_cur_max; + __mb_sch_limit = Cached__mb_sch_limit; __mbrtowc = Cached__mbrtowc; __mbsinit = Cached__mbsinit; __mbsnrtowcs = Cached__mbsnrtowcs; @@ -147,6 +151,7 @@ } CachedRuneLocale = _CurrentRuneLocale; Cached__mb_cur_max = __mb_cur_max; + Cached__mb_sch_limit = __mb_sch_limit; Cached__mbrtowc = __mbrtowc; Cached__mbsinit = __mbsinit; Cached__mbsnrtowcs = __mbsnrtowcs; --- utf8.c.old 2007-09-19 08:18:40.000000000 +0400 +++ utf8.c 2007-09-19 15:55:35.000000000 +0400 @@ -35,6 +35,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _UTF8_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _UTF8_mbsinit(const mbstate_t *); @@ -63,6 +65,7 @@ __wcsnrtombs = _UTF8_wcsnrtombs; _CurrentRuneLocale = rl; __mb_cur_max = 6; + __mb_sch_limit = 128; return (0); } --- wctype.h.old 2007-09-16 21:59:37.000000000 +0400 +++ wctype.h 2007-09-19 15:31:40.000000000 +0400 @@ -89,30 +89,30 @@ #endif __END_DECLS -#define iswalnum(wc) __istype((wc), _CTYPE_A|_CTYPE_D) -#define iswalpha(wc) __istype((wc), _CTYPE_A) -#define iswblank(wc) __istype((wc), _CTYPE_B) -#define iswcntrl(wc) __istype((wc), _CTYPE_C) -#define iswctype(wc, charclass) __istype((wc), (charclass)) +#define iswalnum(wc) __istype((wc), _CTYPE_A|_CTYPE_D|_CTYPE_WID) +#define iswalpha(wc) __istype((wc), _CTYPE_A|_CTYPE_WID) +#define iswblank(wc) __istype((wc), _CTYPE_B|_CTYPE_WID) +#define iswcntrl(wc) __istype((wc), _CTYPE_C|_CTYPE_WID) +#define iswctype(wc, charclass) __istype((wc), (charclass)|_CTYPE_WID) #define iswdigit(wc) __isctype((wc), _CTYPE_D) -#define iswgraph(wc) __istype((wc), _CTYPE_G) -#define iswlower(wc) __istype((wc), _CTYPE_L) -#define iswprint(wc) __istype((wc), _CTYPE_R) -#define iswpunct(wc) __istype((wc), _CTYPE_P) -#define iswspace(wc) __istype((wc), _CTYPE_S) -#define iswupper(wc) __istype((wc), _CTYPE_U) +#define iswgraph(wc) __istype((wc), _CTYPE_G|_CTYPE_WID) +#define iswlower(wc) __istype((wc), _CTYPE_L|_CTYPE_WID) +#define iswprint(wc) __istype((wc), _CTYPE_R|_CTYPE_WID) +#define iswpunct(wc) __istype((wc), _CTYPE_P|_CTYPE_WID) +#define iswspace(wc) __istype((wc), _CTYPE_S|_CTYPE_WID) +#define iswupper(wc) __istype((wc), _CTYPE_U|_CTYPE_WID) #define iswxdigit(wc) __isctype((wc), _CTYPE_X) #define towlower(wc) __tolower(wc) #define towupper(wc) __toupper(wc) #if __BSD_VISIBLE -#define iswascii(wc) (((wc) & ~0x7F) == 0) -#define iswhexnumber(wc) __istype((wc), _CTYPE_X) -#define iswideogram(wc) __istype((wc), _CTYPE_I) -#define iswnumber(wc) __istype((wc), _CTYPE_D) -#define iswphonogram(wc) __istype((wc), _CTYPE_Q) -#define iswrune(wc) __istype((wc), 0xFFFFFF00L) -#define iswspecial(wc) __istype((wc), _CTYPE_T) +#define iswascii(wc) ((wc) < 0x80) +#define iswhexnumber(wc) __istype((wc), _CTYPE_X|_CTYPE_WID) +#define iswideogram(wc) __istype((wc), _CTYPE_I|_CTYPE_WID) +#define iswnumber(wc) __istype((wc), _CTYPE_D|_CTYPE_WID) +#define iswphonogram(wc) __istype((wc), _CTYPE_Q|_CTYPE_WID) +#define iswrune(wc) __istype((wc), 0xFFFFFF00L) /* already have _CTYPE_WID */ +#define iswspecial(wc) __istype((wc), _CTYPE_T|_CTYPE_WID) #endif #endif /* _WCTYPE_H_ */ --0OAP2g/MAC+5xKAE-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 12:14:49 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA1D316A419 for ; Wed, 19 Sep 2007 12:14:49 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by mx1.freebsd.org (Postfix) with ESMTP id 8F48B13C467 for ; Wed, 19 Sep 2007 12:14:49 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so129182nzf for ; Wed, 19 Sep 2007 05:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=z2URaNo8GhpMmf4Of1Axbn2Qhtgi2aCAHlA5jDp67yc=; b=rjekcuECEfkb4dJh6gJqSfN5twkv6cSEyO/d/RcYwE9KBVOW1pxcleUKWloOgd+1ItqHkoOk3LrnfcFjXfgXcHsotb3HNoIarBC8mwln3r0Jhcl/LwrK6YDpevUAckefnBXqYaF5uEcyTXbRvnYqljTJ0Zp00cGeCtYpY2XryEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kDNFom7crWqXOJFxtDZA8wYadYRa80sutEeFoh6VnxicR+gQEIfLDexlKmNKjktviGUX36zPDQiaBB2OChIabffTbT7xLF04OLPysACx4VQVGw7uDAnsz0EONKHj3JAbT9UEqsbq9VAuQu/4XS2e2A1rlkG+uZHE4Wwr4LG42hk= Received: by 10.142.229.4 with SMTP id b4mr96632wfh.1190204088100; Wed, 19 Sep 2007 05:14:48 -0700 (PDT) Received: by 10.143.165.17 with HTTP; Wed, 19 Sep 2007 05:14:48 -0700 (PDT) Message-ID: <3a142e750709190514j61d094bbu68f50d683cd316bd@mail.gmail.com> Date: Wed, 19 Sep 2007 12:14:48 +0000 From: "PBM ." To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: wireless support broken on current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 12:14:49 -0000 With both ndis0 and rum0 drivers for two diferent WLAN card I could not connect to AP. # ifconfig ndis0/rum0 scan doesnt give any results, ifconfig stays in sbwait state forever. on 6.2 STABLE ndis0 works fine but there is no rum0 - which is only available in CURRENT so it is reason I prefer current. From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 13:08:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E270816A41B for ; Wed, 19 Sep 2007 13:08:31 +0000 (UTC) (envelope-from tobez@tobez.org) Received: from heechee.tobez.org (heechee.tobez.org [194.255.56.42]) by mx1.freebsd.org (Postfix) with ESMTP id A6E4D13C469 for ; Wed, 19 Sep 2007 13:08:31 +0000 (UTC) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 0663D12543D; Wed, 19 Sep 2007 14:50:30 +0200 (CEST) Date: Wed, 19 Sep 2007 14:50:29 +0200 From: Anton Berezin To: Eric Schuele Message-ID: <20070919125029.GB45191@heechee.tobez.org> Mail-Followup-To: Anton Berezin , Eric Schuele , freebsd-current@freebsd.org References: <46E98E44.2070808@computer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E98E44.2070808@computer.org> User-Agent: Mutt/1.4.2.3i X-Powered-By: FreeBSD http://www.freebsd.org/ Cc: freebsd-current@freebsd.org Subject: Re: Perl_mallloc() segfault (v5.8.8).... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 13:08:32 -0000 On Thu, Sep 13, 2007 at 02:23:48PM -0500, Eric Schuele wrote: > Hello, > > I seem to have a perl problem. Not much of a perl person so not sure if > the problem is me or not. I'm not even sure I should be posting to > freebsd-current@, but since it worked in 6.2... I'm assuming its perl+7.0. > > Running current i386, and using perl 5.8.8, I get the following back > trace on an app that attempts to use perl for an add-on script. > > #0 0x2972726c in Perl_malloc () > from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so > #1 0x297d75dc in PerlIO_allocate () > from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so > #2 0x297dc257 in PerlIO_stdstreams () > from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so > #3 0x297dc2c2 in Perl_PerlIO_stderr () > from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so > #4 0x297280b0 in Perl_malloc () > from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so > #5 0x297d75dc in PerlIO_allocate () > from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so > #6 0x297dc257 in PerlIO_stdstreams () > from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so > #7 0x297dc2c2 in Perl_PerlIO_stderr () > from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so > #8 0x297280b0 in Perl_malloc () > > Note that this app was working, as well as its add-on script a few days > back when I was running 6.2-STABLE. I backed-up everything, formatted > my disk, installed 7.0 (snapshot), cvsup'd to most recent (sunday > evening)... reinstalled the app in question from package, then from > ports. It however always results in the above bt. If I remove the > script from the add-ons (its the only script I have) the app runs fine. What is the script? What's the output of ldd `which perl`? What's the output of ldd /path/to/xchat (assuming "app" is "xchat", it's not entirely clear)? What's the output of perl -V? The contents of /etc/make.conf might also be useful > Wondering if a bug report is warranted? Should it be filed under xchat, > perl, or what? Cheers, \Anton. -- We're going for 'working' here. 'clean' is for people with skills... -- Flemming Jacobsen From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 13:10:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3E7516A420 for ; Wed, 19 Sep 2007 13:10:15 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.de [194.25.134.81]) by mx1.freebsd.org (Postfix) with ESMTP id 8097213C483 for ; Wed, 19 Sep 2007 13:10:15 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from fwd35.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1IXzJl-0006sr-02; Wed, 19 Sep 2007 15:10:13 +0200 Received: from localhost (bdhteqZlotUvtJNCy9BidrRT39wi0OcCJq3mDhIwVg7i4ID7gjQQ3xOWnbsrBkZQwwqp2ObBk0@[84.165.76.45]) by fwd35.t-online.de with esmtp id 1IXzJh-2JE0Mi0; Wed, 19 Sep 2007 15:10:09 +0200 Date: Wed, 19 Sep 2007 15:10:08 +0200 From: Oliver Herold To: freebsd-current@freebsd.org Message-ID: <20070919131007.GA21833@olymp.home> Mail-Followup-To: freebsd-current@freebsd.org References: <3a142e750709190514j61d094bbu68f50d683cd316bd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a142e750709190514j61d094bbu68f50d683cd316bd@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-ID: bdhteqZlotUvtJNCy9BidrRT39wi0OcCJq3mDhIwVg7i4ID7gjQQ3xOWnbsrBkZQwwqp2ObBk0 X-TOI-MSGID: db8c1104-5a9b-43d9-a5d7-dc6df2dc5510 Subject: Re: wireless support broken on current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 13:10:15 -0000 Maybe rum per se is broken. I remember some problems with rum and kernel panics in current. I'm using ral at the moment together with a pc-card without any problems. Current is from today. Cheers, Oliver On Wed, Sep 19, 2007 at 12:14:48PM +0000, PBM . wrote: > With both ndis0 and rum0 drivers for two diferent WLAN card I could > not connect to AP. > > # ifconfig ndis0/rum0 scan doesnt give any results, ifconfig stays in > sbwait state forever. > > on 6.2 STABLE ndis0 works fine but there is no rum0 - which is only > available in CURRENT so it is reason I prefer current. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Physically there is nothing to distinguish human society from the farm-yard except that children are more troublesome and costly than chickens and women are not so completely enslaved as farm stock. -- George Bernard Shaw, "Getting Married" From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 13:43:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C51216A420 for ; Wed, 19 Sep 2007 13:43:15 +0000 (UTC) (envelope-from e.schuele@computer.org) Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by mx1.freebsd.org (Postfix) with SMTP id 4C36013C4A5 for ; Wed, 19 Sep 2007 13:43:15 +0000 (UTC) (envelope-from e.schuele@computer.org) Received: (qmail 19837 invoked from network); 19 Sep 2007 13:43:14 -0000 Received: from unknown (208.206.151.5) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 19 Sep 2007 13:43:14 -0000 Message-ID: <46F12770.30807@computer.org> Date: Wed, 19 Sep 2007 08:43:12 -0500 From: Eric Schuele User-Agent: Thunderbird 2.0.0.6 (X11/20070912) MIME-Version: 1.0 To: Anton Berezin , Eric Schuele , freebsd-current@freebsd.org References: <46E98E44.2070808@computer.org> <20070919125029.GB45191@heechee.tobez.org> In-Reply-To: <20070919125029.GB45191@heechee.tobez.org> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.ravenlock.us/files/pub_schuele.pgp Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDFA721CEA6F7939081101D4F" Cc: Subject: Re: Perl_mallloc() segfault (v5.8.8).... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 13:43:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDFA721CEA6F7939081101D4F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/19/2007 07:50, Anton Berezin wrote: > On Thu, Sep 13, 2007 at 02:23:48PM -0500, Eric Schuele wrote: >> Hello, >> >> I seem to have a perl problem. Not much of a perl person so not sure = if >> the problem is me or not. I'm not even sure I should be posting to >> freebsd-current@, but since it worked in 6.2... I'm assuming its perl+= 7.0. >> >> Running current i386, and using perl 5.8.8, I get the following back >> trace on an app that attempts to use perl for an add-on script. >> >> #0 0x2972726c in Perl_malloc () >> from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so >> #1 0x297d75dc in PerlIO_allocate () >> from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so >> #2 0x297dc257 in PerlIO_stdstreams () >> from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so >> #3 0x297dc2c2 in Perl_PerlIO_stderr () >> from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so >> #4 0x297280b0 in Perl_malloc () >> from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so >> #5 0x297d75dc in PerlIO_allocate () >> from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so >> #6 0x297dc257 in PerlIO_stdstreams () >> from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so >> #7 0x297dc2c2 in Perl_PerlIO_stderr () >> from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so >> #8 0x297280b0 in Perl_malloc () >> >> Note that this app was working, as well as its add-on script a few day= s >> back when I was running 6.2-STABLE. I backed-up everything, formatted= >> my disk, installed 7.0 (snapshot), cvsup'd to most recent (sunday >> evening)... reinstalled the app in question from package, then from >> ports. It however always results in the above bt. If I remove the >> script from the add-ons (its the only script I have) the app runs fine= =2E >=20 > What is the script? Its called OnJoin for xchat. Performs actions when ppl join. > What's the output of ldd `which perl`? % ldd `which perl` /usr/bin/perl: libperl.so =3D> /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so (0x2807c000) libm.so.5 =3D> /lib/libm.so.5 (0x28182000) libcrypt.so.4 =3D> /lib/libcrypt.so.4 (0x28197000) libutil.so.7 =3D> /lib/libutil.so.7 (0x281b0000) libc.so.7 =3D> /lib/libc.so.7 (0x281bd000) > What's the output of ldd /path/to/xchat (assuming "app" is "xchat", it= 's % ldd `which xchat` /usr/local/bin/xchat: libintl.so.8 =3D> /usr/local/lib/libintl.so.8 (0x2810b000) libiconv.so.3 =3D> /usr/local/lib/libiconv.so.3 (0x28114000) libgtkspell.so.0 =3D> /usr/local/lib/libgtkspell.so.0 (0x28202000= ) libaspell.so.16 =3D> /usr/local/lib/libaspell.so.16 (0x28208000) libgtk-x11-2.0.so.0 =3D> /usr/local/lib/libgtk-x11-2.0.so.0 (0x282bf000) libgdk-x11-2.0.so.0 =3D> /usr/local/lib/libgdk-x11-2.0.so.0 (0x28605000) libatk-1.0.so.0 =3D> /usr/local/lib/libatk-1.0.so.0 (0x28689000) libgdk_pixbuf-2.0.so.0 =3D> /usr/local/lib/libgdk_pixbuf-2.0.so.0= (0x286a3000) libpangocairo-1.0.so.0 =3D> /usr/local/lib/libpangocairo-1.0.so.0= (0x286ba000) libXinerama.so.1 =3D> /usr/local/lib/libXinerama.so.1 (0x286c3000= ) libXi.so.6 =3D> /usr/local/lib/libXi.so.6 (0x286c6000) libXrandr.so.2 =3D> /usr/local/lib/libXrandr.so.2 (0x286ce000) libXext.so.6 =3D> /usr/local/lib/libXext.so.6 (0x286d4000) libXcursor.so.1 =3D> /usr/local/lib/libXcursor.so.1 (0x286e2000) libXfixes.so.3 =3D> /usr/local/lib/libXfixes.so.3 (0x286eb000) libcairo.so.2 =3D> /usr/local/lib/libcairo.so.2 (0x286f0000) libpng.so.5 =3D> /usr/local/lib/libpng.so.5 (0x28765000) libXrender.so.1 =3D> /usr/local/lib/libXrender.so.1 (0x28789000) libpangoft2-1.0.so.0 =3D> /usr/local/lib/libpangoft2-1.0.so.0 (0x28791000) libfontconfig.so.1 =3D> /usr/local/lib/libfontconfig.so.1 (0x287b= d000) libexpat.so.6 =3D> /usr/local/lib/libexpat.so.6 (0x287e8000) libfreetype.so.9 =3D> /usr/local/lib/libfreetype.so.9 (0x28809000= ) libz.so.4 =3D> /lib/libz.so.4 (0x2887b000) libpango-1.0.so.0 =3D> /usr/local/lib/libpango-1.0.so.0 (0x2888d0= 00) libm.so.5 =3D> /lib/libm.so.5 (0x288cb000) libX11.so.6 =3D> /usr/local/lib/libX11.so.6 (0x288e0000) libXau.so.6 =3D> /usr/local/lib/libXau.so.6 (0x289cc000) libXdmcp.so.6 =3D> /usr/local/lib/libXdmcp.so.6 (0x289cf000) librpcsvc.so.4 =3D> /usr/lib/librpcsvc.so.4 (0x289d4000) libgmodule-2.0.so.0 =3D> /usr/local/lib/libgmodule-2.0.so.0 (0x289dc000) libdbus-glib-1.so.2 =3D> /usr/local/lib/libdbus-glib-1.so.2 (0x289e0000) libdbus-1.so.3 =3D> /usr/local/lib/libdbus-1.so.3 (0x289fc000) libgobject-2.0.so.0 =3D> /usr/local/lib/libgobject-2.0.so.0 (0x28a38000) libgthread-2.0.so.0 =3D> /usr/local/lib/libgthread-2.0.so.0 (0x28a74000) libssl.so.5 =3D> /usr/lib/libssl.so.5 (0x28a79000) libcrypto.so.5 =3D> /lib/libcrypto.so.5 (0x28ab8000) libglib-2.0.so.0 =3D> /usr/local/lib/libglib-2.0.so.0 (0x28c04000= ) libthr.so.3 =3D> /lib/libthr.so.3 (0x28c9a000) libc.so.7 =3D> /lib/libc.so.7 (0x28cac000) libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x28da2000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x28e83000) > What's the output of perl -V? % perl -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=3Dfreebsd, osvers=3D7.0-current, archname=3Di386-freebsd-64int= uname=3D'freebsd freebsd.org 7.0-current freebsd 7.0-current #0: fri aug 3 00:53:24 pdt 2007 kris@freebsd.org:usrsrcsysmagickernelpath i386 ' config_args=3D'-sde -Dprefix=3D/usr/local -Darchlib=3D/usr/local/lib/perl5/5.8.8/mach -Dprivlib=3D/usr/local/lib/perl5/5.8.8 -Dman3dir=3D/usr/local/lib/perl5/5.8.8/perl/man/man3 -Dman1dir=3D/usr/local/man/man1 -Dsitearch=3D/usr/local/lib/perl5/site_perl/5.8.8/mach -Dsitelib=3D/usr/local/lib/perl5/site_perl/5.8.8 -Dscriptdir=3D/usr/local/bin -Dsiteman3dir=3D/usr/local/lib/perl5/5.8.8/man/man3 -Dsiteman1dir=3D/usr/local/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=3Dcc -Duseshrplib -Dccflags=3D-DAPPLLIB_EXP=3D"/usr/local/lib/perl5/5.8.8/BSDPAN" -Doptimize=3D-O1 -pipe -Ud_dosuid -Ui_gdbm -Dusethreads=3Dn -Dusemymallo= c=3Dy -Duse64bitint' hint=3Drecommended, useposix=3Dtrue, d_sigaction=3Ddefine usethreads=3Dundef use5005threads=3Dundef useithreads=3Dundef usemultiplicity=3Dundef useperlio=3Ddefine d_sfio=3Dundef uselargefiles=3Ddefine usesocks=3Du= ndef use64bitint=3Ddefine use64bitall=3Dundef uselongdouble=3Dundef usemymalloc=3Dy, bincompat5005=3Dundef Compiler: cc=3D'cc', ccflags =3D'-DAPPLLIB_EXP=3D"/usr/local/lib/perl5/5.8.8/BS= DPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include', optimize=3D'-O1 -pipe ', cppflags=3D'-DAPPLLIB_EXP=3D"/usr/local/lib/perl5/5.8.8/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include' ccversion=3D'', gccversion=3D'4.2.0 20070514 [FreeBSD]', gccosandvers= =3D'' intsize=3D4, longsize=3D4, ptrsize=3D4, doublesize=3D8, byteorder=3D1= 2345678 d_longlong=3Ddefine, longlongsize=3D8, d_longdbl=3Ddefine, longdblsiz= e=3D12 ivtype=3D'long long', ivsize=3D8, nvtype=3D'double', nvsize=3D8, Off_t=3D'off_t', lseeksize=3D8 alignbytes=3D4, prototype=3Ddefine Linker and Libraries: ld=3D'cc', ldflags =3D' -Wl,-E -L/usr/local/lib' libpth=3D/usr/lib /usr/local/lib libs=3D-lm -lcrypt -lutil perllibs=3D-lm -lcrypt -lutil libc=3D, so=3Dso, useshrplib=3Dtrue, libperl=3Dlibperl.so gnulibc_version=3D'' Dynamic Linking: dlsrc=3Ddl_dlopen.xs, dlext=3Dso, d_dlsymun=3Dundef, ccdlflags=3D' -Wl,-R/usr/local/lib/perl5/5.8.8/mach/CORE' cccdlflags=3D'-DPIC -fPIC', lddlflags=3D'-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MYMALLOC PERL_MALLOC_WRAP USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Locally applied patches: defined-or Built under freebsd Compiled at Aug 3 2007 08:00:20 @INC: /usr/local/lib/perl5/5.8.8/BSDPAN /usr/local/lib/perl5/site_perl/5.8.8/mach /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.8.8/mach /usr/local/lib/perl5/5.8.8 . > The contents of /etc/make.conf might also be useful % cat /etc/make.conf # Optimizations CPUTYPE?=3Dpentium4 CFLAGS=3D -O -pipe COPTFLAGS=3D -O -pipe # # General Items # NO_PROFILE=3D true USA_RESIDENT=3D true # Due to CUPS NO_LPR=3D true WITH_CUPS=3D yes # Only build English Docs DOC_LANG=3D en_US.ISO8859-1 # Make sure we are using Fedora Core as linuxulator # Is this still needed? OVERRIDE_LINUX_BASE_PORT=3Dfc4 # mplayer-plugin and others WITH_MOZILLA=3D firefox WITH_GECKO=3D firefox # # Port Settings # ########################## # Pidgin =2Eif ${.CURDIR:M*/net-im/libpurple} WITH_GNUTLS=3Dyes WITHOUT_NSS=3Dyes WITH_GTKUI=3Dyes =2Eendif ########################### # CUPS =2Eif ${.CURDIR:M*/print/cups-base} CUPS_OVERWRITE_BASE=3D yes =2Eendif =2Eif ${.CURDIR:M*/print/cups} CUPS_OVERWRITE_BASE=3D yes =2Eendif ########################### # LinuxPluginWrapper =2Eif ${.CURDIR:M*/www/linuxpluginwrapper} WITH_REALPLAYER=3D yes WITH_ACROREAD=3D yes =2Eendif ########################### # MySQL =2Eif ${.CURDIR:M*/databases/mysql50-server} WITH_LINUXTHREADS=3D yes =2Eendif ########################### # gnucash =2Eif ${.CURDIR:M*/finance/gnucash2} #libltdl_cv_sys_dlopen_deplibs=3D yes =2Eendif =2Eif ${.CURDIR:M*/lang/guile} #libltdl_cv_sys_dlopen_deplibs=3D yes =2Eendif =2Eif ${.CURDIR:M*/devel/libltdl15} #libltdl_cv_sys_dlopen_deplibs=3D yes =2Eendif ########################### # <<<<< EOF >>>>> # ######################## # Obsolete ? # I don't use these any more # # OO #WITHOUT_JAVA=3D yes #WITHOUT_MOZILLA=3D yes # XMMS #WITHOUT_SKINS=3D yes # mplayer-plugin #WITH_MOZILLA=3D firefox # qemu option #WITH_KQEMU=3D yes # gnash #WITH_FIREFOX=3D yes # mplayer or mplayer-plugin #WITHOUT_SKINS=3D yes # ######################## # added by use.perl PERL_VER=3D5.8.8 PERL_VERSION=3D5.8.8 >=20 >> Wondering if a bug report is warranted? Should it be filed under xcha= t, >> perl, or what? >=20 > Cheers, > \Anton. Also fwiw, % uname -a FreeBSD fangorn.nxdomain.org 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Mon Sep 10 13:47:41 CDT 2007 i386 Thanks for your interest. :) --=20 Regards, Eric --------------enigDFA721CEA6F7939081101D4F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG8SdxngSDRM3IXUoRAr62AKCKvdoRJlprv2zwAm2CrF75Wdx98ACeKQb7 dewnwegOdppwbd4HiEpsJPA= =17R2 -----END PGP SIGNATURE----- --------------enigDFA721CEA6F7939081101D4F-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 14:14:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 459DE16A418 for ; Wed, 19 Sep 2007 14:14:14 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E8CC413C46B for ; Wed, 19 Sep 2007 14:14:13 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IY0JQ-0004yq-Dt for freebsd-current@freebsd.org; Wed, 19 Sep 2007 16:13:56 +0200 Received: from 89-172-41-249.adsl.net.t-com.hr ([89.172.41.249]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Sep 2007 16:13:56 +0200 Received: from ivoras by 89-172-41-249.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Sep 2007 16:13:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 19 Sep 2007 16:13:17 +0200 Lines: 41 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig67FD7D61F81EDE33E473D4B2" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-41-249.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: Encoding in 7-CURRENT (next 7.0). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 14:14:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig67FD7D61F81EDE33E473D4B2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable TooMany Secrets wrote: > Hi! >=20 > I would like to know if the next release (7-RELENG), will come with > the system into utf-8 encoding. > I know that I can put my home, apps, etc, into UTF-8 without problems, > but if I try this with the system, it could be more "dangerous". I don't quite get what you mean by "system into utf-8 encoding". You can have UTF-8 filenames in UFS (and AFAIK almost all other file systems, with exception of msdosfs), and there will be no corruption. Problems you will almost certainly encounter are: - bogus / wrong sorting (FreeBSD's locale data for utf-8 is very lacking)= - the console (text-mode) doesn't support utf-8 so you'll see "garbage" on it - problems with Samba (more) and NFS (less, if the destination system is configured to interpret file names as utf-8). --------------enig67FD7D61F81EDE33E473D4B2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8S59ldnAQVacBcgRAhFNAKCRpY1kCQ6O7zGqh6sTMcOy8sTawQCeJ89H 0pkUgktg2aVKtxH0cOhqoJk= =64Y8 -----END PGP SIGNATURE----- --------------enig67FD7D61F81EDE33E473D4B2-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 15:37:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CA7916A418 for ; Wed, 19 Sep 2007 15:37:07 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop2.sarenet.es (proxypop2.sarenet.es [194.30.0.95]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4AA13C467 for ; Wed, 19 Sep 2007 15:37:07 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop2.sarenet.es (Postfix) with ESMTP id 032087335B for ; Wed, 19 Sep 2007 17:34:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <5870F83F-7174-47AA-98AE-C1DE8972E0C8@SARENET.ES> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Borja Marcos Date: Wed, 19 Sep 2007 17:34:28 +0200 X-Mailer: Apple Mail (2.752.2) Subject: Memory allocation problems (ZFS/NFS/amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 15:37:07 -0000 Hello, I've been doing a test with today's FreeBSD-current, amd64. I've set up a website serving files from a NFS backend. The activity is quite high (the machine has reached 40 Mbps), and I've configured a stripping two disks ZFS filesystem as well, as I intended to do some more tests. However, I have a network problem: Sep 19 17:16:18 server kernel: TCP: [X.Y.Z.T]:14301 to [A.B.C.D]:80; syncache_socket: Socket create failed due to limits or memory shortage Sep 19 17:16:18 server kernel: TCP: [X.Y.Z.T]:14301 to [A.B.C.D]:80 tcpflags 0x18; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST These are not innocuous messages, the machine is rejecting connections like crazy. Any ideas? The number of established TCP connections was around 490, and the machine has 2 GB of RAM. Thanks in advance, Borja. ---------------- "The thing he realised about the windows was this: because they had been converted into openable windows after they had first been designed to be impregnable, they were, in fact, much less secure than if they had been designed as openable windows in the first place." Douglas Adams, "Mostly Harmless" From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 16:03:27 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E60316A46B; Wed, 19 Sep 2007 16:03:26 +0000 (UTC) (envelope-from mux@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C490813C4E8; Wed, 19 Sep 2007 16:03:26 +0000 (UTC) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 1253D1A4D8F; Wed, 19 Sep 2007 08:03:49 -0700 (PDT) Date: Wed, 19 Sep 2007 17:03:49 +0200 From: Maxime Henrion To: Jung-uk Kim Message-ID: <20070919150348.GB73569@elvis.mu.org> References: <200709181516.11207.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709181516.11207.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [PATCH] OsdSynch.c modernization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 16:03:27 -0000 Jung-uk Kim wrote: > I have rewritten sys/dev/acpica/Osd/OsdSynch.c to match the modern > ACPI-CA and -CURRENT: > > http://people.freebsd.org/~jkim/acpica/OsdSynch.diff > > Major changes are: > > 1. Semaphore is reimplemented with convar(9) instead of mutex(9). > > 2. Semaphore with ACPI_WAIT_FOREVER option actually waits forever now. > > 3. Obsolete and/or hidden debugging knobs and macros are removed. > > 4. ACPI-CA introduced AcpiOs*Mutex() to complement AcpiOs*Semaphore(): > > http://bugzilla.kernel.org/show_bug.cgi?id=6634 > > These functions are implemented and turned on by default. > > 5. Spinlock is reimplemented with sx lock and more closely implements > the intended behaviour (e.g., save/restore interrupts). > > It is orthogonal to Nate's effort of rewriting acpi_ec.c but I'd like > get more feedback *with* his last patch (revision D) because his > patch will be committed sooner or later. ;-) > > Please test/review and let us know if there is any regression or not. > > Thanks! Out of curiosity, is there any reason you didn't use the sema(9) API for semaphores and are instead implementing them in terms of mutex/condvar? Cheers, Maxime From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 16:29:05 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A28016A468; Wed, 19 Sep 2007 16:29:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2484A13C4A3; Wed, 19 Sep 2007 16:29:04 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8JGT46M081137; Wed, 19 Sep 2007 12:29:04 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Maxime Henrion Date: Wed, 19 Sep 2007 12:28:58 -0400 User-Agent: KMail/1.6.2 References: <200709181516.11207.jkim@FreeBSD.org> <20070919150348.GB73569@elvis.mu.org> In-Reply-To: <20070919150348.GB73569@elvis.mu.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709191229.00966.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4341/Wed Sep 19 11:11:47 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [PATCH] OsdSynch.c modernization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 16:29:05 -0000 On Wednesday 19 September 2007 11:03 am, Maxime Henrion wrote: > Out of curiosity, is there any reason you didn't use the sema(9) > API for semaphores and are instead implementing them in terms of > mutex/condvar? sema(9) can only increment/decrement value by one while AcpiOs*Semaphore() allows any positive units <= maximum units. Internally ACPI-CA does not use units > 1 but I want it to be more closer to the original intention. In fact, Linux OSD code does not support units > 1. ;-) Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 17:36:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C537116A420 for ; Wed, 19 Sep 2007 17:36:48 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7867113C474 for ; Wed, 19 Sep 2007 17:36:48 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IY3TV-0008OK-Ip for freebsd-current@freebsd.org; Wed, 19 Sep 2007 19:36:33 +0200 Received: from 89-172-41-249.adsl.net.t-com.hr ([89.172.41.249]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Sep 2007 19:36:33 +0200 Received: from ivoras by 89-172-41-249.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Sep 2007 19:36:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 19 Sep 2007 19:35:54 +0200 Lines: 31 Message-ID: References: <5870F83F-7174-47AA-98AE-C1DE8972E0C8@SARENET.ES> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEC29D3A2FD094079644E4143" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-41-249.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <5870F83F-7174-47AA-98AE-C1DE8972E0C8@SARENET.ES> X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: Memory allocation problems (ZFS/NFS/amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 17:36:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC29D3A2FD094079644E4143 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Borja Marcos wrote: > These are not innocuous messages, the machine is rejecting connections > like crazy. Any ideas? > The number of established TCP connections was around 490, and the > machine has 2 GB of RAM. Just a guess: what is your vm.kmem_size_max and have you tried increasing it? --------------enigEC29D3A2FD094079644E4143 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8V4XldnAQVacBcgRApfaAKCnBZF7P7l5aabo+GYsI6FtGr0ZvwCgxtzN i1rXX7x4X0uLQ45aYychydg= =kg4I -----END PGP SIGNATURE----- --------------enigEC29D3A2FD094079644E4143-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 17:48:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0590716A421 for ; Wed, 19 Sep 2007 17:48:23 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id B429613C49D for ; Wed, 19 Sep 2007 17:48:22 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so201204nzf for ; Wed, 19 Sep 2007 10:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=j89xFWYKPEiEV7M8P5wn3Aza3HVaXYVrA6yBC/hPZqA=; b=iaFAC0NLwTd6MPysn+Y3/M4E9eAJwg1Lfg4UwBjta6ckG6IlaTuxmZh69zoFMFAoEWvYU5xXvn/kCeCo6xlTVys5jTPVI3xAdW38rMLxYj10SPQcRQlgcCNBuOXztbk4f1A3OdAtQzfzRcYMsYTSJnDtr2c0SVfKukExB71KUfI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GdDn8643n7EhlyX3XWPG5oXY73sJGNuzH1mnv7twYssk3OLAPrlzYu7Rqyed2FxkQa0pfFi2X20VublW4HGXpM4VFuTDPSAJSUHj1sTxvFQ49zLpqjuBEaqMDxIMLF8kIHl04YklFNk2S2B/UiqwKhMpwwMNhrJktHOML/HMvJQ= Received: by 10.142.201.3 with SMTP id y3mr382670wff.1190224101234; Wed, 19 Sep 2007 10:48:21 -0700 (PDT) Received: by 10.143.165.17 with HTTP; Wed, 19 Sep 2007 10:48:21 -0700 (PDT) Message-ID: <3a142e750709191048m66283f3fu947af91cf4b68e9e@mail.gmail.com> Date: Wed, 19 Sep 2007 17:48:21 +0000 From: "PBM ." To: freebsd-current@freebsd.org In-Reply-To: <20070919131007.GA21833@olymp.home> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3a142e750709190514j61d094bbu68f50d683cd316bd@mail.gmail.com> <20070919131007.GA21833@olymp.home> Subject: Re: wireless support broken on current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 17:48:23 -0000 If rum is somehow broken, system should panic, but is just locks in sbwait state the same thing is with ndis on current for example #ifconfig rum0/ndis0 up #ifconfig rum0/ndis0 scan <- never returns on STABLE it doesnt happen. so if somebody have ndis or rum cards on current I would like to know if it actually works. On 9/19/07, Oliver Herold wrote: > Maybe rum per se is broken. I remember some problems with rum and kernel > panics > in current. I'm using ral at the moment together with a pc-card without any > problems. Current is from today. > > Cheers, Oliver > > On Wed, Sep 19, 2007 at 12:14:48PM +0000, PBM . wrote: > > With both ndis0 and rum0 drivers for two diferent WLAN card I could > > not connect to AP. > > > > # ifconfig ndis0/rum0 scan doesnt give any results, ifconfig stays in > > sbwait state forever. > > > > on 6.2 STABLE ndis0 works fine but there is no rum0 - which is only > > available in CURRENT so it is reason I prefer current. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- > Physically there is nothing to distinguish human society from the > farm-yard except that children are more troublesome and costly than > chickens and women are not so completely enslaved as farm stock. > -- George Bernard Shaw, "Getting Married" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 18:38:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1716116A46C for ; Wed, 19 Sep 2007 18:38:26 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 35C1513C4B3 for ; Wed, 19 Sep 2007 18:38:23 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by wa-out-1112.google.com with SMTP id k17so328552waf for ; Wed, 19 Sep 2007 11:38:23 -0700 (PDT) Received: by 10.115.76.1 with SMTP id d1mr962939wal.1190227103400; Wed, 19 Sep 2007 11:38:23 -0700 (PDT) Received: by 10.114.36.11 with HTTP; Wed, 19 Sep 2007 11:38:23 -0700 (PDT) Message-ID: Date: Wed, 19 Sep 2007 20:38:23 +0200 From: "TooMany Secrets" To: freebsd-current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: Subject: Fwd: Encoding in 7-CURRENT (next 7.0). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 18:38:26 -0000 RXhjdXNlIG1lIHRoaXMgdG9wLXBvc3RpbmcuIElzIG9ubHkgdG8gZ2l2ZSB5b3UgdGhlIG9wcG9y dHVuaXR5IHRvCnJlYWQgYW5kIHRvIGFuc3dlcjsgd2hhdCBpcyB0aGUgYXBwcm9waWF0ZSBsaXN0 IHRvIHRhbGsgYWJvdXQgdGhpcz8KClRoYW5rIHlvdSEKCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1l c3NhZ2UgLS0tLS0tLS0tLQpGcm9tOiBUb29NYW55IFNlY3JldHMgPHRvb21hbnlAdG9vbWFueS5u ZXQ+CkRhdGU6IDE5LXNlcC0yMDA3IDE2OjM4ClN1YmplY3Q6IFJlOiBFbmNvZGluZyBpbiA3LUNV UlJFTlQgKG5leHQgNy4wKS4KVG86IEl2YW4gVm9yYXMgPGl2b3Jhc0BmcmVlYnNkLm9yZz4KCgoy MDA3LzkvMTksIEl2YW4gVm9yYXMgPGl2b3Jhc0BmcmVlYnNkLm9yZz46Cj4gSSBkb24ndCBxdWl0 ZSBnZXQgd2hhdCB5b3UgbWVhbiBieSAic3lzdGVtIGludG8gdXRmLTggZW5jb2RpbmciLiBZb3Ug Y2FuCj4gaGF2ZSBVVEYtOCBmaWxlbmFtZXMgaW4gVUZTIChhbmQgQUZBSUsgYWxtb3N0IGFsbCBv dGhlciBmaWxlIHN5c3RlbXMsCj4gd2l0aCBleGNlcHRpb24gb2YgbXNkb3NmcyksIGFuZCB0aGVy ZSB3aWxsIGJlIG5vIGNvcnJ1cHRpb24uCgpJIGtub3csIGJ1dC4uLgoKPiBQcm9ibGVtcyB5b3Ug d2lsbCBhbG1vc3QgY2VydGFpbmx5IGVuY291bnRlciBhcmU6Cj4gLSBib2d1cyAvIHdyb25nIHNv cnRpbmcgKEZyZWVCU0QncyBsb2NhbGUgZGF0YSBmb3IgdXRmLTggaXMgdmVyeSBsYWNraW5nKQoK T25lIG9mIHRoZW0uLi4KCj4gLSB0aGUgY29uc29sZSAodGV4dC1tb2RlKSBkb2Vzbid0IHN1cHBv cnQgdXRmLTggc28geW91J2xsIHNlZSAiZ2FyYmFnZSIKPiBvbiBpdAoKQW5vdGhlci4uLgoKPiAt IHByb2JsZW1zIHdpdGggU2FtYmEgKG1vcmUpIGFuZCBORlMgKGxlc3MsIGlmIHRoZSBkZXN0aW5h dGlvbiBzeXN0ZW0gaXMKPiBjb25maWd1cmVkIHRvIGludGVycHJldCBmaWxlIG5hbWVzIGFzIHV0 Zi04KS4KCkFub3RoZXIgdW5jb21mb3J0YWJsZSB0aGluay4uLgoKVGhyZWUgb3IgdHdvIHllYXJz IGFnbywgSSB0aGluayB0aGF0IG9uZSAicHJpb3JpdHkiIGluIHRoZSBiaWcgbmV4dApyZWxlYXNl ICg3KSwgd291bGQgYmUgdGhlIFVURi04IHN1cHBvcnQgYXQgd2hvbGUgc3lzdGVtLgpXaHkgZG9u J3QgZW5hYmxlIHN1cHBvcnQgZm9yIHRoaXMgaW4gYWxsIG9wZXJhdGluZyBzeXN0ZW0gKEkgaGF0 ZSB0bwpzYXkgdGhpcyksIGxpa2UgaW4gYW55IGxpbnV4IGRpc3Rybz8gV2FzIG5vdCBvbmUgb2Yg dGhlIGdvYWxzIHRvIGdpdmUKYSBnb29kIHN1cHBvcnQgZm9yIGRlc2t0b3A/IEhvdyBpcyBwb3Nz aWJsZSB0byBtYWtlIHRoaXMgd2l0aG91dAphbnl0aGluZyBsaWtlIHRoZSBzdXBwb3J0IG9mIFVU Ri04IChwbGVhc2UsIG5vdGUgdGhlIHF1b3RhdGlvbiBtYXJrcyk/CgpNYXliZSwgbGlrZSBJIHdh cyBzYXksIEknbSBzYXlpbmcgc29tZXRoaW5nIHN0dXBpZC4gSWYgdGhpcyBpcyB0aHVzLApwbGVh c2UgZXhjdXNlIG1lLgoKVGhhbmsgeW91IHZlcnkgbXVjaC4KCi0tCkhhdmUgYSBuaWNlIGRheSAg Oy0pClRvb01hbnlTZWNyZXRzCgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09CkRpam8gQ29u ZnVjaW86CiJFeMOtZ2V0ZSBtdWNobyBhIHRpIG1pc21vIHkgZXNwZXJhIHBvY28gZGUgbG9zIGRl bcOhcy4gQXPDrSB0ZSBhaG9ycmFyw6FzCmRpc2d1c3Rvcy4iCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KCgotLSAKSGF2ZSBhIG5pY2UgZGF5ICA7LSkKVG9vTWFueVNlY3JldHMKCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KRGlqbyBDb25mdWNpbzoKIkV4w61nZXRlIG11Y2hvIGEg dGkgbWlzbW8geSBlc3BlcmEgcG9jbyBkZSBsb3MgZGVtw6FzLiBBc8OtIHRlIGFob3JyYXLDoXMK ZGlzZ3VzdG9zLiIKPT09PT09PT09PT09PT09PT09PT09PT09PT09PQo= From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 19:00:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC15216A4A7; Wed, 19 Sep 2007 19:00:36 +0000 (UTC) (envelope-from willy@Offermans.Rompen.nl) Received: from hpsmtp-eml15.kpnxchange.com (hpsmtp-eml15.kpnxchange.com [213.75.38.115]) by mx1.freebsd.org (Postfix) with ESMTP id 7002513C4D3; Wed, 19 Sep 2007 19:00:36 +0000 (UTC) (envelope-from willy@Offermans.Rompen.nl) Received: from hpsmtp-eml03.kpnxchange.com ([213.75.38.103]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 20:48:32 +0200 Received: from koko.offrom.nl ([86.82.183.148]) by hpsmtp-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 20:48:31 +0200 Received: from wiz.vpn.offrom.nl (Debian-exim@wiz.vpn.offrom.nl [10.168.0.18]) by koko.offrom.nl (8.13.8/8.13.8) with ESMTP id l8JImHKM036968; Wed, 19 Sep 2007 20:48:17 +0200 (CEST) (envelope-from willy@wiz.vpn.offrom.nl) Received: from willy by wiz.vpn.offrom.nl with local (Exim 4.63) (envelope-from ) id 1IY4b4-0001Ef-C8; Wed, 19 Sep 2007 20:48:26 +0200 Date: Wed, 19 Sep 2007 20:48:26 +0200 From: Willy Offermans To: Sergey Matveychuk Message-ID: <20070919184826.GA3923@wiz.vpn.offrom.nl> References: <200709190919.l8J9JQXl025724@freefall.freebsd.org> <46F0ED85.7060608@yandex.ru> <46F0FC7F.7070304@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F0FC7F.7070304@FreeBSD.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV 0.91.2/4344/Wed Sep 19 18:42:50 2007 on koko.offrom.nl X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on koko.offrom.nl X-OriginalArrivalTime: 19 Sep 2007 18:48:31.0928 (UTC) FILETIME=[ACF50380:01C7FAED] Cc: freebsd-ipfw@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: bin/116458: [ipfw]: Logging problems with syslog and ipfw an 6.2.REL-p5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Willy@Offermans.Rompen.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 19:00:37 -0000 Dear FreeBSD friends, On Wed, Sep 19, 2007 at 02:39:59PM +0400, Sergey Matveychuk wrote: > Andrey V. Elsukov ?????: > >Remko Lodder wrote: > > > > bge0 is running in promisc mode because of dsc which is running. > > > > > > > > sample content of /var/log/messages > > > > Sep 14 12:00:00 ns2 newsyslog[94585]: logfile turned over due to > >size>100K > > > > Sep 14 12:00:02 ns2 kernel: 5 > > > > Sep 14 12:00:05 ns2 kernel: > > > > Sep 14 12:00:05 ns2 kernel: 7 > > > > Sep 14 12:00:08 ns2 kernel: > > > > Sep 14 12:00:08 ns2 kernel: 9 > > > > Sep 14 12:00:11 ns2 kernel: 8 > > > > Sep 14 12:00:14 ns2 kernel: > > > > Sep 14 12:00:14 ns2 kernel: e0 > > > > Sep 14 12:00:15 ns2 kernel: a bge0 > > > > Sep 14 12:00:15 ns2 kernel: e0 > > > > Sep 14 12:00:15 ns2 kernel: < > > > >This problem is not related to the ipfw. But you can try this patch: > >http://people.yandex-team.ru/~sem/FreeBSD/kernel/log_mutex.diff > > > >Please, report back if it will help you. > > > > The same patch is in kern/116310. > I have the same problem as well. I have noted it for at least 6 -- 12 months now, but I was too lazy to mention it. I will try the patch as well. Lets see what will happen. Sep 11 23:37:46 rose kernel: <11C>ipfw: 600 Accept TCP 10.X.X.2:445 10.X.X.54:1032 out via tap0 Sep 11 23:37:47 rose kernel: 1032 out via tap0 Sep 11 23:37:48 rose kernel: t via tap0 Sep 11 23:37:48 rose kernel: in via tap0 Sep 11 23:37:49 rose kernel: via tap0 Sep 11 23:37:49 rose kernel: v Sep 11 23:37:49 rose kernel: via tap0 Sep 11 23:37:49 rose kernel: 00 Accept TCP 10.X.X.2:445 10.X.X.54:1032 out via tap0 Sep 11 23:37:49 rose kernel: t via tap0 Sep 11 23:37:50 rose last message repeated 2 times Sep 11 23:37:50 rose kernel: n via tap0 Sep 11 23:37:51 rose kernel: via tap0 Sep 11 23:37:51 rose kernel: t via tap0 Sep 11 23:37:52 rose last message repeated 7 times Sep 11 23:37:52 rose kernel: TCP 10.X.X.2:445 10.X.X.54:1032 out via tap0 Sep 11 23:37:52 rose kernel: ipfw: limit 100000 reached on entry 600 -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 653 27 16 23 e-mail: Willy@Offermans.Rompen.nl Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 21:54:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC13316A417 for ; Wed, 19 Sep 2007 21:54:58 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9F913C45A for ; Wed, 19 Sep 2007 21:54:58 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so226038wxd for ; Wed, 19 Sep 2007 14:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=p2hrMn7lJmpotocTRqpi6JNKIKiRU8jfM0bZF/aXjKg=; b=jOTNUm0w6M7jIZAhRQTiJ/Uvx1Jvbnqsz4JV2ABR95/wouymG9yda/DBUO1QQmUe8n5yA/n6T64oEAD5R0jiesjgdeWN9z9EW6QAwWt7g6v4rKe/u5zpGTAMsowX3eQUURU3yIs3Ofv7BWubTANF/Urb91tr1fAp68hXV7kejiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZflFrWgaxJ9id0CHqOzyM64TOj3UHBlqfFtFIyWN96agUUysAkl3yxhLJAyZ+y+Rg+DFEcUaf85hcaWMPbGve4l8zLREcmqVd2UBx8zkK/HEfxOX57R5/VZVhlKBQfQPjcZH7+a8hL4oL1aMRG8cnFJA7ozc5fRvJc6T83EMRPY= Received: by 10.90.81.14 with SMTP id e14mr955519agb.1190237437535; Wed, 19 Sep 2007 14:30:37 -0700 (PDT) Received: by 10.90.106.19 with HTTP; Wed, 19 Sep 2007 14:30:37 -0700 (PDT) Message-ID: Date: Wed, 19 Sep 2007 16:30:37 -0500 From: Matt To: "Matt Olander" In-Reply-To: <200709041048.41892.matt@ixsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200709041048.41892.matt@ixsystems.com> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Ivan Voras , Jeremy Messenger Subject: Re: VirtualBox? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 21:54:58 -0000 On 9/4/07, Matt Olander wrote: > On Tuesday 04 September 2007 8:27 am, Jeremy Messenger wrote: > > On Tue, 04 Sep 2007 08:33:50 -0500, Ivan Voras wrote: > > > Hi, > > > > > > Is anyone working on porting VirtualBox? > > > > > > http://www.virtualbox.org/wiki/Porting_VirtualBox > > > > > > It mentions FreeBSD but nothing conclusive. It should be easier than > > > VMWare :) > > > > http://www.virtualbox.org/wiki/VBox_vs_Others (see in host box) > > http://www.virtualbox.org/wiki/FreeBSD%20build%20instructions > > http://www.virtualbox.org/search?q=freebsd&wiki=on&changeset=on&ticket=on > > > > It looks like they are working on it. > > I spoke with a couple of their devs on Freenode and while they are willing to > assist contributors porting to FreeBSD, they are not actively working on it > themselves. Their response to my inquiry was "check out source and start > porting!" > > A few of their devs hang out in #vbox-dev on Freenode. This would be an > excellent port for FreeBSD. > > best, > -matt > > -- I agree that this would be an excellent addition to the FreeBSD toolset. We use it on several Linux and Windows host machines and it is quite good. There has been some additional porting work of late and the VirtualBox devs have been quick to import suggestions into their subversion tree. The result is that VirtualBox now builds successfully on FreeBSD version 6.2 and 7-CURRENT with only minor patches (and those should hopefully go away soon too). However, the kernel driver (and some other things too) are missing and need additional work. Is there anyone here capable of helping with that effort? Regards, Matt From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 22:13:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBA1716A468 for ; Wed, 19 Sep 2007 22:13:18 +0000 (UTC) (envelope-from freebsd-current@adam.gs) Received: from mail.adam.gs (mail.adam.gs [76.9.2.116]) by mx1.freebsd.org (Postfix) with ESMTP id A6D7013C457 for ; Wed, 19 Sep 2007 22:13:18 +0000 (UTC) (envelope-from freebsd-current@adam.gs) Received: from [127.0.0.1] (localhost.adam.gs [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id A1193F35559 for ; Wed, 19 Sep 2007 18:13:17 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mail; d=adam.gs; b=g12tepADcbruTeI1I6KrKEOxhio5fYvsz2o5rIog4oCkASZ5cCBl7lUoLtZvsQJgCam7EPeU0LjofEhYi0eeyvzQihFwpLsV6F+5i0QkzBuKeB9wk3BSXYB8fzOsJL6JQJbBhbDKi9DJrXYOKqyekj4cuAqGLGjLNnK5TjKrAiw=; Received: from [66.230.128.46] (unknown [66.230.128.46]) (Authenticated sender: adam@adam.gs) by mail.adam.gs (Postfix) with ESMTP id 4DECDF35417; Wed, 19 Sep 2007 18:13:17 -0400 (EDT) In-Reply-To: <20070919082551.GS55051@obelix.dsto.defence.gov.au> References: <20070919082551.GS55051@obelix.dsto.defence.gov.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Adam Jacob Muller Date: Wed, 19 Sep 2007 18:13:15 -0400 To: "Wilkinson, Alex" X-Mailer: Apple Mail (2.752.3) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS pool not working on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 22:13:18 -0000 On Sep 19, 2007, at 4:25 AM, Wilkinson, Alex wrote: > 0n Wed, Sep 19, 2007 at 03:24:25AM -0400, Adam Jacob Muller wrote: > >> I have a server with two ZFS pools, one is an internal raid0 using >> 2 drives >> connected via ahc. The other is an external storage array with 11 >> drives >> also using ahc, using raidz. (This is a dell 1650 and pv220s). >> On reboot, the pools do not come online on their own. Both pools >> consistently show as failed. > > Make sure your hostid doesn't change. If it does. Then ZFS will > fail upon bootstrap. > > -aW > No, The hostid is not changing, just rebooted and replicated the problem. Also it seems like from reading ZFS docs that the symptoms would be that the pool would simply need to be imported again if the host id changed? after another reboot, I see this: # zpool status pool: tank state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-D3 scrub: none requested config: NAME STATE READ WRITE CKSUM tank UNAVAIL 0 0 0 insufficient replicas da1 ONLINE 0 0 0 da2 UNAVAIL 0 0 0 cannot open ... more output showing the other array with 11 drives is fine # zpool export tank # zpool import tank # zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 errors: No known data errors (11-drive raidz is fine still of course) From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 22:58:04 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84F1516A420; Wed, 19 Sep 2007 22:58:04 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id EE83713C461; Wed, 19 Sep 2007 22:58:03 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l8JMwCiR027243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2007 02:58:14 +0400 Message-ID: <46F1A96F.2040602@FreeBSD.org> Date: Wed, 19 Sep 2007 18:57:51 -0400 From: "Constantine A. Murenin" Organization: Google Summer of Code 2007 Student @ The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: Doug Barton References: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> <46E9FC0C.70607@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , Shteryana Shopova , freebsd-current@FreeBSD.org, "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 22:58:04 -0000 On 19/09/2007 01:13, Doug Barton wrote: > On Thu, 13 Sep 2007, Constantine A. Murenin wrote: > >> Dear freebsd-{arch,current,hackers}@, >> >> On this 256th day of 2007, it is my great pleasure to announce the >> completion of my GSoC2007 project on porting the sysctl hardware >> sensors framework from OpenBSD to FreeBSD. > > > This works great on my C2D: > > hw.sensors.cpu0.temp0: 79.00 degC > hw.sensors.cpu1.temp0: 82.00 degC > > Sensor Value Status Description > cpu0.temp0 82.00 degC > cpu1.temp0 84.00 degC > > (the temp went up because I was compiling something). Thanks for testing! > Two small comments about the rc.d stuff. First, the empty _flags > variable in defaults/rc.conf should be commented out. Second, the rc.d How so? I don't see any other empty _flags variables in defaults/rc.conf being commented out. > script needs the shutdown KEYWORD. Similarly, I don't see why this is needed -- it was not used by the scripts on which this script was based on (the history is in p4). Reading through rc(8) doesn't seem to suggest that this keyword would actually be applicable here. Cheers, Constnatine. From owner-freebsd-current@FreeBSD.ORG Wed Sep 19 23:01:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D688316A417; Wed, 19 Sep 2007 23:01:43 +0000 (UTC) (envelope-from acd@acd.homelinux.org) Received: from server0.acapsecurity.com (acapsecurity.com [207.38.28.204]) by mx1.freebsd.org (Postfix) with ESMTP id B2E5813C459; Wed, 19 Sep 2007 23:01:43 +0000 (UTC) (envelope-from acd@acd.homelinux.org) Received: from acd.homelinux.org (unknown [10.0.15.5]) by server0.acapsecurity.com (Postfix) with ESMTP id 63B4822B6E; Wed, 19 Sep 2007 15:44:50 -0700 (PDT) Received: by acd.homelinux.org (Postfix, from userid 500) id C86593051; Wed, 19 Sep 2007 16:44:49 -0600 (MDT) From: Axel To: Adam Jacob Muller References: Date: Wed, 19 Sep 2007 16:44:49 -0600 In-Reply-To: (Adam Jacob Muller's message of "Wed\, 19 Sep 2007 03\:24\:25 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS pool not working on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 23:01:44 -0000 Adam Jacob Muller writes: > Hello, > I have a server with two ZFS pools, one is an internal raid0 using 2 > drives connected via ahc. The other is an external storage array with > 11 drives also using ahc, using raidz. (This is a dell 1650 and > pv220s). > On reboot, the pools do not come online on their own. Both pools > consistently show as failed. > > the exact symptoms vary, however I have seen that many drives are > marked as variously "corrupt" or "unavailable" most zpool operations > fail with "pool is unavailable" errors. > > Here is the interesting part. > Consistently, 100% of the time, a zpool export followed by a zpool > import restores the arrays to an ONLINE status. Once the array is > online, it's quite stable (I'm loving ZFS btw, thank you to everyone > for the hard work on this, ZFS is fantastic) and works great. > > Anyone have any ideas why this might occur and what/if the solution is? > > Any additional information can be provided on-request, I am running > current from approximately 1 week ago. > > -Adam > There is a file called /boot/zfs/zpool.cache that is kept in sync and loaded at boot time. If that's not there , e.g. by your /boot pointing to it , you're hosed. -- Axel From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 00:06:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10B7416A46E for ; Thu, 20 Sep 2007 00:06:27 +0000 (UTC) (envelope-from freebsd-current@adam.gs) Received: from mail.adam.gs (mail.adam.gs [76.9.2.116]) by mx1.freebsd.org (Postfix) with ESMTP id 7D03813C474 for ; Thu, 20 Sep 2007 00:05:06 +0000 (UTC) (envelope-from freebsd-current@adam.gs) Received: from [127.0.0.1] (localhost.adam.gs [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id 841B8F3555A for ; Wed, 19 Sep 2007 20:05:05 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mail; d=adam.gs; b=NEy9YKYaYlgk2TZgeEzPpYect3WVDhkhbu5ZWRP8sUgsCh70Uz9OCrSmHa9YP+DEhvpnmY2VS8MrHWBJOQ09L919QaSDQS3/6MyoUx+KzaWMpyzgYTuyJZs6V7SPR1FryYwlK1tHI5/iRkyT4IW3S+5jabG6Ek/T4ZyFp4ix11Q=; Received: from [66.230.128.46] (unknown [66.230.128.46]) (Authenticated sender: adam@adam.gs) by mail.adam.gs (Postfix) with ESMTP id 49949F35385; Wed, 19 Sep 2007 20:05:05 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Adam Jacob Muller Date: Wed, 19 Sep 2007 20:05:03 -0400 To: Axel X-Mailer: Apple Mail (2.752.3) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS pool not working on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 00:06:27 -0000 On Sep 19, 2007, at 6:44 PM, Axel wrote: > Adam Jacob Muller writes: > >> Hello, >> I have a server with two ZFS pools, one is an internal raid0 using 2 >> drives connected via ahc. The other is an external storage array with >> 11 drives also using ahc, using raidz. (This is a dell 1650 and >> pv220s). >> On reboot, the pools do not come online on their own. Both pools >> consistently show as failed. >> >> the exact symptoms vary, however I have seen that many drives are >> marked as variously "corrupt" or "unavailable" most zpool operations >> fail with "pool is unavailable" errors. >> >> Here is the interesting part. >> Consistently, 100% of the time, a zpool export followed by a zpool >> import restores the arrays to an ONLINE status. Once the array is >> online, it's quite stable (I'm loving ZFS btw, thank you to everyone >> for the hard work on this, ZFS is fantastic) and works great. >> >> Anyone have any ideas why this might occur and what/if the >> solution is? >> >> Any additional information can be provided on-request, I am running >> current from approximately 1 week ago. >> >> -Adam >> > > There is a file called /boot/zfs/zpool.cache that is kept in sync > and loaded at boot time. > > If that's not there , e.g. by your /boot pointing to it , you're > hosed. > File is there, of note is that some of the prior reboots had been "unintentional" reboots, so it is possible that that file was corrupt, however, it does not seem correct for zfs to come up in a state that shows drives as corrupted and/or unavailable. I believe I have corrected the crashing issue, however it still does not seem that this is the correct behavior. - Adam From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 06:32:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 955E316A41B; Thu, 20 Sep 2007 06:32:25 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.freebsd.org (Postfix) with ESMTP id 3F74613C428; Thu, 20 Sep 2007 06:32:25 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.232.62]) by natial.ongs.co.jp (Postfix) with ESMTP id CC5EE244C19; Thu, 20 Sep 2007 15:32:23 +0900 (JST) Message-ID: <46F213F7.3060802@ongs.co.jp> Date: Thu, 20 Sep 2007 15:32:23 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: Kurt Jaeger , emaste@freebsd.org References: <200709141103.18612.h.schmalzbauer@omnisec.de> <20070914110024.G14481@fledge.watson.org> <46EBEA18.3080800@ongs.co.jp> <20070915170104.GF2061@home.c0mplx.org> <46EF6386.9050700@ongs.co.jp> <20070919021644.GG2061@home.c0mplx.org> In-Reply-To: <20070919021644.GG2061@home.c0mplx.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Unionfs patchset p19 commit? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 06:32:25 -0000 Kurt Jaeger wrote: > Hi! > >>>> I have a big hope to get merged into FreeBSD until >>>> 7-RELEASE. Progress is step by step slowly, but going >>>> forward absolutely. If you have interest in unionfs >>>> improvements, push your passion to re@ and fs@ committers ;-) >>> Did you have a chance to look into this ? >>> >>> http://lists.freebsd.org/pipermail/freebsd-stable/2007-June/035798.html > >> Already we have fixed above issue. > [...] > > I'm compiling this patch on my test system right now. > > Another issue is userland support for unionfs, e.g. in fstat, > as described on this page: > > http://c0mplx.org/src/fstat-unionfs-patch/ > > Do you plan to analyse/investigate this topic ? It looks like interesting. But your patch has a issues. + /* fprintf(stderr,"found upper vnode\n"); */ + res = ufs_filestat(&upper, fsp); and + /* fprintf(stderr,"found lower vnode\n"); */ + res = ufs_filestat(&lower, fsp); depend on UFS. It must treat both UFS and no UFS fs. And I am not a maintainer of fstat(1). Please contact to maintainer. Perhaps Ed Maste(emaste) is maintainer I suppose from commit log. > There's another topic if one uses unionfs in jail() setups: How to > backup the files, and only those files that a different from > the base ? > > If I traverse a mounted unionfs, how do I know where data is coming > from, the lower mount or the higher mount ? > > If I can't tell the difference, I'll backup quite a lot of stuff > multiple times. > > I've experimented a little and found no easy way to tell lower > from upper unless I open the file (which sounds expensive). > Have a look at http://c0mplx.org/src/isunionfs.c -- does this > sound like a way to go ? The isunionfs.c looks like interesting, too :) But your program is not complete. 'below' option gives it non-correct work. Addition it does not consider unionfs and nullfs combibation or something like that. To check upper/lower completely, you need the same way of your fstat(1) patch. But your idea looks interesting :) Keep your concern of unionfs. To get keep concern is very good for us! -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 06:58:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FF9D16A41A for ; Thu, 20 Sep 2007 06:58:40 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.188]) by mx1.freebsd.org (Postfix) with ESMTP id A17BB13C469 for ; Thu, 20 Sep 2007 06:58:39 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so489228mue for ; Wed, 19 Sep 2007 23:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=R4Plpww4tlfC9NvayZDPlKIvvN5L0CjUxSuR/C9wL8k=; b=g5hT1qFfxNs7x0amSgGs7bKHXqdqPUV/dvy6lXwIl1NRMyRIh5DKJhzQon6wucSe/7RxNYrfL+g+8DAXCy+7A16eLJ12chibHJoqebskp1fbIWPyfSx0mLuEUFO43+xwlsTwOnVjoPkR0UXEz94MLCmpeIOstcA4TN4VIZMGdK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c24cQrBJH1s8froVzJCE5z9o8dQsKr+pCSEvQOvoO2/qcQ/hIGCYDErao6Ibg2dwNhX49Da72u5h2+aEhuVcucVVhDMb4Ck9ECyA8gn0G2+6zjTmfHLtbrhJsRSfuFD6T7n6RMZ1Qh/9NlhjsmQELL1aox/pF459ry5r9wFOGBc= Received: by 10.86.100.7 with SMTP id x7mr1143892fgb.1190271496306; Wed, 19 Sep 2007 23:58:16 -0700 (PDT) Received: by 10.86.71.6 with HTTP; Wed, 19 Sep 2007 23:58:16 -0700 (PDT) Message-ID: <790a9fff0709192358kdafac61i7a8c705f776a22b@mail.gmail.com> Date: Thu, 20 Sep 2007 01:58:16 -0500 From: "Scot Hetzel" To: "PBM ." In-Reply-To: <3a142e750709191048m66283f3fu947af91cf4b68e9e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3a142e750709190514j61d094bbu68f50d683cd316bd@mail.gmail.com> <20070919131007.GA21833@olymp.home> <3a142e750709191048m66283f3fu947af91cf4b68e9e@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: wireless support broken on current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 06:58:40 -0000 On 9/19/07, PBM . wrote: > If rum is somehow broken, system should panic, but is just locks in > sbwait state the same thing is with ndis on current > > for example > > #ifconfig rum0/ndis0 up > #ifconfig rum0/ndis0 scan <- never returns > > on STABLE it doesnt happen. > > so if somebody have ndis or rum cards on current I would like to know > if it actually works. On -CURRENT (FreeBSD/amd64) that was updated about an hour ago, I have no major problem using ifconfig ndis0 scan. The first time it is used it will return with a lock order reversal error, but it will show the list of APs. I am able to run the scan a second time with out getting this error. Scot From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 07:01:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E110516A418 for ; Thu, 20 Sep 2007 07:01:40 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop1.sarenet.es (proxypop1.sarenet.es [194.30.0.99]) by mx1.freebsd.org (Postfix) with ESMTP id 8BAA613C459 for ; Thu, 20 Sep 2007 07:01:40 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop1.sarenet.es (Postfix) with ESMTP id EE3A75C34; Thu, 20 Sep 2007 09:01:15 +0200 (CEST) In-Reply-To: References: <5870F83F-7174-47AA-98AE-C1DE8972E0C8@SARENET.ES> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <613318C3-6B66-4758-A0D4-97405D6A1914@SARENET.ES> Content-Transfer-Encoding: 7bit From: Borja Marcos Date: Thu, 20 Sep 2007 09:01:21 +0200 To: Ivan Voras X-Mailer: Apple Mail (2.752.2) Cc: freebsd-current@freebsd.org Subject: Re: Memory allocation problems (ZFS/NFS/amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 07:01:41 -0000 On 19 Sep 2007, at 19:35, Ivan Voras wrote: > Borja Marcos wrote: > >> These are not innocuous messages, the machine is rejecting >> connections >> like crazy. Any ideas? >> The number of established TCP connections was around 490, and the >> machine has 2 GB of RAM. > > Just a guess: what is your vm.kmem_size_max and have you tried > increasing it? It's the first thing I thought, and I cranked it to a very high value just in case: vm.kmem_size_max: 1073741824 It didn't help. Any ideas? The ZFS filesystem was mounted but it had absolutely no activity at that point. It was just Apache 2.2 serving files coming from a NFS-mounted filesystem. Borja. ---------------- "The thing he realised about the windows was this: because they had been converted into openable windows after they had first been designed to be impregnable, they were, in fact, much less secure than if they had been designed as openable windows in the first place." Douglas Adams, "Mostly Harmless" From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 02:39:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB61F16A421; Thu, 20 Sep 2007 02:39:13 +0000 (UTC) (envelope-from acd@acd.homelinux.org) Received: from server0.acapsecurity.com (acapsecurity.com [207.38.28.204]) by mx1.freebsd.org (Postfix) with ESMTP id 96BA513C45E; Thu, 20 Sep 2007 02:39:13 +0000 (UTC) (envelope-from acd@acd.homelinux.org) Received: from acd.homelinux.org (unknown [10.0.15.5]) by server0.acapsecurity.com (Postfix) with ESMTP id 310FB22B6E; Wed, 19 Sep 2007 19:39:12 -0700 (PDT) Received: by acd.homelinux.org (Postfix, from userid 500) id 551D43086; Wed, 19 Sep 2007 20:39:12 -0600 (MDT) From: Axel To: Adam Jacob Muller References: Date: Wed, 19 Sep 2007 20:39:11 -0600 In-Reply-To: (Adam Jacob Muller's message of "Wed\, 19 Sep 2007 20\:05\:03 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 20 Sep 2007 07:17:13 +0000 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS pool not working on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 02:39:13 -0000 Adam Jacob Muller writes: > On Sep 19, 2007, at 6:44 PM, Axel wrote: > >> There is a file called /boot/zfs/zpool.cache that is kept in sync >> and loaded at boot time. >> >> If that's not there , e.g. by your /boot pointing to it , you're >> hosed. >> > > File is there, of note is that some of the prior reboots had been > "unintentional" reboots, so it is possible that that file was > corrupt, however, it does not seem correct for zfs to come up in a > state that shows drives as corrupted and/or unavailable. I believe I > have corrected the crashing issue, however it still does not seem > that this is the correct behavior. > > - Adam > If you have a working root outside of zfs I'd do the following: 1) Rename the zpool.cache to something else to be safe 2) Reboot, make sure that /boot/zfs points to the right location, and reimport the pools. 3) Should be fine from there on. I had sort of the same issue, the zpool.cache isn't documented too well yet; I only stumbled over it by doing a "lsmod" at the loader prompt;it's one reason root can be on zfs before hostid is set. If you setup zfs and don't have the future /boot/zfs set right it won't work because the information gets lost. With / on zfs it's crucial to have /boot point to the actual UFS boot partition and not be in your zfs / somewhere, cause that gets ignored until it's mounted. It's a good idea to keep the actual old UFS / directory around although only /boot gets used in there if you mount / from zfs. http://wiki.freebsd.org/ZFS comes in handy. And yes, I do love zfs too :-) -- Axel From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 08:30:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44E1D16A419 for ; Thu, 20 Sep 2007 08:30:02 +0000 (UTC) (envelope-from daffy@xview.net) Received: from mail.oav.net (mail.oav.net [193.218.105.18]) by mx1.freebsd.org (Postfix) with ESMTP id E8C9713C48A for ; Thu, 20 Sep 2007 08:30:01 +0000 (UTC) (envelope-from daffy@xview.net) Received: from localhost (localhost [127.0.0.1]) by mail02.oav.net (Postfix) with ESMTP id 951D63F43E for ; Thu, 20 Sep 2007 10:13:58 +0200 (CEST) (envelope-from daffy@xview.net) X-Virus-Scanned: by amavisd-new at mail02.oav.net Received: from mail02.oav.net ([127.0.0.1]) by localhost (mail02.oav.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 7p9onF1-Pzcs for ; Thu, 20 Sep 2007 10:13:58 +0200 (CEST) Received: from [10.7.1.109] (unknown [80.11.182.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail02.oav.net (Postfix) with ESMTP id 25D203F447 for ; Thu, 20 Sep 2007 10:13:58 +0200 (CEST) (envelope-from daffy@xview.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Olivier Warin Date: Wed, 19 Sep 2007 23:34:19 +0200 X-Mailer: Apple Mail (2.752.3) Subject: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 08:30:02 -0000 Hi, I recently wanted to give dtrace on FreeBSD a try but found this project to be stopped due to a licensing issue. Will we see dtrace in the base just like zfs anytime (hopefully) soon ? Best regards, /Olivier -- Olivier Warin From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 08:32:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97C7F16A417 for ; Thu, 20 Sep 2007 08:32:34 +0000 (UTC) (envelope-from wike1985@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 5821D13C459 for ; Thu, 20 Sep 2007 08:32:34 +0000 (UTC) (envelope-from wike1985@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so382330rvb for ; Thu, 20 Sep 2007 01:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=kZPULubsB8B+XlzCgf1r1uV1N+fueAm7DE+wfFqrHpk=; b=HKn+Tzp76c24jM4fjfBQ+sm1KWwMp7WtrCEmy/DgEkt+4n9PkJC1xpyvePimbSTuuf+fa7Z30jja0iERg7aGcxV+D1XSOBcNL9U4kkluBjdmBN+c58LqJBS2/IQF8hO81nrwd/0z6eR3fVtXEcUvLYgcMZnaAhE6XjqnTSyWZfI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VUJvyC/Y/xMt3TAJHnTanS3JN00Ijb1alxgYzB8ik1CcSXLBWxcTMvl7/lOqlG8pQlPPKDmoATtxSV3U25GpAW8R7/tF02KQT6zrChyq0PCU3JxAnSX9ElRjYQnmIDit2Aue2V0S3W48kYHh4i6xxS656qdh/xxVvP2QkwVVzjM= Received: by 10.140.193.16 with SMTP id q16mr410078rvf.1190275659780; Thu, 20 Sep 2007 01:07:39 -0700 (PDT) Received: by 10.140.178.4 with HTTP; Thu, 20 Sep 2007 01:07:39 -0700 (PDT) Message-ID: Date: Thu, 20 Sep 2007 08:07:39 +0000 From: "Gawain Bai" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Firefox make some sound like bell X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 08:32:34 -0000 I have update firefox to 2.0.0.7 about 3 hour ago, but I hair some sound like bell when firefox start and runing. why? and I have got some message like this when execute firefox -h Type Manifest File: /usr/local/lib/firefox/components/xpti.dat ###!!! ASSERTION: Failed to write xpti manifest!: 'Error', file xptiInterfaceInfoManager.cpp, line 1937 Break: at file xptiInterfaceInfoManager.cpp, line 1937 *** Registering Apprunner components (all right -- a generic module!) nsNativeComponentLoader: autoregistering begins. nsNativeComponentLoader: autoregistering succeeded ###!!! ASSERTION: Failed to write xpti manifest!: 'Error', file xptiInterfaceInfoManager.cpp, line 1937 Break: at file xptiInterfaceInfoManager.cpp, line 1937 nsNativeComponentLoader: registering deferred (0) -jsconsole Open the Error console. -browser Open a browser window. -inspector Open the DOM inspector. Usage: firefox [-flags] [] WARNING: nsExceptionService ignoring thread destruction after shutdown, file nsExceptionService.cpp, line 191 WARNING: No event queue listener?, file nsEventQueue.cpp, line 79 Could not write out perisistant registry! nsStringStats => mAllocCount: 5064 => mReallocCount: 943 => mFreeCount: 5064 => mShareCount: 5426 => mAdoptCount: 191 => mAdoptFreeCount: 190 -- LEAKED 1 !!! my system informations: FreeBSD local.khsing.net 7.0-CURRENT FreeBSD 7.0-CURRENT #7: Thu Sep 13 12:47:13 UTC 2007 root@local.khsing.net:/usr/obj/usr/src/sys/D600 i386 -- _______________________________________ Mr. Gawain Bai, PinYin: Guixing Bai, Wade-Giles: Kueihsing Pai Email: wike1985_AT_gmail_DOT_com blog: http://cnwike.blogspot.com this for work http://blog.donews.com/kueihsing this for study. give me free or give me death. From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 08:37:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CA8616A41B; Thu, 20 Sep 2007 08:37:59 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 5621C13C49D; Thu, 20 Sep 2007 08:37:58 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F23166.8070908@FreeBSD.org> Date: Thu, 20 Sep 2007 10:37:58 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Borja Marcos References: <5870F83F-7174-47AA-98AE-C1DE8972E0C8@SARENET.ES> <613318C3-6B66-4758-A0D4-97405D6A1914@SARENET.ES> In-Reply-To: <613318C3-6B66-4758-A0D4-97405D6A1914@SARENET.ES> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Memory allocation problems (ZFS/NFS/amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 08:37:59 -0000 Borja Marcos wrote: > > On 19 Sep 2007, at 19:35, Ivan Voras wrote: > >> Borja Marcos wrote: >> >>> These are not innocuous messages, the machine is rejecting connections >>> like crazy. Any ideas? >>> The number of established TCP connections was around 490, and the >>> machine has 2 GB of RAM. >> >> Just a guess: what is your vm.kmem_size_max and have you tried >> increasing it? > > It's the first thing I thought, and I cranked it to a very high value > just in case: > > vm.kmem_size_max: 1073741824 You actually wanted to tune vm.kmem_size too or it may not actually change the value used (_max is just a ceiling for autotuning). However if this is i386 you can't set it that high without also adjusting KVA_PAGES too (which has other effects). Kris From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 09:05:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4006E16A420; Thu, 20 Sep 2007 09:05:30 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop1.sarenet.es (proxypop1.sarenet.es [194.30.0.99]) by mx1.freebsd.org (Postfix) with ESMTP id C4AE013C4A7; Thu, 20 Sep 2007 09:05:29 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop1.sarenet.es (Postfix) with ESMTP id 0E8665D77; Thu, 20 Sep 2007 11:05:26 +0200 (CEST) In-Reply-To: <46F23166.8070908@FreeBSD.org> References: <5870F83F-7174-47AA-98AE-C1DE8972E0C8@SARENET.ES> <613318C3-6B66-4758-A0D4-97405D6A1914@SARENET.ES> <46F23166.8070908@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Borja Marcos Date: Thu, 20 Sep 2007 11:05:30 +0200 To: Kris Kennaway X-Mailer: Apple Mail (2.752.2) Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Memory allocation problems (ZFS/NFS/amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 09:05:30 -0000 On 20 Sep 2007, at 10:37, Kris Kennaway wrote: > Borja Marcos wrote: >> On 19 Sep 2007, at 19:35, Ivan Voras wrote: >>> Borja Marcos wrote: >>> >>>> These are not innocuous messages, the machine is rejecting >>>> connections >>>> like crazy. Any ideas? >>>> The number of established TCP connections was around 490, and the >>>> machine has 2 GB of RAM. >>> >>> Just a guess: what is your vm.kmem_size_max and have you tried >>> increasing it? >> It's the first thing I thought, and I cranked it to a very high >> value just in case: >> vm.kmem_size_max: 1073741824 > > You actually wanted to tune vm.kmem_size too or it may not actually > change the value used (_max is just a ceiling for autotuning). > However if this is i386 you can't set it that high without also > adjusting KVA_PAGES too (which has other effects). It's an amd64. I understand that i386 is mostly out of the question if I want to play reasonably safe with ZFS :) Oh, ok. I will try with both, then. Should I try the same value? Perhaps it's a bit high, but I understand that with a 64 bit address space I can set it sort of arbitrarily high without many side effects. Thank you very much, Borja. ---------------- "The thing he realised about the windows was this: because they had been converted into openable windows after they had first been designed to be impregnable, they were, in fact, much less secure than if they had been designed as openable windows in the first place." Douglas Adams, "Mostly Harmless" From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 21:01:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 483E616A41B; Thu, 20 Sep 2007 21:01:22 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 468A813C468; Thu, 20 Sep 2007 21:01:21 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F2DFA1.6080709@FreeBSD.org> Date: Thu, 20 Sep 2007 23:01:21 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Borja Marcos References: <5870F83F-7174-47AA-98AE-C1DE8972E0C8@SARENET.ES> <613318C3-6B66-4758-A0D4-97405D6A1914@SARENET.ES> <46F23166.8070908@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Memory allocation problems (ZFS/NFS/amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:01:22 -0000 Borja Marcos wrote: > > On 20 Sep 2007, at 10:37, Kris Kennaway wrote: > >> Borja Marcos wrote: >>> On 19 Sep 2007, at 19:35, Ivan Voras wrote: >>>> Borja Marcos wrote: >>>> >>>>> These are not innocuous messages, the machine is rejecting connections >>>>> like crazy. Any ideas? >>>>> The number of established TCP connections was around 490, and the >>>>> machine has 2 GB of RAM. >>>> >>>> Just a guess: what is your vm.kmem_size_max and have you tried >>>> increasing it? >>> It's the first thing I thought, and I cranked it to a very high value >>> just in case: >>> vm.kmem_size_max: 1073741824 >> >> You actually wanted to tune vm.kmem_size too or it may not actually >> change the value used (_max is just a ceiling for autotuning). >> However if this is i386 you can't set it that high without also >> adjusting KVA_PAGES too (which has other effects). > > It's an amd64. I understand that i386 is mostly out of the question if I > want to play reasonably safe with ZFS :) > > Oh, ok. I will try with both, then. Should I try the same value? Perhaps > it's a bit high, but I understand that with a 64 bit address space I can > set it sort of arbitrarily high without many side effects. Yes, you should set them both to the same value. Kris From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 21:04:29 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96CB516A41A; Thu, 20 Sep 2007 21:04:29 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id E26FB13C461; Thu, 20 Sep 2007 21:04:28 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l8KIgHDN021729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Sep 2007 21:42:31 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l8KIg1lf072957; Thu, 20 Sep 2007 21:42:16 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l8KIg1mr072948; Thu, 20 Sep 2007 21:42:01 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Thu, 20 Sep 2007 21:42:01 +0300 From: Giorgos Keramidas To: Colin Percival Message-ID: <20070920184201.GA72805@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.095, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.30, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@FreeBSD.org Subject: portsnap snapshot corruption? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:04:29 -0000 Hi Colin, I've tried removing all of /var/db/portsnap/* and refetching several times today, but all the attempts resulted in corrupt snapshots, like this one: % root@kobe:/root# rm -fr /var/db/portsnap/* % root@kobe:/root# portsnap fetch % Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. % Fetching public key from portsnap3.FreeBSD.org... done. % Fetching snapshot tag from portsnap3.FreeBSD.org... done. % Fetching snapshot metadata... done. % Fetching snapshot generated at Thu Sep 20 04:07:10 EEST 2007: % 1a2086f1a8eea72b21ecc5c6a03587a26e3b86055bc54a100% of 49 MB 1451 kBps 00m00s % Extracting snapshot... done. % Verifying snapshot integrity... gunzip: snap/2bafbd0d8edc7a7cfa7e19833986ae4032f82006fd0d65cba9c4a75b432b5c8e.gz: unexpected end of file % gunzip: snap/2bafbd0d8edc7a7cfa7e19833986ae4032f82006fd0d65cba9c4a75b432b5c8e.gz: uncompress failed % snapshot corrupt. % root@kobe:/root# Is something wrong with the portsnap servers, or should I try to see if there's something odd with my latest CURRENT upgrade? - Giorgos From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 21:04:30 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D73CD16A418; Thu, 20 Sep 2007 21:04:30 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6C413C455; Thu, 20 Sep 2007 21:04:30 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l8KIkM2t021902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Sep 2007 21:46:32 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l8KIk6Sp073088; Thu, 20 Sep 2007 21:46:22 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l8KIk6nQ073087; Thu, 20 Sep 2007 21:46:06 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Thu, 20 Sep 2007 21:46:06 +0300 From: Giorgos Keramidas To: Colin Percival Message-ID: <20070920184606.GA73060@kobe.laptop> References: <20070920184201.GA72805@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070920184201.GA72805@kobe.laptop> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.098, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.30, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@FreeBSD.org Subject: Re: portsnap snapshot corruption? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:04:30 -0000 On 2007-09-20 21:42, Giorgos Keramidas wrote: > Hi Colin, > > I've tried removing all of /var/db/portsnap/* and refetching several > times today, but all the attempts resulted in corrupt snapshots, like > this one: > > % root@kobe:/root# rm -fr /var/db/portsnap/* > % root@kobe:/root# portsnap fetch > % Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. > % Fetching public key from portsnap3.FreeBSD.org... done. > % Fetching snapshot tag from portsnap3.FreeBSD.org... done. > % Fetching snapshot metadata... done. > % Fetching snapshot generated at Thu Sep 20 04:07:10 EEST 2007: > % 1a2086f1a8eea72b21ecc5c6a03587a26e3b86055bc54a100% of 49 MB 1451 kBps 00m00s > % Extracting snapshot... done. > % Verifying snapshot integrity... gunzip: snap/2bafbd0d8edc7a7cfa7e19833986ae4032f82006fd0d65cba9c4a75b432b5c8e.gz: unexpected end of file > % gunzip: snap/2bafbd0d8edc7a7cfa7e19833986ae4032f82006fd0d65cba9c4a75b432b5c8e.gz: uncompress failed > % snapshot corrupt. > % root@kobe:/root# > > Is something wrong with the portsnap servers, or should I try to see if > there's something odd with my latest CURRENT upgrade? Damn, right after having spent an hour on this *and* posting a message, our local admin notified us that our network has started using a transparent proxy -- which is apparently broken. Sorry for the noise. I'll try to resolve this with our IT guys :) From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 21:07:02 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73FB816A4C2 for ; Thu, 20 Sep 2007 21:07:02 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id E886513C54A for ; Thu, 20 Sep 2007 21:06:37 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id l8KG6B71037903; Thu, 20 Sep 2007 18:06:17 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id l8KG6B3C037902; Thu, 20 Sep 2007 18:06:11 +0200 (CEST) (envelope-from olli) Date: Thu, 20 Sep 2007 18:06:11 +0200 (CEST) Message-Id: <200709201606.l8KG6B3C037902@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, scf@FreeBSD.ORG, sergei@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (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]); Thu, 20 Sep 2007 18:06:17 +0200 (CEST) Cc: Subject: Re: /libexec/ld-elf.so.1: environment corrupt; missing value for X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, scf@FreeBSD.ORG, sergei@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:07:02 -0000 Sean C. Farley wrote: > Oliver Fromme wrote: > > This started to happen after updating to a recent 7-current > > about one week ago (it was working fine with a previous 7- > > current that was a few weeks older). The shell is zsh. > > > > zsh$ /usr/bin/su > > /libexec/ld-elf.so.1: environment corrupt; missing value for > > zsh$ > > Did you also upgrade zsh at the same time? Yes, I did. > You should have been having > troubles with zsh much earlier since my change to the *env() function > went in early July. :) zsh 4.3.4 has a bug where it was mixing calls > to *env() functions with direct manipulation of environ. The CVS > version of zsh is fixed. I created PR ports/115094[1] to patch it in > the ports tree about a month ago. *nudging sergei* :) I applied the patch, and it fixes the problem indeed. Thank you very much! Will the PR be committed to the zsh port before the branch of 7.0 is released? I think it is a rather serious issue. 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 Perl is worse than Python because people wanted it worse. -- Larry Wall From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 21:16:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BFA816A4D6 for ; Thu, 20 Sep 2007 21:16:25 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id AD83F13C4C1 for ; Thu, 20 Sep 2007 21:16:01 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.14.1) id l8KF8eX6034001; Thu, 20 Sep 2007 10:08:40 -0500 (CDT) (envelope-from dan) Date: Thu, 20 Sep 2007 10:08:40 -0500 From: Dan Nelson To: Axel Message-ID: <20070920150840.GG7562@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-fs@freebsd.org, Adam Jacob Muller , freebsd-current@freebsd.org Subject: Re: ZFS pool not working on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:16:26 -0000 In the last episode (Sep 19), Axel said: > Adam Jacob Muller writes: > > On Sep 19, 2007, at 6:44 PM, Axel wrote: > >> There is a file called /boot/zfs/zpool.cache that is kept in sync > >> and loaded at boot time. > >> > >> If that's not there , e.g. by your /boot pointing to it , you're > >> hosed. > > > > File is there, of note is that some of the prior reboots had been > > "unintentional" reboots, so it is possible that that file was > > corrupt, however, it does not seem correct for zfs to come up in a > > state that shows drives as corrupted and/or unavailable. I believe I > > have corrected the crashing issue, however it still does not seem > > that this is the correct behavior. > > If you have a working root outside of zfs I'd do the following: > > 1) Rename the zpool.cache to something else to be safe > 2) Reboot, make sure that /boot/zfs points to the right location, > and reimport the pools. > 3) Should be fine from there on. > > I had sort of the same issue, the zpool.cache isn't documented too > well yet; I only stumbled over it by doing a "lsmod" at the loader > prompt;it's one reason root can be on zfs before hostid is set. If > you setup zfs and don't have the future /boot/zfs set right it won't > work because the information gets lost. With / on zfs it's crucial to > have /boot point to the actual UFS boot partition and not be in your > zfs / somewhere, cause that gets ignored until it's mounted. > > It's a good idea to keep the actual old UFS / directory around > although only /boot gets used in there if you mount / from zfs. What I do is populate my UFS /.boot filesystem with /etc, /lib, /libexec, /bin, and /sbin from my root filesystem, so if zfs fails to load it's easy to recover. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 21:17:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DC9616A419; Thu, 20 Sep 2007 21:17:55 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop1.sarenet.es (proxypop1.sarenet.es [194.30.0.99]) by mx1.freebsd.org (Postfix) with ESMTP id E029713C633; Thu, 20 Sep 2007 21:16:39 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop1.sarenet.es (Postfix) with ESMTP id EADDD5C58; Thu, 20 Sep 2007 12:02:08 +0200 (CEST) In-Reply-To: References: <5870F83F-7174-47AA-98AE-C1DE8972E0C8@SARENET.ES> <613318C3-6B66-4758-A0D4-97405D6A1914@SARENET.ES> <46F23166.8070908@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Borja Marcos Date: Thu, 20 Sep 2007 12:02:11 +0200 To: Borja Marcos X-Mailer: Apple Mail (2.752.2) Cc: Kris Kennaway , freebsd-current@freebsd.org, Ivan Voras Subject: Re: Memory allocation problems (ZFS/NFS/amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:17:55 -0000 I've just tried cranking up both vm.kmem_size and vm.kmem_size_max to the same value (1073741824), and I end up with the same problem. In order to have a repeatable load I'm using httperf --hog --num- conn=100000 --rate 600 --timeout 5 retrieving a small jpg file. The ESTABLISHED TCP sessions I see at the victim machine peak at about 800, and I start to see the same "memory allocation" messages in /var/log/messages. I'm clueless, I must admit :/ Just in case it was the problem I've set up kern.ipc.somaxconn to 4096, but the result is still the same. And disabled syncookies as well. I'm looking at the whole sysctl variables tree and I cannot see a clue. Just to refresh it, it's -CURRENT from yesterday, amd64, apache22 compiled from ports. I've just tried using the echo service from inetd, and the server is keeping 1024 established connections without that error. I just don't understand why this can fail with Apache, but it seems it's an issue with -current, as we have a similar setup with 6.2(i386), same hardware, and it works. Any ideas? So far I'm getting lost :/ Borja. On 20 Sep 2007, at 11:05, Borja Marcos wrote: > > On 20 Sep 2007, at 10:37, Kris Kennaway wrote: > >> Borja Marcos wrote: >>> On 19 Sep 2007, at 19:35, Ivan Voras wrote: >>>> Borja Marcos wrote: >>>> >>>>> These are not innocuous messages, the machine is rejecting >>>>> connections >>>>> like crazy. Any ideas? >>>>> The number of established TCP connections was around 490, and the >>>>> machine has 2 GB of RAM. >>>> >>>> Just a guess: what is your vm.kmem_size_max and have you tried >>>> increasing it? >>> It's the first thing I thought, and I cranked it to a very high >>> value just in case: >>> vm.kmem_size_max: 1073741824 >> >> You actually wanted to tune vm.kmem_size too or it may not >> actually change the value used (_max is just a ceiling for >> autotuning). However if this is i386 you can't set it that high >> without also adjusting KVA_PAGES too (which has other effects). > > It's an amd64. I understand that i386 is mostly out of the question > if I want to play reasonably safe with ZFS :) > > Oh, ok. I will try with both, then. Should I try the same value? > Perhaps it's a bit high, but I understand that with a 64 bit > address space I can set it sort of arbitrarily high without many > side effects. > > ---------------- "The thing he realised about the windows was this: because they had been converted into openable windows after they had first been designed to be impregnable, they were, in fact, much less secure than if they had been designed as openable windows in the first place." Douglas Adams, "Mostly Harmless" From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 21:30:44 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93F5116A478 for ; Thu, 20 Sep 2007 21:30:44 +0000 (UTC) (envelope-from SRS0=efde380b57ce2c99188fd31470d08fe6e5dbee8e=464=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7B513C4F2 for ; Thu, 20 Sep 2007 21:30:44 +0000 (UTC) (envelope-from SRS0=efde380b57ce2c99188fd31470d08fe6e5dbee8e=464=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id ZEY67630; Thu, 20 Sep 2007 14:30:30 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id DBEE945027; Thu, 20 Sep 2007 14:30:29 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Giorgos Keramidas In-Reply-To: Your message of "Thu, 20 Sep 2007 21:46:06 +0300." <20070920184606.GA73060@kobe.laptop> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1190323829_17203P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 20 Sep 2007 14:30:29 -0700 From: "Kevin Oberman" Message-Id: <20070920213029.DBEE945027@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Giorgos Keramidas X-To_Domain: freebsd.org X-To: Giorgos Keramidas X-To_Email: keramida@FreeBSD.org X-To_Alias: keramida Cc: freebsd-current@FreeBSD.org, Colin Percival Subject: Re: portsnap snapshot corruption? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:30:44 -0000 --==_Exmh_1190323829_17203P Content-Type: text/plain; charset=us-ascii > On 2007-09-20 21:42, Giorgos Keramidas wrote: > > Hi Colin, > > > > I've tried removing all of /var/db/portsnap/* and refetching several > > times today, but all the attempts resulted in corrupt snapshots, like > > this one: > > > > % root@kobe:/root# rm -fr /var/db/portsnap/* > > % root@kobe:/root# portsnap fetch > > % Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. > > % Fetching public key from portsnap3.FreeBSD.org... done. > > % Fetching snapshot tag from portsnap3.FreeBSD.org... done. > > % Fetching snapshot metadata... done. > > % Fetching snapshot generated at Thu Sep 20 04:07:10 EEST 2007: > > % 1a2086f1a8eea72b21ecc5c6a03587a26e3b86055bc54a100% of 49 MB 1451 kBps 00m00s > > % Extracting snapshot... done. > > % Verifying snapshot integrity... gunzip: snap/2bafbd0d8edc7a7cfa7e19833986ae4032f82006fd0d65cba9c4a75b432b5c8e.gz: unexpected end of file > > % gunzip: snap/2bafbd0d8edc7a7cfa7e19833986ae4032f82006fd0d65cba9c4a75b432b5c8e.gz: uncompress failed > > % snapshot corrupt. > > % root@kobe:/root# > > > > Is something wrong with the portsnap servers, or should I try to see if > > there's something odd with my latest CURRENT upgrade? > > Damn, right after having spent an hour on this *and* posting a message, > our local admin notified us that our network has started using a > transparent proxy -- which is apparently broken. > > Sorry for the noise. I'll try to resolve this with our IT guys :) In my experience the term "transparent proxy" is an oxymoron (like jumbo shrimp). "Transparent" proxies seem to vary from the distorions of a fun-house mirror to barely translucent. I really, really dislike them when trying to figure out the corrective lenses needed with each of them. -- 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_1190323829_17203P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG8uZ1kn3rs5h7N1ERAiQQAJwLTKEYWsqGobhe1gh8eT6RAmILKACfX7Ok g2PK8tFmgyUV4LjAVk7auZs= =4wRf -----END PGP SIGNATURE----- --==_Exmh_1190323829_17203P-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 21:45:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31B8716A46C; Thu, 20 Sep 2007 21:45:28 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id AD0FD13C50A; Thu, 20 Sep 2007 21:45:27 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l8KLjAIq035406; Fri, 21 Sep 2007 01:45:10 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 21 Sep 2007 01:45:10 +0400 (MSD) From: Dmitry Morozovsky To: Dan Nelson In-Reply-To: <20070920150840.GG7562@dan.emsphone.com> Message-ID: <20070921014243.C33213@woozle.rinet.ru> References: <20070920150840.GG7562@dan.emsphone.com> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Fri, 21 Sep 2007 01:45:10 +0400 (MSD) Cc: freebsd-fs@freebsd.org, Adam Jacob Muller , freebsd-current@freebsd.org, Axel Subject: Re: ZFS pool not working on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:45:28 -0000 On Thu, 20 Sep 2007, Dan Nelson wrote: DN> > It's a good idea to keep the actual old UFS / directory around DN> > although only /boot gets used in there if you mount / from zfs. DN> DN> What I do is populate my UFS /.boot filesystem with /etc, /lib, /libexec, DN> /bin, and /sbin from my root filesystem, so if zfs fails to load it's DN> easy to recover. With small patch to rescue (including zpool and zfs together with libraries involved) all that required is copying /rescue and symlinking /bin and /sbin to it. Well, you also have to mkdir dev and possibly have ./etc/{,s}pwd.db to make tar happy... Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 21:48:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A38316A4A1 for ; Thu, 20 Sep 2007 21:48:48 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.freebsd.org (Postfix) with ESMTP id 2935713C46E for ; Thu, 20 Sep 2007 21:48:48 +0000 (UTC) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 6AC3073098; Thu, 20 Sep 2007 20:34:13 +0000 (GMT) Date: Thu, 20 Sep 2007 20:34:13 +0000 From: John Birrell To: Olivier Warin Message-ID: <20070920203413.GA13737@what-creek.com> References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:48:48 -0000 On Wed, Sep 19, 2007 at 11:34:19PM +0200, Olivier Warin wrote: > I recently wanted to give dtrace on FreeBSD a try but found this > project to be stopped due to a licensing issue. > Will we see dtrace in the base just like zfs anytime (hopefully) soon ? I'm am currently trying to find a way around the licensing issues. Sun is no help at all. The patent clauses in their CDDL are a big deal. They claim that they don't want to sue anyone over patents, but when push comes to shove they actually will. Refer to the Netapp lawsuits. ZFS is completely contained within optional kernel modules which do not affect the BSD license status of the kernel. DTrace consists mainly of kernel modules, however in order for DTrace to inspect the kernel internals it has to have some code inside existing BSD licensed files. An example of the problem is the extra fields that are required in struct thread. DTrace has a bunch of it's own stuff in there. I can't just add to proc.h because the only documentation that I have that indicates that those fields are even needed is in the CDDL source that is smattered throughout OpenSolaris. So I have to extend struct thread in an opaque way like the scheduler appends it's structure. Long story short.... yes DTrace will be back at some time, but there isn't a set time line. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 21:56:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F4CC16A420; Thu, 20 Sep 2007 21:56:39 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop1.sarenet.es (proxypop1.sarenet.es [194.30.0.99]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2CD13C44B; Thu, 20 Sep 2007 21:56:39 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop1.sarenet.es (Postfix) with ESMTP id CDE825D49; Thu, 20 Sep 2007 13:51:33 +0200 (CEST) In-Reply-To: References: <5870F83F-7174-47AA-98AE-C1DE8972E0C8@SARENET.ES> <613318C3-6B66-4758-A0D4-97405D6A1914@SARENET.ES> <46F23166.8070908@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C4A3C06-A6F3-41B1-BE53-F04369CD4F8D@SARENET.ES> Content-Transfer-Encoding: 7bit From: Borja Marcos Date: Thu, 20 Sep 2007 13:51:35 +0200 To: Borja Marcos X-Mailer: Apple Mail (2.752.2) Cc: Kris Kennaway , freebsd-current@freebsd.org, Ivan Voras Subject: Re: Memory allocation problems (ZFS/NFS/amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 21:56:39 -0000 On 20 Sep 2007, at 12:02, Borja Marcos wrote: > I've just tried using the echo service from inetd, and the server > is keeping 1024 established > connections without that error. I just don't understand why this > can fail with Apache, but it seems it's an issue with -current, as > we have a similar setup with 6.2(i386), same hardware, and it works. Here's what I've found out. Apache was confgured by a different person, and I didn't notice that the MaxClients parameter was set too low (159). Setting it up to a high value (1024) has made those errors disappear. So that "memory limit" was actually that the system was dropping connection requests from the listen queue. The error message is quite looks misleading to me. At least I had never seen it, so it caught me by surprise. Sorry about the confusion. I will go on doing tests and let you know the result. Borja. ---------------- "The thing he realised about the windows was this: because they had been converted into openable windows after they had first been designed to be impregnable, they were, in fact, much less secure than if they had been designed as openable windows in the first place." Douglas Adams, "Mostly Harmless" From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 22:30:16 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2054616A4D7 for ; Thu, 20 Sep 2007 22:30:16 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: from marklar.blazingdot.com (marklar.blazingdot.com [207.154.84.83]) by mx1.freebsd.org (Postfix) with SMTP id 09D7C13C44B for ; Thu, 20 Sep 2007 22:30:15 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: (qmail 93114 invoked by uid 503); 20 Sep 2007 22:30:15 -0000 Date: Thu, 20 Sep 2007 15:30:15 -0700 From: Marcus Reid To: Giorgos Keramidas Message-ID: <20070920223015.GA88368@blazingdot.com> References: <20070920184201.GA72805@kobe.laptop> <20070920184606.GA73060@kobe.laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070920184606.GA73060@kobe.laptop> X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org, Colin Percival Subject: Re: portsnap snapshot corruption? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 22:30:16 -0000 On Thu, Sep 20, 2007 at 09:46:06PM +0300, Giorgos Keramidas wrote: > On 2007-09-20 21:42, Giorgos Keramidas wrote: > > Hi Colin, > > > > I've tried removing all of /var/db/portsnap/* and refetching several > > times today, but all the attempts resulted in corrupt snapshots, like > > this one: > > > > % root@kobe:/root# rm -fr /var/db/portsnap/* > > % root@kobe:/root# portsnap fetch > > % Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. > > % Fetching public key from portsnap3.FreeBSD.org... done. > > % Fetching snapshot tag from portsnap3.FreeBSD.org... done. > > % Fetching snapshot metadata... done. > > % Fetching snapshot generated at Thu Sep 20 04:07:10 EEST 2007: > > % 1a2086f1a8eea72b21ecc5c6a03587a26e3b86055bc54a100% of 49 MB 1451 kBps 00m00s > > % Extracting snapshot... done. > > % Verifying snapshot integrity... gunzip: snap/2bafbd0d8edc7a7cfa7e19833986ae4032f82006fd0d65cba9c4a75b432b5c8e.gz: unexpected end of file > > % gunzip: snap/2bafbd0d8edc7a7cfa7e19833986ae4032f82006fd0d65cba9c4a75b432b5c8e.gz: uncompress failed > > % snapshot corrupt. > > % root@kobe:/root# > > > > Is something wrong with the portsnap servers, or should I try to see if > > there's something odd with my latest CURRENT upgrade? > > Damn, right after having spent an hour on this *and* posting a message, > our local admin notified us that our network has started using a > transparent proxy -- which is apparently broken. > > Sorry for the noise. I'll try to resolve this with our IT guys :) I've been having the same problem and I'm not behind any sort of proxy. Also, what sort of proxy would corrupt that 49MB gzipped tar file in a way that it passes gunzip -t? I think this is a real problem with the snapshots being served up by the portsnap servers. I posted this issue to freebsd-ports@ yesterday. Would someone please do an initial portsnap fetch and let me know if it works for them? I haven't seen a "works for me" yet since this problem started. Thank You, Marcus From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 22:37:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3782716A417; Thu, 20 Sep 2007 22:37:16 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id A0E7D13C447; Thu, 20 Sep 2007 22:37:15 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l8KMbA79076517; Thu, 20 Sep 2007 17:37:10 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l8KMb9Ch076516; Thu, 20 Sep 2007 17:37:09 -0500 (CDT) (envelope-from brooks) Date: Thu, 20 Sep 2007 17:37:09 -0500 From: Brooks Davis To: Marcus Reid Message-ID: <20070920223709.GF72058@lor.one-eyed-alien.net> References: <20070920184201.GA72805@kobe.laptop> <20070920184606.GA73060@kobe.laptop> <20070920223015.GA88368@blazingdot.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RE3pQJLXZi4fr8Xo" Content-Disposition: inline In-Reply-To: <20070920223015.GA88368@blazingdot.com> User-Agent: Mutt/1.5.15 (2007-04-06) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 20 Sep 2007 17:37:11 -0500 (CDT) Cc: freebsd-current@freebsd.org, Giorgos Keramidas , Colin Percival Subject: Re: portsnap snapshot corruption? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 22:37:16 -0000 --RE3pQJLXZi4fr8Xo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 20, 2007 at 03:30:15PM -0700, Marcus Reid wrote: > On Thu, Sep 20, 2007 at 09:46:06PM +0300, Giorgos Keramidas wrote: > > On 2007-09-20 21:42, Giorgos Keramidas wrote: > > > Hi Colin, > > > > > > I've tried removing all of /var/db/portsnap/* and refetching several > > > times today, but all the attempts resulted in corrupt snapshots, like > > > this one: > > > > > > % root@kobe:/root# rm -fr /var/db/portsnap/* > > > % root@kobe:/root# portsnap fetch > > > % Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. > > > % Fetching public key from portsnap3.FreeBSD.org... done. > > > % Fetching snapshot tag from portsnap3.FreeBSD.org... done. > > > % Fetching snapshot metadata... done. > > > % Fetching snapshot generated at Thu Sep 20 04:07:10 EEST 2007: > > > % 1a2086f1a8eea72b21ecc5c6a03587a26e3b86055bc54a100% of 49 MB 1451 = kBps 00m00s > > > % Extracting snapshot... done. > > > % Verifying snapshot integrity... gunzip: snap/2bafbd0d8edc7a7cfa7e19= 833986ae4032f82006fd0d65cba9c4a75b432b5c8e.gz: unexpected end of file > > > % gunzip: snap/2bafbd0d8edc7a7cfa7e19833986ae4032f82006fd0d65cba9c4a7= 5b432b5c8e.gz: uncompress failed > > > % snapshot corrupt. > > > % root@kobe:/root# > > > > > > Is something wrong with the portsnap servers, or should I try to see = if > > > there's something odd with my latest CURRENT upgrade? > >=20 > > Damn, right after having spent an hour on this *and* posting a message, > > our local admin notified us that our network has started using a > > transparent proxy -- which is apparently broken. > >=20 > > Sorry for the noise. I'll try to resolve this with our IT guys :) >=20 > I've been having the same problem and I'm not behind any sort of proxy. > Also, what sort of proxy would corrupt that 49MB gzipped tar file in a > way that it passes gunzip -t? I think this is a real problem with > the snapshots being served up by the portsnap servers. I posted this > issue to freebsd-ports@ yesterday. >=20 > Would someone please do an initial portsnap fetch and let me know if it > works for them? I haven't seen a "works for me" yet since this problem > started. [5:32pm] brooks@coredump (/var/db): sudo portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. Fetching public key from portsnap2.FreeBSD.org... done. Fetching snapshot tag from portsnap2.FreeBSD.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Wed Sep 19 20:07:10 CDT 2007: 1a2086f1a8eea72b21ecc5c6a03587a26e3b86055bc54a100% of 49 MB 366 kBps 00m= 00s Extracting snapshot... done. Verifying snapshot integrity... done. Fetching snapshot tag from portsnap2.FreeBSD.org... done. Fetching snapshot metadata... done. Updating from Wed Sep 19 20:07:10 CDT 2007 to Thu Sep 20 16:06:41 CDT 2007. Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 42 patches.....10....20....30....40. done. Applying patches... done. Fetching 2 new ports or files... done. [5:36pm] brooks@coredump (/var/db): -- BRooks --RE3pQJLXZi4fr8Xo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFG8vYUXY6L6fI4GtQRArZ6AKDkutKrwQWt8Ri6SrD5T9l4WAWyBQCbBqJM /k5sw1mKSV/8MH1gcKzt/o4= =7Zpg -----END PGP SIGNATURE----- --RE3pQJLXZi4fr8Xo-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 22:43:37 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03CE416A417 for ; Thu, 20 Sep 2007 22:43:37 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: from marklar.blazingdot.com (marklar.blazingdot.com [207.154.84.83]) by mx1.freebsd.org (Postfix) with SMTP id C08E813C474 for ; Thu, 20 Sep 2007 22:43:36 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: (qmail 97474 invoked by uid 503); 20 Sep 2007 22:43:36 -0000 Date: Thu, 20 Sep 2007 15:43:36 -0700 From: Marcus Reid To: Giorgos Keramidas Message-ID: <20070920224336.GA94445@blazingdot.com> References: <20070920184201.GA72805@kobe.laptop> <20070920184606.GA73060@kobe.laptop> <20070920223015.GA88368@blazingdot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070920223015.GA88368@blazingdot.com> X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org, Colin Percival Subject: Re: portsnap snapshot corruption? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 22:43:37 -0000 On Thu, Sep 20, 2007 at 03:30:15PM -0700, Marcus Reid wrote: > On Thu, Sep 20, 2007 at 09:46:06PM +0300, Giorgos Keramidas wrote: > > On 2007-09-20 21:42, Giorgos Keramidas wrote: > > > > > > Is something wrong with the portsnap servers, or should I try to see if > > > there's something odd with my latest CURRENT upgrade? > > > > Damn, right after having spent an hour on this *and* posting a message, > > our local admin notified us that our network has started using a > > transparent proxy -- which is apparently broken. > > > > Sorry for the noise. I'll try to resolve this with our IT guys :) > > I've been having the same problem and I'm not behind any sort of proxy. > Also, what sort of proxy would corrupt that 49MB gzipped tar file in a > way that it passes gunzip -t? I think this is a real problem with > the snapshots being served up by the portsnap servers. I posted this > issue to freebsd-ports@ yesterday. I should provide a couple more details of what I've seen: - The portsnap fetch downloads the 49MB .tgz, and it extracts properly. This file is not corrupted (passes gzip checksum). - In the portsnap/snap directory, many of the .gz files are correct, but many (looks like 1/4?) of them are truncated somehow. They are gzip files, but they are corrupted. Marcus From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 22:55:35 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 580FC16A417; Thu, 20 Sep 2007 22:55:35 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 13F4F13C4A3; Thu, 20 Sep 2007 22:55:34 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from stat.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IYUvi-0007PT-GO; Fri, 21 Sep 2007 02:55:30 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IYUx7-0001P9-N2; Fri, 21 Sep 2007 02:56:57 +0400 To: Marcus Reid References: <20070920184201.GA72805@kobe.laptop> <20070920184606.GA73060@kobe.laptop> <20070920223015.GA88368@blazingdot.com> <20070920224336.GA94445@blazingdot.com> From: Boris Samorodov Date: Fri, 21 Sep 2007 02:56:57 +0400 In-Reply-To: <20070920224336.GA94445@blazingdot.com> (Marcus Reid's message of "Thu\, 20 Sep 2007 15\:43\:36 -0700") Message-ID: <30854022@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, Giorgos Keramidas , Colin Percival Subject: Re: portsnap snapshot corruption? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 22:55:35 -0000 On Thu, 20 Sep 2007 15:43:36 -0700 Marcus Reid wrote: > On Thu, Sep 20, 2007 at 03:30:15PM -0700, Marcus Reid wrote: > > On Thu, Sep 20, 2007 at 09:46:06PM +0300, Giorgos Keramidas wrote: > > > On 2007-09-20 21:42, Giorgos Keramidas wrote: > > > > > > > > Is something wrong with the portsnap servers, or should I try to see if > > > > there's something odd with my latest CURRENT upgrade? > > > > > > Damn, right after having spent an hour on this *and* posting a message, > > > our local admin notified us that our network has started using a > > > transparent proxy -- which is apparently broken. > > > > > > Sorry for the noise. I'll try to resolve this with our IT guys :) > > > > I've been having the same problem and I'm not behind any sort of proxy. > > Also, what sort of proxy would corrupt that 49MB gzipped tar file in a > > way that it passes gunzip -t? I think this is a real problem with > > the snapshots being served up by the portsnap servers. I posted this > > issue to freebsd-ports@ yesterday. > I should provide a couple more details of what I've seen: > - The portsnap fetch downloads the 49MB .tgz, and it extracts > properly. This file is not corrupted (passes gzip checksum). > - In the portsnap/snap directory, many of the .gz > files are correct, but many (looks like 1/4?) of them are > truncated somehow. They are gzip files, but they are corrupted. Isn't it related to a recent libarchive backout?: . src/lib/libarchive/archive_write_disk.c rev.1.16 . src/lib/libarchive/test/test_write_disk.c rev.1.5 WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 22:56:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23F7816A468 for ; Thu, 20 Sep 2007 22:56:45 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from spork.qfe3.net (spork.qfe3.net [212.13.207.101]) by mx1.freebsd.org (Postfix) with ESMTP id CACC513C467 for ; Thu, 20 Sep 2007 22:56:44 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from [81.104.144.87] (helo=voi.aagh.net) by spork.qfe3.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1IYQag-000G9E-VV; Thu, 20 Sep 2007 19:17:31 +0100 Received: from freaky by voi.aagh.net with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IYQag-000FI5-NZ; Thu, 20 Sep 2007 19:17:30 +0100 Date: Thu, 20 Sep 2007 19:17:30 +0100 From: Thomas Hurst To: Olivier Warin Message-ID: <20070920181730.GA58507@voi.aagh.net> Mail-Followup-To: Olivier Warin , freebsd-current@freebsd.org References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> Organization: Not much. User-Agent: Mutt/1.5.16 (2007-06-09) Sender: Thomas Hurst Cc: freebsd-current@freebsd.org Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 22:56:45 -0000 * Olivier Warin (daffy@xview.net) wrote: > I recently wanted to give dtrace on FreeBSD a try but found this > project to be stopped due to a licensing issue. Will we see dtrace in > the base just like zfs anytime (hopefully) soon ? The last I've heard of it is sadly rather anemic, but basically says it's been restarted from scratch: http://dtrace.what-creek.com/ Maybe we'll see it in FreeBSD 8. *makes puppydog eyes at jb* -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 23:12:17 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EB0116A474 for ; Thu, 20 Sep 2007 23:12:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 27CDB13C494 for ; Thu, 20 Sep 2007 23:12:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 13894 invoked by uid 399); 20 Sep 2007 23:12:16 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 20 Sep 2007 23:12:16 -0000 X-Originating-IP: 127.0.0.1 Date: Thu, 20 Sep 2007 16:12:13 -0700 (PDT) From: Doug Barton To: "Constantine A. Murenin" In-Reply-To: <46F1A96F.2040602@FreeBSD.org> Message-ID: References: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> <46E9FC0C.70607@FreeBSD.org> <46F1A96F.2040602@FreeBSD.org> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Leidinger , Shteryana Shopova , freebsd-current@FreeBSD.org Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 23:12:17 -0000 On Wed, 19 Sep 2007, Constantine A. Murenin wrote: > Thanks for testing! Glad to help. In case it's interesting, I was doing the xorg update with portmaster last night and I got several "PROCHOT asserted" messages on my console at different times. I'm assuming that's expected behavior, just curious if it's something bad, as in when that happens it's time to turn off the laptop? (I didn't seem them when the happened, they were there when I got back to check on the compiling.) >> Two small comments about the rc.d stuff. First, the empty _flags variable >> in defaults/rc.conf should be commented out. Second, the rc.d > > How so? I don't see any other empty _flags variables in defaults/rc.conf > being commented out. Well you missed named_flags. :) But seriously, I didn't realize that things had gotten quite so out of hand with that ... never mind then. >> script needs the shutdown KEYWORD. > > Similarly, I don't see why this is needed -- it was not used by the scripts > on which this script was based on Which scripts? I realize that a distressingly large number of scripts that start services don't have this keyword, but they should. I'll work on a patch for that. At the same time, we don't want to add any new scripts that make the same mistake. > Reading through rc(8) doesn't seem to suggest that this keyword would > actually be applicable here. As far as I can tell, you're starting a daemon, which means that it should be cleanly shut down when the system exits. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 23:16:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED7CE16A421 for ; Thu, 20 Sep 2007 23:16:23 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.freebsd.org (Postfix) with ESMTP id B9D6013C465 for ; Thu, 20 Sep 2007 23:16:23 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so466274wxd for ; Thu, 20 Sep 2007 16:16:22 -0700 (PDT) Received: by 10.143.157.10 with SMTP id j10mr37284wfo.1190295545517; Thu, 20 Sep 2007 06:39:05 -0700 (PDT) Received: by 10.143.14.9 with HTTP; Thu, 20 Sep 2007 06:39:05 -0700 (PDT) Message-ID: <47d0403c0709200639r3c78819dxb7402997aff3093e@mail.gmail.com> Date: Thu, 20 Sep 2007 09:39:05 -0400 From: "Ben Kaduk" To: "Gawain Bai" 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-current@freebsd.org Subject: Re: Firefox make some sound like bell X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 23:16:24 -0000 On 9/20/07, Gawain Bai wrote: > I have update firefox to 2.0.0.7 about 3 hour ago, but I hair some > sound like bell when firefox start and runing. > Did you compile firefox with some sort of ``development'' or ``debugging'' configuration knob (I don't remember the exact name of the flag at the moment)? Doing so causes firefox to beep whenever some sort of error or inconsistency is discovered (and a message is printed to the logs). I found this too annoying for me, and disabled the config flag. -Ben Kaduk > why? > > and I have got some message like this when execute firefox -h > > Type Manifest File: /usr/local/lib/firefox/components/xpti.dat > ###!!! ASSERTION: Failed to write xpti manifest!: 'Error', file > xptiInterfaceInfoManager.cpp, line 1937 > Break: at file xptiInterfaceInfoManager.cpp, line 1937 > *** Registering Apprunner components (all right -- a generic module!) > nsNativeComponentLoader: autoregistering begins. > nsNativeComponentLoader: autoregistering succeeded > ###!!! ASSERTION: Failed to write xpti manifest!: 'Error', file > xptiInterfaceInfoManager.cpp, line 1937 > Break: at file xptiInterfaceInfoManager.cpp, line 1937 > nsNativeComponentLoader: registering deferred (0) > -jsconsole Open the Error console. > -browser Open a browser window. > -inspector Open the DOM inspector. > Usage: firefox [-flags] [] > WARNING: nsExceptionService ignoring thread destruction after > shutdown, file nsExceptionService.cpp, line 191 > WARNING: No event queue listener?, file nsEventQueue.cpp, line 79 > Could not write out perisistant registry! > nsStringStats > => mAllocCount: 5064 > => mReallocCount: 943 > => mFreeCount: 5064 > => mShareCount: 5426 > => mAdoptCount: 191 > => mAdoptFreeCount: 190 -- LEAKED 1 !!! > > my system informations: > > FreeBSD local.khsing.net 7.0-CURRENT FreeBSD 7.0-CURRENT #7: Thu Sep > 13 12:47:13 UTC 2007 > root@local.khsing.net:/usr/obj/usr/src/sys/D600 i386 > > > -- > _______________________________________ > Mr. Gawain Bai, PinYin: Guixing Bai, Wade-Giles: Kueihsing Pai > Email: wike1985_AT_gmail_DOT_com > blog: http://cnwike.blogspot.com this for work > http://blog.donews.com/kueihsing this for study. > give me free or give me death. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 23:20:42 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E03016A419 for ; Thu, 20 Sep 2007 23:20:42 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: from marklar.blazingdot.com (marklar.blazingdot.com [207.154.84.83]) by mx1.freebsd.org (Postfix) with SMTP id 0551B13C45A for ; Thu, 20 Sep 2007 23:20:41 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: (qmail 9570 invoked by uid 503); 20 Sep 2007 23:20:41 -0000 Date: Thu, 20 Sep 2007 16:20:41 -0700 From: Marcus Reid To: Boris Samorodov Message-ID: <20070920232041.GA8549@blazingdot.com> References: <20070920184201.GA72805@kobe.laptop> <20070920184606.GA73060@kobe.laptop> <20070920223015.GA88368@blazingdot.com> <20070920224336.GA94445@blazingdot.com> <30854022@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30854022@srv.sem.ipt.ru> X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org, Giorgos Keramidas , Colin Percival Subject: Re: portsnap snapshot corruption? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 23:20:42 -0000 On Fri, Sep 21, 2007 at 02:56:57AM +0400, Boris Samorodov wrote: > On Thu, 20 Sep 2007 15:43:36 -0700 Marcus Reid wrote: > > On Thu, Sep 20, 2007 at 03:30:15PM -0700, Marcus Reid wrote: > > > On Thu, Sep 20, 2007 at 09:46:06PM +0300, Giorgos Keramidas wrote: > > > > On 2007-09-20 21:42, Giorgos Keramidas wrote: > > > > > > > > > > Is something wrong with the portsnap servers, or should I try to see if > > > > > there's something odd with my latest CURRENT upgrade? > > > > > > > > Damn, right after having spent an hour on this *and* posting a message, > > > > our local admin notified us that our network has started using a > > > > transparent proxy -- which is apparently broken. > > > > > > > > Sorry for the noise. I'll try to resolve this with our IT guys :) > > > > > > I've been having the same problem and I'm not behind any sort of proxy. > > > Also, what sort of proxy would corrupt that 49MB gzipped tar file in a > > > way that it passes gunzip -t? I think this is a real problem with > > > the snapshots being served up by the portsnap servers. I posted this > > > issue to freebsd-ports@ yesterday. > > > I should provide a couple more details of what I've seen: > > > - The portsnap fetch downloads the 49MB .tgz, and it extracts > > properly. This file is not corrupted (passes gzip checksum). > > > - In the portsnap/snap directory, many of the .gz > > files are correct, but many (looks like 1/4?) of them are > > truncated somehow. They are gzip files, but they are corrupted. > > Isn't it related to a recent libarchive backout?: > . src/lib/libarchive/archive_write_disk.c rev.1.16 > . src/lib/libarchive/test/test_write_disk.c rev.1.5 Yes, that would be it. Both of the machines that I was testing on have the version with the regressions. Thanks! Marcus From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 02:41:11 2007 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52BF916A500; Fri, 21 Sep 2007 02:41:11 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 6FB9713C45B; Fri, 21 Sep 2007 02:41:09 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l8L2f8j8021365; Fri, 21 Sep 2007 06:41:08 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1190342468; bh=FRYmNZ/Vd3kG7s1WD6jEj9RxrWqBOnBoecBcT/a Kphs=; l=14929; h=Date:From:To:Subject:Message-ID:Mail-Followup-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent; b=bpPRSYcXDhqaRo41WRfJduklP15VlvIw+zISKTTO ni/SMjRp8nZOkZgExUveg6ddDhGzSjDfTYXoQ6T3epuYqZZHzZDC6n6ct5kpuSo79aV b5gWWPkhnS3u2fKLU7uGIGu5jnz38Y5XEEWFG5Vlc+MGebHHoIihmsKgZFdeNIbk= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l8L2f7rT021364; Fri, 21 Sep 2007 06:41:07 +0400 (MSD) (envelope-from ache) Date: Fri, 21 Sep 2007 06:41:07 +0400 From: Andrey Chernov To: Taku YAMAMOTO , Petr Hroudn?? , current@FreeBSD.ORG, perky@FreeBSD.ORG, i18n@FreeBSD.ORG Message-ID: <20070921024107.GA21223@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Taku YAMAMOTO , Petr Hroudn?? , current@FreeBSD.ORG, perky@FreeBSD.ORG, i18n@FreeBSD.ORG References: <20070916192924.GA12678@nagual.pp.ru> <20070917092130.GA24424@nagual.pp.ru> <20070918020100.d43beb0b.taku@tackymt.homeip.net> <20070917171633.GA31179@nagual.pp.ru> <20070919111207.f37653fc.taku@tackymt.homeip.net> <20070919022555.GA70617@nagual.pp.ru> <20070919023625.GA70891@nagual.pp.ru> <20070919051830.GA72429@nagual.pp.ru> <20070919121024.GA81606@nagual.pp.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <20070919121024.GA81606@nagual.pp.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 02:41:11 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Sep 19, 2007 at 04:10:24PM +0400, Andrey Chernov wrote: > Improved vesrsion. Intoduce general __mb_sch_limit parameter instead for > all locales specifying upper limit of single char range. It allows also > fix the bug when ctype(3) functions called with arg > 0xFF for wide > character locales and simplifies all checks. New patch is attached. Here > is updated rationale again: Next improved version, now optimized for speed. I decide to remove extra _CTYPE_WID flag and duplicate needed functions instead. -- http://ache.pp.ru/ --rwEMma7ioTxnRzrJ Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ctype.patch" --- Symbol.map.old 2007-09-19 22:37:21.000000000 +0400 +++ Symbol.map 2007-09-21 06:31:56.000000000 +0400 @@ -60,12 +60,17 @@ nextwctype; nl_langinfo; __maskrune; + __sbmaskrune; __istype; + __sbistype; __isctype; __toupper; + __sbtoupper; __tolower; + __sbtolower; __wcwidth; __mb_cur_max; + __mb_sch_limit; rpmatch; ___runetype; setlocale; --- _ctype.h.old 2007-09-16 21:13:59.000000000 +0400 +++ _ctype.h 2007-09-21 06:21:59.000000000 +0400 @@ -87,6 +87,8 @@ #define __inline #endif +extern int __mb_sch_limit; + /* * Use inline functions if we are allowed to and the compiler supports them. */ @@ -103,15 +105,28 @@ } static __inline int +__sbmaskrune(__ct_rune_t _c, unsigned long _f) +{ + return (_c < 0 || _c >= __mb_sch_limit) ? 0 : + _CurrentRuneLocale->__runetype[_c] & _f; +} + +static __inline int __istype(__ct_rune_t _c, unsigned long _f) { return (!!__maskrune(_c, _f)); } static __inline int +__sbistype(__ct_rune_t _c, unsigned long _f) +{ + return (!!__sbmasksrune(_c, _f)); +} + +static __inline int __isctype(__ct_rune_t _c, unsigned long _f) { - return (_c < 0 || _c >= _CACHED_RUNES) ? 0 : + return (_c < 0 || _c >= __mb_sch_limit) ? 0 : !!(_DefaultRuneLocale.__runetype[_c] & _f); } @@ -123,12 +138,26 @@ } static __inline __ct_rune_t +__sbtoupper(__ct_rune_t _c) +{ + return (_c < 0 || _c >= __mb_sch_limit) ? _c : + _CurrentRuneLocale->__mapupper[_c]; +} + +static __inline __ct_rune_t __tolower(__ct_rune_t _c) { return (_c < 0 || _c >= _CACHED_RUNES) ? ___tolower(_c) : _CurrentRuneLocale->__maplower[_c]; } +static __inline __ct_rune_t +__sbtolower(__ct_rune_t _c) +{ + return (_c < 0 || _c >= __mb_sch_limit) ? _c : + _CurrentRuneLocale->__maplower[_c]; +} + static __inline int __wcwidth(__ct_rune_t _c) { @@ -146,10 +175,14 @@ __BEGIN_DECLS int __maskrune(__ct_rune_t, unsigned long); +int __sbmaskrune(__ct_rune_t, unsigned long); int __istype(__ct_rune_t, unsigned long); +int __sbistype(__ct_rune_t, unsigned long); int __isctype(__ct_rune_t, unsigned long); __ct_rune_t __toupper(__ct_rune_t); +__ct_rune_t __sbtoupper(__ct_rune_t); __ct_rune_t __tolower(__ct_rune_t); +__ct_rune_t __sbtolower(__ct_rune_t); int __wcwidth(__ct_rune_t); __END_DECLS #endif /* using inlines */ --- big5.c.old 2007-09-19 08:48:55.000000000 +0400 +++ big5.c 2007-09-19 15:41:26.000000000 +0400 @@ -49,6 +49,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _BIG5_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _BIG5_mbsinit(const mbstate_t *); @@ -68,6 +70,7 @@ __mbsinit = _BIG5_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_sch_limit = 256; return (0); } --- ctype.h.old 2007-09-16 22:03:55.000000000 +0400 +++ ctype.h 2007-09-21 06:26:26.000000000 +0400 @@ -86,19 +86,19 @@ #endif __END_DECLS -#define isalnum(c) __istype((c), _CTYPE_A|_CTYPE_D) -#define isalpha(c) __istype((c), _CTYPE_A) -#define iscntrl(c) __istype((c), _CTYPE_C) +#define isalnum(c) __sbistype((c), _CTYPE_A|_CTYPE_D) +#define isalpha(c) __sbistype((c), _CTYPE_A) +#define iscntrl(c) __sbistype((c), _CTYPE_C) #define isdigit(c) __isctype((c), _CTYPE_D) /* ANSI -- locale independent */ -#define isgraph(c) __istype((c), _CTYPE_G) -#define islower(c) __istype((c), _CTYPE_L) -#define isprint(c) __istype((c), _CTYPE_R) -#define ispunct(c) __istype((c), _CTYPE_P) -#define isspace(c) __istype((c), _CTYPE_S) -#define isupper(c) __istype((c), _CTYPE_U) +#define isgraph(c) __sbistype((c), _CTYPE_G) +#define islower(c) __sbistype((c), _CTYPE_L) +#define isprint(c) __sbistype((c), _CTYPE_R) +#define ispunct(c) __sbistype((c), _CTYPE_P) +#define isspace(c) __sbistype((c), _CTYPE_S) +#define isupper(c) __sbistype((c), _CTYPE_U) #define isxdigit(c) __isctype((c), _CTYPE_X) /* ANSI -- locale independent */ -#define tolower(c) __tolower(c) -#define toupper(c) __toupper(c) +#define tolower(c) __sbtolower(c) +#define toupper(c) __sbtoupper(c) #if __XSI_VISIBLE /* @@ -112,24 +112,24 @@ * * XXX isascii() and toascii() should similarly be undocumented. */ -#define _tolower(c) __tolower(c) -#define _toupper(c) __toupper(c) +#define _tolower(c) __sbtolower(c) +#define _toupper(c) __sbtoupper(c) #define isascii(c) (((c) & ~0x7F) == 0) #define toascii(c) ((c) & 0x7F) #endif #if __ISO_C_VISIBLE >= 1999 -#define isblank(c) __istype((c), _CTYPE_B) +#define isblank(c) __sbistype((c), _CTYPE_B) #endif #if __BSD_VISIBLE -#define digittoint(c) __maskrune((c), 0xFF) -#define ishexnumber(c) __istype((c), _CTYPE_X) -#define isideogram(c) __istype((c), _CTYPE_I) -#define isnumber(c) __istype((c), _CTYPE_D) -#define isphonogram(c) __istype((c), _CTYPE_Q) -#define isrune(c) __istype((c), 0xFFFFFF00L) -#define isspecial(c) __istype((c), _CTYPE_T) +#define digittoint(c) __sbmaskrune((c), 0xFF) +#define ishexnumber(c) __sbistype((c), _CTYPE_X) +#define isideogram(c) __sbistype((c), _CTYPE_I) +#define isnumber(c) __sbistype((c), _CTYPE_D) +#define isphonogram(c) __sbistype((c), _CTYPE_Q) +#define isrune(c) __sbistype((c), 0xFFFFFF00L) +#define isspecial(c) __sbistype((c), _CTYPE_T) #endif #endif /* !_CTYPE_H_ */ --- euc.c.old 2007-09-19 08:50:57.000000000 +0400 +++ euc.c 2007-09-19 15:41:26.000000000 +0400 @@ -49,6 +49,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _EUC_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _EUC_mbsinit(const mbstate_t *); @@ -116,6 +118,7 @@ __mbrtowc = _EUC_mbrtowc; __wcrtomb = _EUC_wcrtomb; __mbsinit = _EUC_mbsinit; + __mb_sch_limit = 256; return (0); } --- gb18030.c.old 2007-09-19 08:59:01.000000000 +0400 +++ gb18030.c 2007-09-19 15:41:26.000000000 +0400 @@ -39,6 +39,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _GB18030_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GB18030_mbsinit(const mbstate_t *); @@ -59,6 +61,7 @@ __mbsinit = _GB18030_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 4; + __mb_sch_limit = 256; return (0); } --- gb2312.c.old 2007-09-19 09:00:35.000000000 +0400 +++ gb2312.c 2007-09-19 15:41:26.000000000 +0400 @@ -35,6 +35,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _GB2312_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GB2312_mbsinit(const mbstate_t *); @@ -55,6 +57,7 @@ __wcrtomb = _GB2312_wcrtomb; __mbsinit = _GB2312_mbsinit; __mb_cur_max = 2; + __mb_sch_limit = 256; return (0); } --- gbk.c.old 2007-09-19 09:01:33.000000000 +0400 +++ gbk.c 2007-09-19 15:41:26.000000000 +0400 @@ -42,6 +42,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _GBK_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GBK_mbsinit(const mbstate_t *); @@ -61,6 +63,7 @@ __mbsinit = _GBK_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_sch_limit = 256; return (0); } --- isctype.c.old 2007-09-16 22:31:26.000000000 +0400 +++ isctype.c 2007-09-21 06:28:30.000000000 +0400 @@ -48,7 +48,7 @@ digittoint(c) int c; { - return (__maskrune(c, 0xFF)); + return (__sbmaskrune(c, 0xFF)); } #undef isalnum @@ -56,7 +56,7 @@ isalnum(c) int c; { - return (__istype(c, _CTYPE_A|_CTYPE_D)); + return (__sbistype(c, _CTYPE_A|_CTYPE_D)); } #undef isalpha @@ -64,7 +64,7 @@ isalpha(c) int c; { - return (__istype(c, _CTYPE_A)); + return (__sbistype(c, _CTYPE_A)); } #undef isascii @@ -80,7 +80,7 @@ isblank(c) int c; { - return (__istype(c, _CTYPE_B)); + return (__sbistype(c, _CTYPE_B)); } #undef iscntrl @@ -88,7 +88,7 @@ iscntrl(c) int c; { - return (__istype(c, _CTYPE_C)); + return (__sbistype(c, _CTYPE_C)); } #undef isdigit @@ -104,7 +104,7 @@ isgraph(c) int c; { - return (__istype(c, _CTYPE_G)); + return (__sbistype(c, _CTYPE_G)); } #undef ishexnumber @@ -112,7 +112,7 @@ ishexnumber(c) int c; { - return (__istype(c, _CTYPE_X)); + return (__sbistype(c, _CTYPE_X)); } #undef isideogram @@ -120,7 +120,7 @@ isideogram(c) int c; { - return (__istype(c, _CTYPE_I)); + return (__sbistype(c, _CTYPE_I)); } #undef islower @@ -128,7 +128,7 @@ islower(c) int c; { - return (__istype(c, _CTYPE_L)); + return (__sbistype(c, _CTYPE_L)); } #undef isnumber @@ -136,7 +136,7 @@ isnumber(c) int c; { - return (__istype(c, _CTYPE_D)); + return (__sbistype(c, _CTYPE_D)); } #undef isphonogram @@ -144,7 +144,7 @@ isphonogram(c) int c; { - return (__istype(c, _CTYPE_Q)); + return (__sbistype(c, _CTYPE_Q)); } #undef isprint @@ -152,7 +152,7 @@ isprint(c) int c; { - return (__istype(c, _CTYPE_R)); + return (__sbistype(c, _CTYPE_R)); } #undef ispunct @@ -160,7 +160,7 @@ ispunct(c) int c; { - return (__istype(c, _CTYPE_P)); + return (__sbistype(c, _CTYPE_P)); } #undef isrune @@ -168,7 +168,7 @@ isrune(c) int c; { - return (__istype(c, 0xFFFFFF00L)); + return (__sbistype(c, 0xFFFFFF00L)); } #undef isspace @@ -176,7 +176,7 @@ isspace(c) int c; { - return (__istype(c, _CTYPE_S)); + return (__sbistype(c, _CTYPE_S)); } #undef isspecial @@ -184,7 +184,7 @@ isspecial(c) int c; { - return (__istype(c, _CTYPE_T)); + return (__sbistype(c, _CTYPE_T)); } #undef isupper @@ -192,7 +192,7 @@ isupper(c) int c; { - return (__istype(c, _CTYPE_U)); + return (__sbistype(c, _CTYPE_U)); } #undef isxdigit @@ -216,7 +216,7 @@ tolower(c) int c; { - return (__tolower(c)); + return (__sbtolower(c)); } #undef toupper @@ -224,6 +224,6 @@ toupper(c) int c; { - return (__toupper(c)); + return (__sbtoupper(c)); } --- iswctype.c.old 2007-09-16 22:31:30.000000000 +0400 +++ iswctype.c 2007-09-21 06:29:59.000000000 +0400 @@ -61,7 +61,7 @@ iswascii(wc) wint_t wc; { - return ((wc & ~0x7F) == 0); + return (wc < 0x80); } #undef iswblank --- mskanji.c.old 2007-09-19 09:02:56.000000000 +0400 +++ mskanji.c 2007-09-19 15:41:26.000000000 +0400 @@ -47,6 +47,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _MSKanji_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _MSKanji_mbsinit(const mbstate_t *); @@ -66,6 +68,7 @@ __mbsinit = _MSKanji_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_sch_limit = 256; return (0); } --- none.c.old 2007-09-19 08:56:40.000000000 +0400 +++ none.c 2007-09-19 21:16:11.000000000 +0400 @@ -58,6 +58,11 @@ static size_t _none_wcsnrtombs(char * __restrict, const wchar_t ** __restrict, size_t, size_t, mbstate_t * __restrict); +/* setup defaults */ + +int __mb_cur_max = 1; +int __mb_sch_limit = 256; /* Expected to be <= _CACHED_RUNES */ + int _none_init(_RuneLocale *rl) { @@ -69,6 +74,7 @@ __wcsnrtombs = _none_wcsnrtombs; _CurrentRuneLocale = rl; __mb_cur_max = 1; + __mb_sch_limit = 256; return(0); } @@ -176,7 +182,6 @@ /* setup defaults */ -int __mb_cur_max = 1; size_t (*__mbrtowc)(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict) = _none_mbrtowc; int (*__mbsinit)(const mbstate_t *) = _none_mbsinit; --- setrunelocale.c.old 2007-09-19 09:03:59.000000000 +0400 +++ setrunelocale.c 2007-09-19 15:41:26.000000000 +0400 @@ -45,6 +45,8 @@ #include "mblocal.h" #include "setlocale.h" +extern int __mb_sch_limit; + extern _RuneLocale *_Read_RuneMagi(FILE *); static int __setrunelocale(const char *); @@ -59,6 +61,7 @@ static char ctype_encoding[ENCODING_LEN + 1]; static _RuneLocale *CachedRuneLocale; static int Cached__mb_cur_max; + static int Cached__mb_sch_limit; static size_t (*Cached__mbrtowc)(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static size_t (*Cached__wcrtomb)(char * __restrict, wchar_t, @@ -85,6 +88,7 @@ strcmp(encoding, ctype_encoding) == 0) { _CurrentRuneLocale = CachedRuneLocale; __mb_cur_max = Cached__mb_cur_max; + __mb_sch_limit = Cached__mb_sch_limit; __mbrtowc = Cached__mbrtowc; __mbsinit = Cached__mbsinit; __mbsnrtowcs = Cached__mbsnrtowcs; @@ -147,6 +151,7 @@ } CachedRuneLocale = _CurrentRuneLocale; Cached__mb_cur_max = __mb_cur_max; + Cached__mb_sch_limit = __mb_sch_limit; Cached__mbrtowc = __mbrtowc; Cached__mbsinit = __mbsinit; Cached__mbsnrtowcs = __mbsnrtowcs; --- utf8.c.old 2007-09-19 08:18:40.000000000 +0400 +++ utf8.c 2007-09-19 15:55:35.000000000 +0400 @@ -35,6 +35,8 @@ #include #include "mblocal.h" +extern int __mb_sch_limit; + static size_t _UTF8_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _UTF8_mbsinit(const mbstate_t *); @@ -63,6 +65,7 @@ __wcsnrtombs = _UTF8_wcsnrtombs; _CurrentRuneLocale = rl; __mb_cur_max = 6; + __mb_sch_limit = 128; return (0); } --- wctype.h.old 2007-09-16 21:59:37.000000000 +0400 +++ wctype.h 2007-09-21 06:08:40.000000000 +0400 @@ -106,7 +106,7 @@ #define towupper(wc) __toupper(wc) #if __BSD_VISIBLE -#define iswascii(wc) (((wc) & ~0x7F) == 0) +#define iswascii(wc) ((wc) < 0x80) #define iswhexnumber(wc) __istype((wc), _CTYPE_X) #define iswideogram(wc) __istype((wc), _CTYPE_I) #define iswnumber(wc) __istype((wc), _CTYPE_D) --rwEMma7ioTxnRzrJ-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 03:45:18 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59CEE16A417; Fri, 21 Sep 2007 03:45:18 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id D3D2F13C44B; Fri, 21 Sep 2007 03:45:17 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-4-28-21.dhcp.embarqhsd.net [76.4.28.21]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l8L3jNc7010294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Sep 2007 07:45:25 +0400 Message-ID: <46F33E3A.8010508@FreeBSD.org> Date: Thu, 20 Sep 2007 23:44:58 -0400 From: "Constantine A. Murenin" Organization: Google Summer of Code 2007 Student @ The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: Doug Barton References: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> <46E9FC0C.70607@FreeBSD.org> <46F1A96F.2040602@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , Shteryana Shopova , freebsd-current@FreeBSD.org, "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 03:45:18 -0000 On 20/09/2007 19:12, Doug Barton wrote: > On Wed, 19 Sep 2007, Constantine A. Murenin wrote: > >> Thanks for testing! > > > Glad to help. In case it's interesting, I was doing the xorg update with > portmaster last night and I got several "PROCHOT asserted" messages on > my console at different times. I'm assuming that's expected behavior, > just curious if it's something bad, as in when that happens it's time to > turn off the laptop? (I didn't seem them when the happened, they were > there when I got back to check on the compiling.) Based on the fact that it's a laptop, I'm not too surprised -- the word 'laptop' in itself should not be taken literally due to the heat that these things produce -- you clearly don't want them on your lap. :-) >>> Two small comments about the rc.d stuff. First, the empty _flags >>> variable in defaults/rc.conf should be commented out. Second, the rc.d >> >> >> How so? I don't see any other empty _flags variables in >> defaults/rc.conf being commented out. > > > Well you missed named_flags. :) But seriously, I didn't realize that > things had gotten quite so out of hand with that ... never mind then. > >>> script needs the shutdown KEYWORD. >> >> >> Similarly, I don't see why this is needed -- it was not used by the >> scripts on which this script was based on > > > Which scripts? I realize that a distressingly large number of scripts > that start services don't have this keyword, but they should. I'll work > on a patch for that. At the same time, we don't want to add any new > scripts that make the same mistake. http://lists.freebsd.org/pipermail/p4-projects/2007-September/020980.html "add /etc/rc.d/sensorsd, modelled after ftpproxy and somewhat around powerd" >> Reading through rc(8) doesn't seem to suggest that this keyword would >> actually be applicable here. > > > As far as I can tell, you're starting a daemon, which means that it > should be cleanly shut down when the system exits. Again, this is not how the majority of other daemons do it. Moreover, I am not aware of any practical problems with the current approach. > Doug C. From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 06:29:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0F1F16A421 for ; Fri, 21 Sep 2007 06:29:14 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 4B3A813C4A8 for ; Fri, 21 Sep 2007 06:29:14 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so639415nfb for ; Thu, 20 Sep 2007 23:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=JORExFdS7u5qYoH0YjRVa0Rt15UZ5XGCGGoHFTXb5cI=; b=Mc6ygWdwAp6Y/lWEnxBp9lYnQADw/vVZ+cKeUOuIzp/WhlQnmihSFzl7m14dJuPzDgTdePp6p8BVfKc7qXRUACEcxvATdEEuctm9E1/VrHTwQc+QQ5W46IqZ+pAKwlzDFFR/wa6x8gdICw35WCHPjrLv9AR9OHquXoth65C9cPA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cosuN38UEIw53TM1zTpiEPYcxAuJjhxgizpTkAoSvk0TNnc9hvCLxF20gmN4CF/Dd5RFXaagXunqtG6A51b70YCISgJlQK0hNbL9EzLcECFl3suhRQSky67oGnFM9hTNKSrlkVj5uFqTbY+9tQFiW645MwOsjSSDL9l1z5MfoWg= Received: by 10.78.193.19 with SMTP id q19mr1750605huf.1190354659990; Thu, 20 Sep 2007 23:04:19 -0700 (PDT) Received: by 10.78.166.18 with HTTP; Thu, 20 Sep 2007 23:04:19 -0700 (PDT) Message-ID: Date: Fri, 21 Sep 2007 08:04:19 +0200 From: "Claus Guttesen" To: "Borja Marcos" In-Reply-To: <4C4A3C06-A6F3-41B1-BE53-F04369CD4F8D@SARENET.ES> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5870F83F-7174-47AA-98AE-C1DE8972E0C8@SARENET.ES> <613318C3-6B66-4758-A0D4-97405D6A1914@SARENET.ES> <46F23166.8070908@FreeBSD.org> <4C4A3C06-A6F3-41B1-BE53-F04369CD4F8D@SARENET.ES> Cc: freebsd-current@freebsd.org Subject: Re: Memory allocation problems (ZFS/NFS/amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 06:29:14 -0000 > > I've just tried using the echo service from inetd, and the server > > is keeping 1024 established > > connections without that error. I just don't understand why this > > can fail with Apache, but it seems it's an issue with -current, as > > we have a similar setup with 6.2(i386), same hardware, and it works. > > Here's what I've found out. Apache was confgured by a different > person, and I didn't notice that the MaxClients parameter was set too > low (159). > > Setting it up to a high value (1024) has made those errors disappear. > So that "memory limit" was actually that the system was dropping > connection requests from the listen queue. The error message is quite > looks misleading to me. At least I had never seen it, so it caught me > by surprise. Thank you. I was planning to upgrade our file/samba server with current from June 11'th next week to get the latest enhancements related to zfs. And with 5 TB in use the last thing I needed was dropped connections. :-) -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 06:56:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DCB816A417 for ; Fri, 21 Sep 2007 06:56:57 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8EF13C46E for ; Fri, 21 Sep 2007 06:56:57 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 9D7CD2F2DF; Fri, 21 Sep 2007 02:41:22 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 21 Sep 2007 02:41:22 -0400 X-Sasl-enc: s58aGrQ53v42S4/E0a8+QCTOC+YFdibQkcTNp8knD5yc 1190356882 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id 153CA20A97; Fri, 21 Sep 2007 02:41:21 -0400 (EDT) Message-ID: <46F367E0.4000300@freebsd.org> Date: Thu, 20 Sep 2007 23:42:40 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: John Birrell References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> <20070920203413.GA13737@what-creek.com> In-Reply-To: <20070920203413.GA13737@what-creek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Olivier Warin , freebsd-current@freebsd.org Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 06:56:57 -0000 John Birrell wrote: > On Wed, Sep 19, 2007 at 11:34:19PM +0200, Olivier Warin wrote: > > I recently wanted to give dtrace on FreeBSD a try but found this > > project to be stopped due to a licensing issue. > > Will we see dtrace in the base just like zfs anytime (hopefully) soon ? > > I'm am currently trying to find a way around the licensing issues. > Sun is no help at all. The patent clauses in their CDDL are a big deal. > They claim that they don't want to sue anyone over patents, but > when push comes to shove they actually will. Refer to the Netapp > lawsuits. > > ... > DTrace consists mainly of kernel modules, however in order for DTrace > to inspect the kernel internals it has to have some code inside > existing BSD licensed files. > This should not be a problem. Code added to BSD licensed files should be BSD licensed. Darren From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 07:00:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D05116A420 for ; Fri, 21 Sep 2007 07:00:50 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.freebsd.org (Postfix) with ESMTP id 064C713C455 for ; Fri, 21 Sep 2007 07:00:49 +0000 (UTC) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 15C25732FF; Fri, 21 Sep 2007 07:03:48 +0000 (GMT) Date: Fri, 21 Sep 2007 07:03:48 +0000 From: John Birrell To: Darren Reed Message-ID: <20070921070347.GA17990@what-creek.com> References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> <20070920203413.GA13737@what-creek.com> <46F367E0.4000300@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F367E0.4000300@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Olivier Warin , freebsd-current@freebsd.org Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 07:00:50 -0000 On Thu, Sep 20, 2007 at 11:42:40PM -0700, Darren Reed wrote: > John Birrell wrote: > >DTrace consists mainly of kernel modules, however in order for DTrace > >to inspect the kernel internals it has to have some code inside > >existing BSD licensed files. > > > > This should not be a problem. > Code added to BSD licensed files should be BSD licensed. Only if it is clean-room coded. In the case of DTrace, the only reference is the OpenSolaris CDDL code. It's hard to claim something as BSD licensed when all you are really doing is adding stuff like: (part of struct thread) uintptr_t td_dtrace_pc; /* DTrace saved pc from fasttrap. */ uintptr_t td_dtrace_npc; /* DTrace next pc from fasttrap. */ uintptr_t td_dtrace_scrpc; /* DTrace per-thread scratch location. */ uintptr_t td_dtrace_astpc; /* DTrace return sequence location. */ u_int64_t td_hrtime; /* Last time on cpu. */ Sun still claims CDDL on snippets as simple as this (because the reference was CDDL'd). I had hoped they'd just say "that's OK to be BSD licensed". But, no, their attitude is that FreeBSD can just suck up Sun's patent clauses in the CDDL. I could just change the field names and re-arrange the words in the comments to make it look like I thought of it. But if that's OK by Sun's lawyers then they are just stupid. If they were to ask me in a court of law (in a proceeding like the ones SCO has been in), what would my answer be? Answer: I read the OpenSolaris code which is CDDL'd and I worked out what I had to add to FreeBSD and I added it. With vi. :-) -- John Birrell From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 07:12:30 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 496D516A417 for ; Fri, 21 Sep 2007 07:12:30 +0000 (UTC) (envelope-from sergei@FreeBSD.ORG) Received: from gondor.elendil.ru (gondor.elendil.ru [195.189.222.13]) by mx1.freebsd.org (Postfix) with ESMTP id 9DC5513C46A for ; Fri, 21 Sep 2007 07:12:29 +0000 (UTC) (envelope-from sergei@FreeBSD.ORG) Received: (qmail 93818 invoked by uid 1001); 21 Sep 2007 06:47:08 -0000 Date: Fri, 21 Sep 2007 10:47:08 +0400 From: Sergei Kolobov To: freebsd-current@FreeBSD.ORG, scf@FreeBSD.ORG Message-ID: <20070921064707.GB80642@gondor.elendil.ru> References: <200709201606.l8KG6B3C037902@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: <200709201606.l8KG6B3C037902@lurza.secnetix.de> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: /libexec/ld-elf.so.1: environment corrupt; missing value for X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 07:12:30 -0000 --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2007-09-20 at 18:06 +0200, Oliver Fromme wrote: > Sean C. Farley wrote: > > [...] zsh 4.3.4 has a bug where it was mixing calls > > to *env() functions with direct manipulation of environ. The CVS > > version of zsh is fixed. I created PR ports/115094[1] to patch it in > > the ports tree about a month ago. *nudging sergei* :) Oops - sorry, Sean! I must have overlooked it or something - will take care of it shortly. Thanks! > Will the PR be committed to the zsh port before the > branch of 7.0 is released? I think it is a rather > serious issue. Sure - absolutely. Sergei --neYutvxvOLaeuPCA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG82jpFOxuaTulNAERApjxAKCEf0Q2VmSqt3agVQtHJhFwotxGwwCfR5KR Cz3LHwcdgFRhXwIGo6Ff+wA= =Ycy/ -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 07:47:53 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17AE516A419; Fri, 21 Sep 2007 07:47:53 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2001:618:400::50b1:e8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 8121113C45B; Fri, 21 Sep 2007 07:47:52 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [80.177.232.250] (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id l8L7lnGW028050; Fri, 21 Sep 2007 08:47:49 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: John Birrell In-Reply-To: <20070921070347.GA17990@what-creek.com> References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> <20070920203413.GA13737@what-creek.com> <46F367E0.4000300@freebsd.org> <20070921070347.GA17990@what-creek.com> Content-Type: text/plain Date: Fri, 21 Sep 2007 08:47:48 +0100 Message-Id: <1190360869.1627.9.camel@herring.rabson.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/4355/Thu Sep 20 18:09:53 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: Darren Reed , Olivier Warin , freebsd-current@freebsd.org Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 07:47:53 -0000 On Fri, 2007-09-21 at 07:03 +0000, John Birrell wrote: > On Thu, Sep 20, 2007 at 11:42:40PM -0700, Darren Reed wrote: > > John Birrell wrote: > > >DTrace consists mainly of kernel modules, however in order for DTrace > > >to inspect the kernel internals it has to have some code inside > > >existing BSD licensed files. > > > > > > > This should not be a problem. > > Code added to BSD licensed files should be BSD licensed. > > Only if it is clean-room coded. > > In the case of DTrace, the only reference is the OpenSolaris > CDDL code. It's hard to claim something as BSD licensed when > all you are really doing is adding stuff like: > > (part of struct thread) > uintptr_t td_dtrace_pc; /* DTrace saved pc from fasttrap. */ > uintptr_t td_dtrace_npc; /* DTrace next pc from fasttrap. */ > uintptr_t td_dtrace_scrpc; > /* DTrace per-thread scratch location. */ > uintptr_t td_dtrace_astpc; > /* DTrace return sequence location. */ > u_int64_t td_hrtime; /* Last time on cpu. */ > > Sun still claims CDDL on snippets as simple as this (because the > reference was CDDL'd). > > I had hoped they'd just say "that's OK to be BSD licensed". > > But, no, their attitude is that FreeBSD can just suck up Sun's > patent clauses in the CDDL. > > I could just change the field names and re-arrange the words > in the comments to make it look like I thought of it. But if that's > OK by Sun's lawyers then they are just stupid. If they were to ask > me in a court of law (in a proceeding like the ones SCO has > been in), what would my answer be? Answer: I read the OpenSolaris > code which is CDDL'd and I worked out what I had to add to FreeBSD > and I added it. With vi. :-) For something like this example, I would suggest putting those fields in a separate structure declared in a CDDL licensed file and then embed that structure in our thread. I'm guessing not all of your problems are quite this tidy though. From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 07:48:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A48AB16A418 for ; Fri, 21 Sep 2007 07:48:56 +0000 (UTC) (envelope-from angelo@hongens.nl) Received: from krypton.hongens.local (cl-794.ams-05.nl.sixxs.net [IPv6:2001:610:600:319::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5EDF413C467 for ; Fri, 21 Sep 2007 07:48:56 +0000 (UTC) (envelope-from angelo@hongens.nl) Received: from localhost (localhost.hongens.local [127.0.0.1]) by krypton.hongens.local (Postfix) with ESMTP id 8B235BA50 for ; Fri, 21 Sep 2007 09:48:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at hongens.nl Received: from krypton.hongens.local ([127.0.0.1]) by localhost (krypton.hongens.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORMz8oqNNgjT for ; Fri, 21 Sep 2007 09:48:49 +0200 (CEST) Received: from ws05 (atwork-66.r-212.178.110.atwork.nl [212.178.110.66]) by krypton.hongens.local (Postfix) with ESMTP id 33806BA8D for ; Fri, 21 Sep 2007 09:48:49 +0200 (CEST) From: =?iso-8859-1?Q?Angel_H=F6ngens?= To: Date: Fri, 21 Sep 2007 09:48:45 +0200 Message-ID: <000b01c7fc23$d6ee60f0$84cb22d0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acf8I9aitcdEv/RvTy6AGKNtRsdPqw== Content-Language: en-us Subject: iscsi port in /etc/services? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 07:48:56 -0000 Hey guys, my first post here, so don't shoot me. (Don't know if this is = the right place to come with the question) I'm running RELENG_6 (built yesterday)m and after installing the iscsi-target from ports, I found that I could not get it started.. I = got the error "***ERROR*** getaddrinfo: servname not supported for = ai_socktype", which after googling for half an hour turns out to be a cryptic message meaning a service is not found in /etc/services. After getting a later version of /etc/services, the iscsi-target would start, but I was not able to connect using an initiator on another = machine. I then found out these ports in /etc/services: (apparently since rev = 1.112) iscsi 860/tcp iscsi 860/udp While my initiator expected to see port 3260. After some more googling, = I found out port 860 is a port to be used ONLY when in need of a system = TCP port number (?) but by default, port 3260 must be used: RFC3720 says: The well-known user TCP port number for iSCSI connections assigned by IANA is 3260 and this is the default iSCSI port. Implementations needing a system TCP port number may use port 860, the port assigned by IANA as the iSCSI system port; however in order to use port 860, it MUST be explicitly specified - implementations MUST NOT default to use of port 860, as 3260 is the only allowed default. Is this in error in /etc/services, or an error in my logic? Kind regards, Angelo H=F6ngens The Netherlands. From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 08:08:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB4CB16A417 for ; Fri, 21 Sep 2007 08:08:07 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.freebsd.org (Postfix) with ESMTP id CD36C13C48E for ; Fri, 21 Sep 2007 08:08:07 +0000 (UTC) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 006D373098; Fri, 21 Sep 2007 08:11:06 +0000 (GMT) Date: Fri, 21 Sep 2007 08:11:06 +0000 From: John Birrell To: Doug Rabson Message-ID: <20070921081106.GA18488@what-creek.com> References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> <20070920203413.GA13737@what-creek.com> <46F367E0.4000300@freebsd.org> <20070921070347.GA17990@what-creek.com> <1190360869.1627.9.camel@herring.rabson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1190360869.1627.9.camel@herring.rabson.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 08:08:08 -0000 On Fri, Sep 21, 2007 at 08:47:48AM +0100, Doug Rabson wrote: > For something like this example, I would suggest putting those fields in > a separate structure declared in a CDDL licensed file and then embed > that structure in our thread. I'm guessing not all of your problems are > quite this tidy though. Then it can't be in GENERIC by default. That cuts out one of the major DTrace features - you are supposed to be able to run DTrace at any time, even if it involves loading kernel modules (which Solaris does on demand). For the example I used, every thread has to have the space allocated even though the DTrace modules aren't loaded. And to do that it has to be entirely BSD licensed code. The DTrace modules themselves can be CDDL'd just like kernel modules may be GPL'd. So there can't be any include file tricks. If it's code that has to be in the GENERIC kernel, then all the headers have to be BSD licensed. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 08:14:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55DD616A420 for ; Fri, 21 Sep 2007 08:14:29 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2001:618:400::50b1:e8f2]) by mx1.freebsd.org (Postfix) with ESMTP id DA8C113C458 for ; Fri, 21 Sep 2007 08:14:28 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [80.177.232.250] (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id l8L8ERIh028174; Fri, 21 Sep 2007 09:14:27 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: John Birrell In-Reply-To: <20070921081106.GA18488@what-creek.com> References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> <20070920203413.GA13737@what-creek.com> <46F367E0.4000300@freebsd.org> <20070921070347.GA17990@what-creek.com> <1190360869.1627.9.camel@herring.rabson.org> <20070921081106.GA18488@what-creek.com> Content-Type: text/plain Date: Fri, 21 Sep 2007 09:14:27 +0100 Message-Id: <1190362467.1627.13.camel@herring.rabson.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/4356/Fri Sep 21 08:19:47 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 08:14:29 -0000 On Fri, 2007-09-21 at 08:11 +0000, John Birrell wrote: > On Fri, Sep 21, 2007 at 08:47:48AM +0100, Doug Rabson wrote: > > For something like this example, I would suggest putting those fields in > > a separate structure declared in a CDDL licensed file and then embed > > that structure in our thread. I'm guessing not all of your problems are > > quite this tidy though. > > Then it can't be in GENERIC by default. That cuts out one of the > major DTrace features - you are supposed to be able to run DTrace > at any time, even if it involves loading kernel modules (which > Solaris does on demand). > > For the example I used, every thread has to have the space allocated > even though the DTrace modules aren't loaded. And to do that it > has to be entirely BSD licensed code. The DTrace modules themselves > can be CDDL'd just like kernel modules may be GPL'd. So there > can't be any include file tricks. If it's code that has to be in the > GENERIC kernel, then all the headers have to be BSD licensed. I see your problem. How about adding a char td_dtrace_reserved[some number] which can be cast into a dtrace structure in dtrace code but which is opaque to normal kernel code? From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 09:12:49 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A669B16A469 for ; Fri, 21 Sep 2007 09:12:49 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 86A1A13C4A7 for ; Fri, 21 Sep 2007 09:12:44 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id C4A222EE4E; Fri, 21 Sep 2007 05:12:43 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 21 Sep 2007 05:12:43 -0400 X-Sasl-enc: vDjfWnp9Y5Gv6hMFFiBHyHv82cyt7AGbwWZH/iurH6vh 1190365963 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id 23BEB20AD0; Fri, 21 Sep 2007 05:12:43 -0400 (EDT) Message-ID: <46F38B59.9070707@freebsd.org> Date: Fri, 21 Sep 2007 02:14:01 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: John Birrell References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> <20070920203413.GA13737@what-creek.com> <46F367E0.4000300@freebsd.org> <20070921070347.GA17990@what-creek.com> In-Reply-To: <20070921070347.GA17990@what-creek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Olivier Warin , freebsd-current@freebsd.org Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 09:12:49 -0000 John Birrell wrote: > On Thu, Sep 20, 2007 at 11:42:40PM -0700, Darren Reed wrote: > > John Birrell wrote: > > >DTrace consists mainly of kernel modules, however in order for DTrace > > >to inspect the kernel internals it has to have some code inside > > >existing BSD licensed files. > > > > > > > This should not be a problem. > > Code added to BSD licensed files should be BSD licensed. > > Only if it is clean-room coded. > So find someone who hasn't read that email, write up a spec for the missing fields that dtrace requires and ask them to implement and commit the change to the dtrace branch on freebsd.org ? :) Darren From owner-freebsd-current@FreeBSD.ORG Thu Sep 20 22:00:44 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8866816A473 for ; Thu, 20 Sep 2007 22:00:44 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from webmail34.mail.yandex.net (webmail34.mail.yandex.net [213.180.223.183]) by mx1.freebsd.org (Postfix) with ESMTP id A160213C4A8 for ; Thu, 20 Sep 2007 22:00:43 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from YAMAIL (webmail34) by mail.yandex.ru id S2409091AbXITQBz for ; Thu, 20 Sep 2007 20:01:55 +0400 X-Yandex-Spam: 1 Received: from [91.122.49.58] ([91.122.49.58]) by mail.yandex.ru with HTTP; Thu, 20 Sep 2007 20:01:55 +0400 From: "S.N.Grigoriev" To: freebsd-current@freebsd.org MIME-Version: 1.0 Message-Id: <105091190304115@webmail34.yandex.ru> Date: Thu, 20 Sep 2007 20:01:55 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailman-Approved-At: Fri, 21 Sep 2007 09:39:15 +0000 Subject: Xorg 7.3 problem on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 22:00:44 -0000 Hi, list, I've upgraded to Xorg 7.3 my CURRENT amd64 machine (both source and port trees are fresh). All programs work correctly except for X session terminations. Every time I try to finish the current X session, the X server crashes with core dump (irrespective of how sessions were started with startx or xdm). Upgrades of X on 6.2 i386 machines do not introduce this problem. Does anybody know how this can be fixed? Thanks, Serguey. From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 07:04:46 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6274F16A41B for ; Fri, 21 Sep 2007 07:04:46 +0000 (UTC) (envelope-from petr.hroudny@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id DF00513C468 for ; Fri, 21 Sep 2007 07:04:45 +0000 (UTC) (envelope-from petr.hroudny@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so644234nfb for ; Fri, 21 Sep 2007 00:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=qVuhfMNZ8bSrnDuI4F+m8Cm5GSUHhg/DW31XlJP/1/I=; b=lBwQczuPo5wz0ThUQHNmjpEHI1GN7vUJ/yHe9ssWFUraYyhEHBgsUvmOaBg/tQ8Mvr1XDm9BZwUkpvb0CWMR4NSLwZJwzDBPvFbNYvPV9/BbzamHeKJ2UnxoQhtudglv3KjYIWSEzzLGXas+Z0p73GVKkygdYmORfKaLf0h1UNk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=opKZmOSxaAYAENdNXIhPn9Wde/0ZXaJIODflaGXEq50M75Xkw8QD263lonbLuLwA8dpz2P2khnXKOxea9qd+mfLyrbqbzUCrcntgm0erLL+TFy5W+3trrZiqjYmpQ6L7t9v2tsMqO25h3jZT0vBTlZT/xSPWpBOBPNZH8YJa3qY= Received: by 10.78.170.6 with SMTP id s6mr1762014hue.1190358284294; Fri, 21 Sep 2007 00:04:44 -0700 (PDT) Received: by 10.78.100.2 with HTTP; Fri, 21 Sep 2007 00:04:44 -0700 (PDT) Message-ID: Date: Fri, 21 Sep 2007 09:04:44 +0200 From: "=?UTF-8?Q?Petr_Hroudn=C3=BD?=" To: "Andrey Chernov" , "Taku YAMAMOTO" , "Petr Hroudn??" , current@freebsd.org, perky@freebsd.org, i18n@freebsd.org In-Reply-To: <20070921024107.GA21223@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070916192924.GA12678@nagual.pp.ru> <20070917092130.GA24424@nagual.pp.ru> <20070918020100.d43beb0b.taku@tackymt.homeip.net> <20070917171633.GA31179@nagual.pp.ru> <20070919111207.f37653fc.taku@tackymt.homeip.net> <20070919022555.GA70617@nagual.pp.ru> <20070919023625.GA70891@nagual.pp.ru> <20070919051830.GA72429@nagual.pp.ru> <20070919121024.GA81606@nagual.pp.ru> <20070921024107.GA21223@nagual.pp.ru> X-Mailman-Approved-At: Fri, 21 Sep 2007 09:39:15 +0000 Cc: Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 07:04:46 -0000 2007/9/21, Andrey Chernov : > On Wed, Sep 19, 2007 at 04:10:24PM +0400, Andrey Chernov wrote: > > Improved vesrsion. Intoduce general __mb_sch_limit parameter instead for > > all locales specifying upper limit of single char range. It allows also > > fix the bug when ctype(3) functions called with arg > 0xFF for wide > > character locales and simplifies all checks. New patch is attached. Here > > is updated rationale again: > > Next improved version, now optimized for speed. I decide to remove extra > _CTYPE_WID flag and duplicate needed functions instead. I believe your patch needs some adjustments for CJK charsets. You are setting __mb_sch_limit to 256 for all multibyte locales except UTF-8, but I believe it should be 128 also for Big5, GB18030, GBK. Regards, Petr From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 10:33:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53E2E16A468 for ; Fri, 21 Sep 2007 10:33:28 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: from mail1.slb.deg.dub.stisp.net (mail1.slb.deg.dub.stisp.net [84.203.253.98]) by mx1.freebsd.org (Postfix) with SMTP id A056113C467 for ; Fri, 21 Sep 2007 10:33:27 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: (qmail 8676 invoked from network); 21 Sep 2007 10:06:40 -0000 Received: from unknown (HELO holyman.cobbled.net) (84.203.180.117) by mail1.slb.deg.dub.stisp.net with SMTP; 21 Sep 2007 10:06:40 -0000 Received: by holyman.cobbled.net (Postfix, from userid 16385) id AEF3F16530; Fri, 21 Sep 2007 10:06:30 +0000 (UTC) Date: Fri, 21 Sep 2007 10:06:30 +0000 From: ttw+bsd@cobbled.net To: freebsd-current@freebsd.org Message-ID: <20070921100630.GA10718@holyman.cobbled.net> Mail-Followup-To: freebsd-current@freebsd.org, John Birrell , Olivier Warin , Darren Reed References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> <20070920203413.GA13737@what-creek.com> <46F367E0.4000300@freebsd.org> <20070921070347.GA17990@what-creek.com> <46F38B59.9070707@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46F38B59.9070707@freebsd.org> Cc: Darren Reed , Olivier Warin , John Birrell Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 10:33:28 -0000 On 21.09-02:14, Darren Reed wrote: [ ... ] > >Only if it is clean-room coded. > > So find someone who hasn't read that email, write up a spec for the missing > fields that dtrace requires and ask them to implement and commit the change > to the dtrace branch on freebsd.org ? :) this has merit. to be honest, within copyright (UK and EU), i think you could reasonably use structure definitions as they are fundamental to the interaction, not the operation of the code. this has support, though it's not been specifically ruled on in court (certainally not that i'm aware of). there is a much bigger problem around patents and no amount of clean room coding is going to avoid those. ... having said that, nethier is adding some secondary structure -- that is not how patent coverage works, only copyright. From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 11:03:08 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0833216A41A; Fri, 21 Sep 2007 11:03:08 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (unknown [IPv6:2001:b30:5000:2:20e:cff:fe4b:ca01]) by mx1.freebsd.org (Postfix) with ESMTP id 71FEF13C447; Fri, 21 Sep 2007 11:03:07 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 2E13150899; Fri, 21 Sep 2007 14:03:06 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on local.mail.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiHkHJdF6R8x; Fri, 21 Sep 2007 14:03:01 +0300 (EEST) Received: from [193.226.5.46] (hades.utcluj.ro [193.226.5.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id 4FFAD5089F; Fri, 21 Sep 2007 14:03:01 +0300 (EEST) Message-ID: <46F3A4E4.5030702@net.utcluj.ro> Date: Fri, 21 Sep 2007 14:03:00 +0300 From: Cristian KLEIN User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Jung-uk Kim References: <200709181516.11207.jkim@FreeBSD.org> <46F041BC.6070604@net.utcluj.ro> <200709181734.57392.jkim@FreeBSD.org> In-Reply-To: <200709181734.57392.jkim@FreeBSD.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [PATCH] OsdSynch.c modernization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 11:03:08 -0000 Jung-uk Kim wrote: > On Tuesday 18 September 2007 05:23 pm, Cristian KLEIN wrote: >> Jung-uk Kim wrote: >>> I have rewritten sys/dev/acpica/Osd/OsdSynch.c to match the >>> modern ACPI-CA and -CURRENT: >>> >>> http://people.freebsd.org/~jkim/acpica/OsdSynch.diff >>> >>> Major changes are: >>> >>> 1. Semaphore is reimplemented with convar(9) instead of mutex(9). >>> >>> 2. Semaphore with ACPI_WAIT_FOREVER option actually waits forever >>> now. >>> >>> 3. Obsolete and/or hidden debugging knobs and macros are removed. >>> >>> 4. ACPI-CA introduced AcpiOs*Mutex() to complement >>> AcpiOs*Semaphore(): >>> >>> http://bugzilla.kernel.org/show_bug.cgi?id=6634 >>> >>> These functions are implemented and turned on by default. >>> >>> 5. Spinlock is reimplemented with sx lock and more closely >>> implements the intended behaviour (e.g., save/restore >>> interrupts). >>> >>> It is orthogonal to Nate's effort of rewriting acpi_ec.c but I'd >>> like get more feedback *with* his last patch (revision D) because >>> his patch will be committed sooner or later. ;-) >>> >>> Please test/review and let us know if there is any regression or >>> not. >> Sorry for not being able to test the patch. May I assume this will >> fix: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=114113 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=114649 > > I believe my patch AND Nate's patch will fix the problem. Hi, I tested your patch and it works flawless. However, before applying your patch, the "recursive lock on non-recursive mutex" did not occur either. From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 12:52:08 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B49A16A469 for ; Fri, 21 Sep 2007 12:52:08 +0000 (UTC) (envelope-from hopet@ics.muni.cz) Received: from minas.ics.muni.cz (minas.ics.muni.cz [147.251.4.40]) by mx1.freebsd.org (Postfix) with ESMTP id 85A8D13C4A3 for ; Fri, 21 Sep 2007 12:52:07 +0000 (UTC) (envelope-from hopet@ics.muni.cz) Received: from KLOBOUCEK (kloboucek.ics.muni.cz [147.251.3.38]) (authenticated user=hopet@ICS.MUNI.CZ bits=0) by minas.ics.muni.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id l8LBnHvw004823 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 21 Sep 2007 13:49:18 +0200 From: "Petr Holub" To: Date: Fri, 21 Sep 2007 13:49:19 +0200 Message-ID: <002c01c7fc45$717e6400$5317fb93@KLOBOUCEK> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Muni-Spam-TestIP: 147.251.3.38 X-Muni-Envelope-From: hopet@ics.muni.cz X-Muni-Envelope-To: current@freebsd.org X-Muni-Virus-Test: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (minas.ics.muni.cz [147.251.4.35]); Fri, 21 Sep 2007 13:49:18 +0200 (CEST) X-Mailman-Approved-At: Fri, 21 Sep 2007 13:31:23 +0000 Cc: Subject: TCP socket problem on Sept. -CURRENT snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 12:52:08 -0000 Hi, I've encountered the following problem while building xorg from ports: TCP: [134.76.12.3]:21 to [147.251.54.186]:56914 tcpflags 0x18; tcp_do_ segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo ving tcpcb TCP: [134.76.12.3]:21 to [147.251.54.186]:62424 tcpflags 0x18; tcp_do_ segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo ving tcpcb TCP: [134.76.12.3]:21 to [147.251.54.186]:55989 tcpflags 0x18; tcp_do_ segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo ving tcpcb TCP: [134.76.12.3]:21 to [147.251.54.186]:52923 tcpflags 0x18; tcp_do_ segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo ving tcpcb It occurred from several different addresses and results in being unable event to ping that IP until reboot. Petr From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 13:51:06 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8229016A417 for ; Fri, 21 Sep 2007 13:51:06 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 715B313C45A for ; Fri, 21 Sep 2007 13:51:06 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 204631CC02A; Fri, 21 Sep 2007 06:33:16 -0700 (PDT) Date: Fri, 21 Sep 2007 06:33:16 -0700 From: Jeremy Chadwick To: Petr Holub Message-ID: <20070921133316.GA63294@eos.sc1.parodius.com> References: <002c01c7fc45$717e6400$5317fb93@KLOBOUCEK> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002c01c7fc45$717e6400$5317fb93@KLOBOUCEK> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org Subject: Re: TCP socket problem on Sept. -CURRENT snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 13:51:06 -0000 On Fri, Sep 21, 2007 at 01:49:19PM +0200, Petr Holub wrote: > Hi, > > I've encountered the following problem while building xorg from > ports: > > TCP: [134.76.12.3]:21 to [147.251.54.186]:56914 tcpflags 0x18; tcp_do_ > segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo > ving tcpcb > TCP: [134.76.12.3]:21 to [147.251.54.186]:62424 tcpflags 0x18; tcp_do_ > segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo > ving tcpcb > TCP: [134.76.12.3]:21 to [147.251.54.186]:55989 tcpflags 0x18; tcp_do_ > segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo > ving tcpcb > TCP: [134.76.12.3]:21 to [147.251.54.186]:52923 tcpflags 0x18; tcp_do_ > segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo > ving tcpcb > > It occurred from several different addresses and results in being > unable event to ping that IP until reboot. This is "normal" for the current time being, as the output in question is being used to help track down a TCP-related bug in -CURRENT: http://lists.freebsd.org/pipermail/freebsd-current/2007-August/075984.html If the log messages annoy you, set the following sysctl. net.inet.tcp.log_debug=0 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 15:34:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB03A16A41A for ; Fri, 21 Sep 2007 15:34:17 +0000 (UTC) (envelope-from reinhard.haller@interactive-net.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2001F13C45B for ; Fri, 21 Sep 2007 15:34:17 +0000 (UTC) (envelope-from reinhard.haller@interactive-net.de) Received: from [217.225.220.205] (helo=interactive.dnsalias.net) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1IYkWF04qP-0000mP; Fri, 21 Sep 2007 17:34:16 +0200 Received: from fs-inter.interactive.de ([192.168.0.1]) by interactive.dnsalias.net with smtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IYkWE-0001r3-15 for freebsd-current@freebsd.org; Fri, 21 Sep 2007 17:34:14 +0200 Received: from [192.168.0.75] (core2duo.interactive.de [192.168.0.75]) by fs-inter.interactive.de; Fri, 21 Sep 2007 17:33:36 +0200 Message-ID: <46F3E45C.3010907@interactive-net.de> Date: Fri, 21 Sep 2007 17:33:48 +0200 From: Reinhard Haller User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------060608030206020906070905" X-ACL-rcpt: freebsd-current@freebsd.org X-ACL-Send: reinhard.haller@interactive-net.de X-Provags-ID: V01U2FsdGVkX1/08qSPe+5JReQvN4YFbeqZbPSx3UoJCPEB8jL dT8M2MdRClnBJ9Kjzv8/yAEWQ81MNko6ib0k6SfwrnPQWWK+5D mlhProkXkSBu80jhxvSBg== X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: amd64-current em, fxp, nfe partially broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 15:34:17 -0000 This is a multi-part message in MIME format. --------------060608030206020906070905 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi, I've set up a box (ASUS V3-M2NC61S, AMD Athlon 4400+) with freebsd 7.0 current amd64. Even with gcc 4.2.1 20070719 none of the nic's is able to communicate to a Linksys WRVS4400N wireless router. I've tested the em and fxp nics on a freebsd 7.0 current i386 (Pentium III/500) and they worked as expected, also the builtin nfe under Windows. The problem is not limited to the Linksys router (auto negotiation, 1000baseTX, 100BaseTX), my notebook (connected by a crossover cable) with a builtin RTL 8168/8111 nic under Vista has similar problems. Even by connecting my amd64 box and the Linksys to a 10/100 switch there is no communication possible. Any suggestions? Thanks Reinhard Haller ------------------------------------------------------------------------------- Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #8: Thu Sep 20 14:07:10 CEST 2007 root@firewall.interactive.de:/usr/obj/usr/src/sys/FIREWALL WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (2310.67-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb1 Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 2103508992 (2006 MB) avail memory = 2030026752 (1935 MB) ACPI APIC Table: <_ASUS_ Notebook> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <_ASUS_ Notebook> on motherboard acpi0: [ITHREAD] acpi_hpet0: iomem 0xfefff000-0xfefff3ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 acpi0: Power Button (fixed) acpi0: reservation of fefff000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7dde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: 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) ohci0: mem 0xfe02f000-0xfe02ffff irq 23 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 8 ports with 8 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 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: 8 ports with 8 removable, self powered pcib1: at device 4.0 on pci0 pci1: on pcib1 fxp0: port 0xcc00-0xcc3f mem 0xfdfff000-0xfdffffff,0xfde00000-0xfdefffff irq 17 at device 8.0 on pci1 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:d0:b7:16:8a:3d fxp0: [ITHREAD] em0: port 0xc800-0xc83f mem 0xfdfc0000-0xfdfdffff,0xfdfa0000-0xfdfbffff irq 18 at device 9.0 on pci1 em0: Ethernet address: 00:1b:21:07:11:65 em0: [FILTER] pci0: at device 5.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] nfe0: port 0xec00-0xec07 mem 0xfe02d000-0xfe02dfff irq 22 at device 7.0 on pci0 miibus1: on nfe0 rlphy0: PHY 1 on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nfe0: Ethernet address: 00:1a:92:4b:b2:27 nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xfe02c000-0xfe02cfff irq 20 at device 8.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pcib2: at device 9.0 on pci0 pci2: on pcib2 pcib3: at device 11.0 on pci0 pci3: on pcib3 pcib4: at device 12.0 on pci0 pci4: on pcib4 vgapci0: mem 0xfb000000-0xfbffffff,0xe0000000-0xefffffff,0xfc000000-0xfcffffff irq 23 at device 13.0 on pci0 acpi_tz0: on acpi0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] 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 MouseMan+, device ID 0 cryptosoft0: on motherboard orm0: at iomem 0xd0000-0xd0fff,0xd1000-0xd1fff on isa0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> Timecounters tick every 1.000 msec Fast IPsec: Initialized Security Association Processing. ad4: 238475MB at ata2-master SATA300 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad4s1a em0: link state changed to UP lock order reversal: 1st 0xffffffff80768dc8 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0xffffffff8076a488 udp (udp) @ /usr/src/sys/contrib/pf/net/pf.c:2970 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x64b _mtx_lock_flags() at _mtx_lock_flags+0x75 pf_socket_lookup() at pf_socket_lookup+0x23f pf_test_udp() at pf_test_udp+0x89a pf_test() at pf_test+0xf9d pf_check_in() at pf_check_in+0x2b pfil_run_hooks() at pfil_run_hooks+0xc0 ip_input() at ip_input+0x321 ether_demux() at ether_demux+0x1d9 ether_input() at ether_input+0x21d fxp_intr() at fxp_intr+0x1e4 ithread_loop() at ithread_loop+0xe0 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffab9ebd30, rbp = 0 --- --------------060608030206020906070905-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 15:40:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 418FC16A41B for ; Fri, 21 Sep 2007 15:40:06 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from mail.renet.ru (mail-local.renet.ru [82.116.32.21]) by mx1.freebsd.org (Postfix) with ESMTP id 94BC513C458 for ; Fri, 21 Sep 2007 15:40:04 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from localhost (dcss-08.dialup.virtual.int [172.19.101.8]) by mail.renet.ru (8.14.0/8.14.0) with ESMTP id l8LFdlWX038691; Fri, 21 Sep 2007 19:39:49 +0400 (MSD) (envelope-from novel@FreeBSD.org) Date: Fri, 21 Sep 2007 19:40:33 +0400 From: Roman Bogorodskiy To: Jeff Roberson Message-ID: <20070921154033.GA46811@underworld.novel.ru> References: <20070916061932.GA93480@underworld.novel.ru> <20070915234855.G531@10.0.0.1> <20070916071421.GA1320@underworld.novel.ru> <20070916003323.U4507@10.0.0.1> <20070917044351.GA17565@underworld.novel.ru> <20070917162400.GA42669@underworld.novel.ru> <20070917141820.M558@10.0.0.1> <20070918155244.GA1336@underworld.novel.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <20070918155244.GA1336@underworld.novel.ru> X-PGP: http://people.freebsd.org/~novel/novel.key.asc Cc: freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 15:40:06 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here's what I got today: http://people.freebsd.org/~novel/misc/out.tar.bz2 I run this command when x11 windows became to take quite a long to redraw (several seconds). Though it's not the worst thing I got, so I will drop a mail as soon as I will be able to 'catch' harder 'freeze'. Roman Bogorodskiy --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iQCVAwUBRvPl8YB0WzgdqspGAQKF8gP9EJw2xqvF+Zw+VaiCo0igVm07LUwfo/A3 twDAMxb81NLJrjgV4ZTbEYCso4TTQpkUEJqYs7EWY2DCLtkYYHzYlVKck8csWMAJ TQEOfEOhyPxKTHxuLSzeUUhyiwhCHnWHGh8/7R4McbkLpWWYFBOMqDDKojZ29tzk VM7WsiAFv6w= =XNwo -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 15:47:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA06F16A419 for ; Fri, 21 Sep 2007 15:47:42 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id C840713C44B for ; Fri, 21 Sep 2007 15:47:42 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from adsl-69-149-117-186.dsl.austtx.swbell.net ([69.149.117.186]:62817 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IYkUU-000MiG-0u for freebsd-current@freebsd.org; Fri, 21 Sep 2007 10:32:37 -0500 Date: Fri, 21 Sep 2007 10:32:23 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-current@freebsd.org Message-ID: <20070921102946.T11189@borg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -3.3 (---) X-LERCTR-Spam-Score: -3.3 (---) X-Spam-Report: SpamScore (-3.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1 X-LERCTR-Spam-Report: SpamScore (-3.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1 DomainKey-Status: no signature Subject: panic: kmem_malloc(131072): kmem_map too small (AMD64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 15:47:43 -0000 I'm a heavy ZFS user, and got the following panic on 2007-09-18 source/world: # kgdb -c vmcore.1 /usr/obj/usr/src/sys/BORG/kernel.debug [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: panic: kmem_malloc(131072): kmem_map too small: 333647872 total allocated cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17a kmem_malloc() at kmem_malloc+0x49a uma_large_malloc() at uma_large_malloc+0x4a malloc() at malloc+0x12d arc_get_data_buf() at arc_get_data_buf+0x36e arc_buf_alloc() at arc_buf_alloc+0xe4 arc_read() at arc_read+0xfa dbuf_prefetch() at dbuf_prefetch+0x137 dmu_zfetch_dofetch() at dmu_zfetch_dofetch+0xd4 dmu_zfetch() at dmu_zfetch+0x616 dbuf_read() at dbuf_read+0x31f dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0xe9 dmu_buf_hold_array() at dmu_buf_hold_array+0x62 dmu_read_uio() at dmu_read_uio+0x3f zfs_freebsd_read() at zfs_freebsd_read+0x576 vn_read() at vn_read+0x17a dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x1ce Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x80158835c, rsp = 0x7fffff9fd058, rbp = 0 --- Uptime: 2d6h22m6s Physical memory: 4085 MB Dumping 1305 MB: 1290 1274 1258 1242 1226 1210 1194 1178 1162 1146 1130 1114 1098 1082 1066 1050 1034 1018 1002 986 970 954 938 922 906 890 874 858 842 826 810 794 778 762 746 730 714 698 682 666 650 634 618 602 586 570 554 538 522 506 490 474 458 442 426 410 394 378 362 346 330 314 298 282 266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 #0 doadump () at pcpu.h:194 194 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:194 #1 0xffffffff802e3c65 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xffffffff802e40d7 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xffffffff804d138a in kmem_malloc (map=0xffffff00010000f8, size=131072, flags=2) at /usr/src/sys/vm/vm_kern.c:305 #4 0xffffffff804ca53a in uma_large_malloc (size=131072, wait=2) at /usr/src/sys/vm/uma_core.c:2709 #5 0xffffffff802d65ed in malloc (size=131072, mtp=0xffffffff8095f5c0, flags=2) at /usr/src/sys/kern/kern_malloc.c:364 #6 0xffffffff80900a8e in ?? () #7 0x000000000000a125 in ?? () #8 0xffffff00180f90f0 in ?? () #9 0xffffff00046fa000 in ?? () #10 0xffffff006cc14898 in ?? () #11 0x0000000000020000 in ?? () #12 0xffffff00046fa000 in ?? () #13 0xffffffffb243c4f0 in ?? () #14 0xffffffff80900ca4 in ?? () #15 0x0000000000000000 in ?? () #16 0xffffffff94cd1d00 in ?? () #17 0x0000000000000070 in ?? () #18 0x0000000000000000 in ?? () #19 0xffffffffb243c580 in ?? () #20 0xffffffff80901bda in ?? () #21 0xffffffffb243c5e0 in ?? () #22 0xffffffff802eb070 in _sx_xunlock (sx=0xffffffff809633c0, file=0x20000
, line=403673328) ---Type to continue, or q to quit--- at /usr/src/sys/kern/kern_sx.c:309 Previous frame inner to this frame (corrupt stack?) (kgdb) I have the core available, and am more than willing to give access to the box. I'm not sure exactly what may have triggered it, but this is the first ZFS panic I've seen. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 16:13:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE57516A417 for ; Fri, 21 Sep 2007 16:13:46 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 9443213C447 for ; Fri, 21 Sep 2007 16:13:46 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l8LGDh5t025026; Fri, 21 Sep 2007 10:13:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46F3EDB7.4060502@samsco.org> Date: Fri, 21 Sep 2007 10:13:43 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Larry Rosenman References: <20070921102946.T11189@borg> In-Reply-To: <20070921102946.T11189@borg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 21 Sep 2007 10:13:43 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: panic: kmem_malloc(131072): kmem_map too small (AMD64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 16:13:46 -0000 Larry Rosenman wrote: > I'm a heavy ZFS user, and got the following panic on 2007-09-18 > source/world: > [...] > > I have the core available, and am more than willing to give access to > the box. > > I'm not sure exactly what may have triggered it, but this is the first > ZFS panic I've seen. > > > I bet this is probably due to the recent change to the way small memory allocations are accounted for. Nothing has actually changed in memory usage, it's just that it's being counted much more accurately now. I had forgotten that there was such a low limit on the KMEM_MAP size on amd64. I think it should probably be raised significantly for the release (assuming that doing so doesn't screw up auto-sizing other maps). Scott From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 17:30:11 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C617F16A421 for ; Fri, 21 Sep 2007 17:30:11 +0000 (UTC) (envelope-from SRS0=d0c8b9c90915d0208f62c239425c5d64ac37ac8e=465=es.net=oberman@es.net) Received: from postal1.es.net (postal2.es.net [IPv6:2001:400:14:3::7]) by mx1.freebsd.org (Postfix) with ESMTP id 531E413C458 for ; Fri, 21 Sep 2007 17:30:11 +0000 (UTC) (envelope-from SRS0=d0c8b9c90915d0208f62c239425c5d64ac37ac8e=465=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id AAZ75704; Fri, 21 Sep 2007 10:30:04 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id DD21E45027; Fri, 21 Sep 2007 10:30:03 -0700 (PDT) To: "Constantine A. Murenin" In-Reply-To: Your message of "Thu, 20 Sep 2007 23:44:58 EDT." <46F33E3A.8010508@FreeBSD.org> Mime-Version: 1.0 Date: Fri, 21 Sep 2007 10:30:03 -0700 From: "Kevin Oberman" Message-Id: <20070921173003.DD21E45027@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; ; ; X-Sender: X-To_Name: Constantine A. Murenin X-To_Domain: freebsd.org X-To: "Constantine A. Murenin" X-To_Email: cnst@FreeBSD.org X-To_Alias: cnst Content-Type: application/pgp-signature X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@FreeBSD.org, Alexander Leidinger , Shteryana Shopova , Doug Barton Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 17:30:11 -0000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG8/+bkn3rs5h7N1ERAmDXAJ9EAeHwZ4QmrgaZhbM+56K80/pdFACfVrwn mRrkZ/AzGz4cYN6rAoJaeP4= =tp+d -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 17:32:16 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C9BB16A468 for ; Fri, 21 Sep 2007 17:32:16 +0000 (UTC) (envelope-from SRS0=d0c8b9c90915d0208f62c239425c5d64ac37ac8e=465=es.net=oberman@es.net) Received: from postal1.es.net (postal2.es.net [IPv6:2001:400:14:3::7]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2D713C478 for ; Fri, 21 Sep 2007 17:32:15 +0000 (UTC) (envelope-from SRS0=d0c8b9c90915d0208f62c239425c5d64ac37ac8e=465=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id AAB30413; Fri, 21 Sep 2007 10:32:13 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 54CAE4502A; Fri, 21 Sep 2007 10:32:11 -0700 (PDT) To: Doug Barton In-Reply-To: Your message of "Thu, 20 Sep 2007 16:12:13 PDT." Mime-Version: 1.0 Date: Fri, 21 Sep 2007 10:32:11 -0700 From: "Kevin Oberman" Message-Id: <20070921173211.54CAE4502A@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; ; ; X-Sender: X-To_Name: Doug Barton X-To_Domain: freebsd.org X-To: Doug Barton X-To_Email: dougb@FreeBSD.org X-To_Alias: dougb Content-Type: application/pgp-signature X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Leidinger , Shteryana Shopova , freebsd-current@FreeBSD.org, "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 17:32:16 -0000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG9AAbkn3rs5h7N1ERAigpAKCL5HszEL4Lk9KmBmEJ1mZJC5TYfwCgr+fP 55K+sINNCmywv6M3AVRwLT4= =2IsP -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 17:39:47 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D06316A41A for ; Fri, 21 Sep 2007 17:39:47 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 36EDC13C4AA for ; Fri, 21 Sep 2007 17:39:47 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l8LHcTR8044165 for ; Fri, 21 Sep 2007 10:38:29 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l8LHcTsM044164 for current@freebsd.org; Fri, 21 Sep 2007 10:38:29 -0700 (PDT) (envelope-from rizzo) Date: Fri, 21 Sep 2007 10:38:29 -0700 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20070921103829.A43801@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: Why USB must be so hard to use ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 17:39:47 -0000 i recently tried to attach one of the Openbeacon USB devices http://wiki.openbeacon.org/wiki/OpenBeacon_USB to a -stable box, and "of course" attach failed, even though the same thing is claimed to work right away on Linux and XP without any special driver. It wasn't too hard to convince umodem.c to attach to the device, but i had to put the ids in the list of devices explicitly recognised, and further disable the extra check for capabilities at the end of umodem.c::USB_MATCH (or umodem_match in -current). The device itself returns a class UICLASS_CDC, but subclass and protocol are 0, i.e. this is a very basic serial device as probably many gadget we are going to see in the future. Now i wonder: why dealing with usb peripherals in FreeBSD must be so hard, and nothing works out of the box ? In many cases it is really because we are too strict in making checks, or because our system to embed device IDs in the driver is unaccessible to the average user/sysadmin. Can we try to relax a bit the checks in the code (inherited from some other BSD) that probes peripherals so it is more tolerant to small differences in the features of peripherals, and provides an easier way to tweak device tables ? Over the last year, once i have gathered a bit more familiarity with the USB code, i managed to make a number of peripherals (cameras, scanners, various usb memory or mp3 players) work on FreeBSD and in several cases it was just a matter of a few lines of code. Hopefully, my patches are going in the tree in some way (linux_kmod_compat) or another (patches waiting to be committed), but the process is slow because, I suppose, all of us are still a bit nervous about relaxing checks in the code. I understand being careful, but if we keep being so strict in what our driver accept (and sometimes i wonder if they ever worked on more than a single specific device!) FreeBSD will get a reputation for having an unusable USB subsystem, and this drives away many workstation users. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 17:49:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7903716A41B for ; Fri, 21 Sep 2007 17:49:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 342D813C46A for ; Fri, 21 Sep 2007 17:49:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 21 Sep 2007 10:38:16 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id B1081126473; Fri, 21 Sep 2007 10:38:15 -0700 (PDT) Message-ID: <46F40188.4060408@elischer.org> Date: Fri, 21 Sep 2007 10:38:16 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: John Birrell References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> <20070920203413.GA13737@what-creek.com> <46F367E0.4000300@freebsd.org> <20070921070347.GA17990@what-creek.com> In-Reply-To: <20070921070347.GA17990@what-creek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Darren Reed , Olivier Warin , freebsd-current@freebsd.org Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 17:49:30 -0000 John Birrell wrote: > On Thu, Sep 20, 2007 at 11:42:40PM -0700, Darren Reed wrote: >> John Birrell wrote: >>> DTrace consists mainly of kernel modules, however in order for DTrace >>> to inspect the kernel internals it has to have some code inside >>> existing BSD licensed files. >>> >> This should not be a problem. >> Code added to BSD licensed files should be BSD licensed. > > Only if it is clean-room coded. > > In the case of DTrace, the only reference is the OpenSolaris > CDDL code. It's hard to claim something as BSD licensed when > all you are really doing is adding stuff like: > > (part of struct thread) > uintptr_t td_dtrace_pc; /* DTrace saved pc from fasttrap. */ > uintptr_t td_dtrace_npc; /* DTrace next pc from fasttrap. */ > uintptr_t td_dtrace_scrpc; > /* DTrace per-thread scratch location. */ > uintptr_t td_dtrace_astpc; > /* DTrace return sequence location. */ > u_int64_t td_hrtime; /* Last time on cpu. */ > > Sun still claims CDDL on snippets as simple as this (because the > reference was CDDL'd). > > I had hoped they'd just say "that's OK to be BSD licensed". > > But, no, their attitude is that FreeBSD can just suck up Sun's > patent clauses in the CDDL. > > I could just change the field names and re-arrange the words > in the comments to make it look like I thought of it. But if that's > OK by Sun's lawyers then they are just stupid. If they were to ask > me in a court of law (in a proceeding like the ones SCO has > been in), what would my answer be? Answer: I read the OpenSolaris > code which is CDDL'd and I worked out what I had to add to FreeBSD > and I added it. With vi. :-) they can't copyright the names to the variables. you don't need the same comments. Personally I thing they wouldn't have a leg to stand on.. sounds like "fair use" to me. > > > -- > John Birrell > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 17:56:53 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8952316A418 for ; Fri, 21 Sep 2007 17:56:53 +0000 (UTC) (envelope-from SRS0=d0c8b9c90915d0208f62c239425c5d64ac37ac8e=465=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 0FAF113C474 for ; Fri, 21 Sep 2007 17:56:50 +0000 (UTC) (envelope-from SRS0=d0c8b9c90915d0208f62c239425c5d64ac37ac8e=465=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id AAZ55545; Fri, 21 Sep 2007 10:56:45 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C5A4245027; Fri, 21 Sep 2007 10:56:44 -0700 (PDT) To: Doug Barton In-Reply-To: Your message of "Thu, 20 Sep 2007 16:12:13 PDT." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1190397404_67439P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 21 Sep 2007 10:56:44 -0700 From: "Kevin Oberman" Message-Id: <20070921175644.C5A4245027@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; ; ; X-Sender: X-To_Name: Doug Barton X-To_Domain: freebsd.org X-To: Doug Barton X-To_Email: dougb@FreeBSD.org X-To_Alias: dougb Cc: Alexander Leidinger , Shteryana Shopova , freebsd-current@FreeBSD.org, "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 17:56:53 -0000 --==_Exmh_1190397404_67439P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Thu, 20 Sep 2007 16:12:13 -0700 (PDT) > From: Doug Barton > Sender: owner-freebsd-current@freebsd.org > > On Wed, 19 Sep 2007, Constantine A. Murenin wrote: > > > Thanks for testing! > > Glad to help. In case it's interesting, I was doing the xorg update with > portmaster last night and I got several "PROCHOT asserted" messages on my > console at different times. I'm assuming that's expected behavior, just > curious if it's something bad, as in when that happens it's time to turn > off the laptop? (I didn't seem them when the happened, they were there > when I got back to check on the compiling.) > > >> Two small comments about the rc.d stuff. First, the empty _flags variable > >> in defaults/rc.conf should be commented out. Second, the rc.d > > > > How so? I don't see any other empty _flags variables in defaults/rc.conf > > being commented out. > > Well you missed named_flags. :) But seriously, I didn't realize that > things had gotten quite so out of hand with that ... never mind then. > > >> script needs the shutdown KEYWORD. > > > > Similarly, I don't see why this is needed -- it was not used by the scripts > > on which this script was based on > > Which scripts? I realize that a distressingly large number of scripts that > start services don't have this keyword, but they should. I'll work on a > patch for that. At the same time, we don't want to add any new scripts > that make the same mistake. > > > Reading through rc(8) doesn't seem to suggest that this keyword would > > actually be applicable here. > > As far as I can tell, you're starting a daemon, which means that it should > be cleanly shut down when the system exits. I've now read rcorder(8) and rc(8). I am very unclear what the significance of the shutdown keyword is. I thought it was to cause rc.shutdown to invoke a "stop" at shutdown time, but only 11 of the scripts in /etc/rc.d include the shutdown keyword. They do include most of the daemons which look likely to really need to be shut down (e.g. random, mixer, nfsd, inetd, auditd), but it is missing from a number of others. I think 'shutdown' might belong in others, but, if a 'kill -9' does the same thing as a 'stop' operation for a given daemon, it might be better to not have 'shutdown' to avoid having a hung daemon delay the shutdown. The reality is that it looks like it is usually done right and I don't see any real reason for 'shutdown' in this case. Feel free to call me a fool. I don't claim to -- 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_1190397404_67439P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG9AXckn3rs5h7N1ERAqiLAKCRM4EpCZipreoD1IYHH7kRwFqPWwCfXmZV 2pFlI5F57cMjT+3jwaa6Sjk= =qIz2 -----END PGP SIGNATURE----- --==_Exmh_1190397404_67439P-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 18:02:30 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E27A16A418; Fri, 21 Sep 2007 18:02:30 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA4513C459; Fri, 21 Sep 2007 18:02:28 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.1/8.14.1) with ESMTP id l8LI2QQD038792; Fri, 21 Sep 2007 22:02:26 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1190397746; bh=5Od60kz9Fs4Njw3ZHpOwuCDDQCmJgFuonPN7Yva 51CE=; l=14788; h=Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent; b=EQ0+MQR4lC6Hg16/6cUh TVqM9xuEd2/aq9bgQ4EZPk650E5JO52EqHbXlpnw/UiuxkJdzyn2/TSYE4eIvWO/UUn AUY7hSjBKc0KLaJpvgrmurV4DIcysb/nyNQHkZ/JlmVQ+NOSO5xljiKDU5UyyUQsKiE m33OiA77tbfI9ONv8= Received: (from ache@localhost) by nagual.pp.ru (8.14.1/8.14.1/Submit) id l8LI2O5L038791; Fri, 21 Sep 2007 22:02:24 +0400 (MSD) (envelope-from ache) Date: Fri, 21 Sep 2007 22:02:23 +0400 From: Andrey Chernov To: Petr Hroudn?? Message-ID: <20070921180223.GA38675@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Petr Hroudn?? , Taku YAMAMOTO , current@freebsd.org, perky@freebsd.org, i18n@freebsd.org References: <20070917092130.GA24424@nagual.pp.ru> <20070918020100.d43beb0b.taku@tackymt.homeip.net> <20070917171633.GA31179@nagual.pp.ru> <20070919111207.f37653fc.taku@tackymt.homeip.net> <20070919022555.GA70617@nagual.pp.ru> <20070919023625.GA70891@nagual.pp.ru> <20070919051830.GA72429@nagual.pp.ru> <20070919121024.GA81606@nagual.pp.ru> <20070921024107.GA21223@nagual.pp.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Taku YAMAMOTO , i18n@freebsd.org, current@freebsd.org, perky@freebsd.org Subject: Re: Ctype patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 18:02:30 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 21, 2007 at 09:04:44AM +0200, Petr Hroudn?? wrote: > I believe your patch needs some adjustments for CJK charsets. You are setting > __mb_sch_limit to 256 for all multibyte locales except UTF-8, but I believe it > should be 128 also for Big5, GB18030, GBK. For GB2312 too. Thanx for pointing out, here is adjusted patch. And __mb_sch_limit renamed to _mb_sb_limit to better match functions prefix. -- http://ache.pp.ru/ --LQksG6bCIzRHxTLp Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ctype.patch" --- Symbol.map.old 2007-09-19 22:37:21.000000000 +0400 +++ Symbol.map 2007-09-21 21:52:23.000000000 +0400 @@ -60,12 +60,17 @@ nextwctype; nl_langinfo; __maskrune; + __sbmaskrune; __istype; + __sbistype; __isctype; __toupper; + __sbtoupper; __tolower; + __sbtolower; __wcwidth; __mb_cur_max; + __mb_sb_limit; rpmatch; ___runetype; setlocale; --- _ctype.h.old 2007-09-16 21:13:59.000000000 +0400 +++ _ctype.h 2007-09-21 21:44:31.000000000 +0400 @@ -87,6 +87,8 @@ #define __inline #endif +extern int __mb_sb_limit; + /* * Use inline functions if we are allowed to and the compiler supports them. */ @@ -103,15 +105,28 @@ } static __inline int +__sbmaskrune(__ct_rune_t _c, unsigned long _f) +{ + return (_c < 0 || _c >= __mb_sb_limit) ? 0 : + _CurrentRuneLocale->__runetype[_c] & _f; +} + +static __inline int __istype(__ct_rune_t _c, unsigned long _f) { return (!!__maskrune(_c, _f)); } static __inline int +__sbistype(__ct_rune_t _c, unsigned long _f) +{ + return (!!__sbmasksrune(_c, _f)); +} + +static __inline int __isctype(__ct_rune_t _c, unsigned long _f) { - return (_c < 0 || _c >= _CACHED_RUNES) ? 0 : + return (_c < 0 || _c >= __mb_sb_limit) ? 0 : !!(_DefaultRuneLocale.__runetype[_c] & _f); } @@ -123,12 +138,26 @@ } static __inline __ct_rune_t +__sbtoupper(__ct_rune_t _c) +{ + return (_c < 0 || _c >= __mb_sb_limit) ? _c : + _CurrentRuneLocale->__mapupper[_c]; +} + +static __inline __ct_rune_t __tolower(__ct_rune_t _c) { return (_c < 0 || _c >= _CACHED_RUNES) ? ___tolower(_c) : _CurrentRuneLocale->__maplower[_c]; } +static __inline __ct_rune_t +__sbtolower(__ct_rune_t _c) +{ + return (_c < 0 || _c >= __mb_sb_limit) ? _c : + _CurrentRuneLocale->__maplower[_c]; +} + static __inline int __wcwidth(__ct_rune_t _c) { @@ -146,10 +175,14 @@ __BEGIN_DECLS int __maskrune(__ct_rune_t, unsigned long); +int __sbmaskrune(__ct_rune_t, unsigned long); int __istype(__ct_rune_t, unsigned long); +int __sbistype(__ct_rune_t, unsigned long); int __isctype(__ct_rune_t, unsigned long); __ct_rune_t __toupper(__ct_rune_t); +__ct_rune_t __sbtoupper(__ct_rune_t); __ct_rune_t __tolower(__ct_rune_t); +__ct_rune_t __sbtolower(__ct_rune_t); int __wcwidth(__ct_rune_t); __END_DECLS #endif /* using inlines */ --- big5.c.old 2007-09-19 08:48:55.000000000 +0400 +++ big5.c 2007-09-21 21:44:31.000000000 +0400 @@ -49,6 +49,8 @@ #include #include "mblocal.h" +extern int __mb_sb_limit; + static size_t _BIG5_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _BIG5_mbsinit(const mbstate_t *); @@ -68,6 +70,7 @@ __mbsinit = _BIG5_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_sb_limit = 128; return (0); } --- ctype.h.old 2007-09-16 22:03:55.000000000 +0400 +++ ctype.h 2007-09-21 06:26:26.000000000 +0400 @@ -86,19 +86,19 @@ #endif __END_DECLS -#define isalnum(c) __istype((c), _CTYPE_A|_CTYPE_D) -#define isalpha(c) __istype((c), _CTYPE_A) -#define iscntrl(c) __istype((c), _CTYPE_C) +#define isalnum(c) __sbistype((c), _CTYPE_A|_CTYPE_D) +#define isalpha(c) __sbistype((c), _CTYPE_A) +#define iscntrl(c) __sbistype((c), _CTYPE_C) #define isdigit(c) __isctype((c), _CTYPE_D) /* ANSI -- locale independent */ -#define isgraph(c) __istype((c), _CTYPE_G) -#define islower(c) __istype((c), _CTYPE_L) -#define isprint(c) __istype((c), _CTYPE_R) -#define ispunct(c) __istype((c), _CTYPE_P) -#define isspace(c) __istype((c), _CTYPE_S) -#define isupper(c) __istype((c), _CTYPE_U) +#define isgraph(c) __sbistype((c), _CTYPE_G) +#define islower(c) __sbistype((c), _CTYPE_L) +#define isprint(c) __sbistype((c), _CTYPE_R) +#define ispunct(c) __sbistype((c), _CTYPE_P) +#define isspace(c) __sbistype((c), _CTYPE_S) +#define isupper(c) __sbistype((c), _CTYPE_U) #define isxdigit(c) __isctype((c), _CTYPE_X) /* ANSI -- locale independent */ -#define tolower(c) __tolower(c) -#define toupper(c) __toupper(c) +#define tolower(c) __sbtolower(c) +#define toupper(c) __sbtoupper(c) #if __XSI_VISIBLE /* @@ -112,24 +112,24 @@ * * XXX isascii() and toascii() should similarly be undocumented. */ -#define _tolower(c) __tolower(c) -#define _toupper(c) __toupper(c) +#define _tolower(c) __sbtolower(c) +#define _toupper(c) __sbtoupper(c) #define isascii(c) (((c) & ~0x7F) == 0) #define toascii(c) ((c) & 0x7F) #endif #if __ISO_C_VISIBLE >= 1999 -#define isblank(c) __istype((c), _CTYPE_B) +#define isblank(c) __sbistype((c), _CTYPE_B) #endif #if __BSD_VISIBLE -#define digittoint(c) __maskrune((c), 0xFF) -#define ishexnumber(c) __istype((c), _CTYPE_X) -#define isideogram(c) __istype((c), _CTYPE_I) -#define isnumber(c) __istype((c), _CTYPE_D) -#define isphonogram(c) __istype((c), _CTYPE_Q) -#define isrune(c) __istype((c), 0xFFFFFF00L) -#define isspecial(c) __istype((c), _CTYPE_T) +#define digittoint(c) __sbmaskrune((c), 0xFF) +#define ishexnumber(c) __sbistype((c), _CTYPE_X) +#define isideogram(c) __sbistype((c), _CTYPE_I) +#define isnumber(c) __sbistype((c), _CTYPE_D) +#define isphonogram(c) __sbistype((c), _CTYPE_Q) +#define isrune(c) __sbistype((c), 0xFFFFFF00L) +#define isspecial(c) __sbistype((c), _CTYPE_T) #endif #endif /* !_CTYPE_H_ */ --- euc.c.old 2007-09-19 08:50:57.000000000 +0400 +++ euc.c 2007-09-21 21:44:31.000000000 +0400 @@ -49,6 +49,8 @@ #include #include "mblocal.h" +extern int __mb_sb_limit; + static size_t _EUC_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _EUC_mbsinit(const mbstate_t *); @@ -116,6 +118,7 @@ __mbrtowc = _EUC_mbrtowc; __wcrtomb = _EUC_wcrtomb; __mbsinit = _EUC_mbsinit; + __mb_sb_limit = 256; return (0); } --- gb18030.c.old 2007-09-19 08:59:01.000000000 +0400 +++ gb18030.c 2007-09-21 21:44:31.000000000 +0400 @@ -39,6 +39,8 @@ #include #include "mblocal.h" +extern int __mb_sb_limit; + static size_t _GB18030_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GB18030_mbsinit(const mbstate_t *); @@ -59,6 +61,7 @@ __mbsinit = _GB18030_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 4; + __mb_sb_limit = 128; return (0); } --- gb2312.c.old 2007-09-19 09:00:35.000000000 +0400 +++ gb2312.c 2007-09-21 21:44:31.000000000 +0400 @@ -35,6 +35,8 @@ #include #include "mblocal.h" +extern int __mb_sb_limit; + static size_t _GB2312_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GB2312_mbsinit(const mbstate_t *); @@ -55,6 +57,7 @@ __wcrtomb = _GB2312_wcrtomb; __mbsinit = _GB2312_mbsinit; __mb_cur_max = 2; + __mb_sb_limit = 128; return (0); } --- gbk.c.old 2007-09-19 09:01:33.000000000 +0400 +++ gbk.c 2007-09-21 21:44:31.000000000 +0400 @@ -42,6 +42,8 @@ #include #include "mblocal.h" +extern int __mb_sb_limit; + static size_t _GBK_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _GBK_mbsinit(const mbstate_t *); @@ -61,6 +63,7 @@ __mbsinit = _GBK_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_sb_limit = 128; return (0); } --- isctype.c.old 2007-09-16 22:31:26.000000000 +0400 +++ isctype.c 2007-09-21 06:28:30.000000000 +0400 @@ -48,7 +48,7 @@ digittoint(c) int c; { - return (__maskrune(c, 0xFF)); + return (__sbmaskrune(c, 0xFF)); } #undef isalnum @@ -56,7 +56,7 @@ isalnum(c) int c; { - return (__istype(c, _CTYPE_A|_CTYPE_D)); + return (__sbistype(c, _CTYPE_A|_CTYPE_D)); } #undef isalpha @@ -64,7 +64,7 @@ isalpha(c) int c; { - return (__istype(c, _CTYPE_A)); + return (__sbistype(c, _CTYPE_A)); } #undef isascii @@ -80,7 +80,7 @@ isblank(c) int c; { - return (__istype(c, _CTYPE_B)); + return (__sbistype(c, _CTYPE_B)); } #undef iscntrl @@ -88,7 +88,7 @@ iscntrl(c) int c; { - return (__istype(c, _CTYPE_C)); + return (__sbistype(c, _CTYPE_C)); } #undef isdigit @@ -104,7 +104,7 @@ isgraph(c) int c; { - return (__istype(c, _CTYPE_G)); + return (__sbistype(c, _CTYPE_G)); } #undef ishexnumber @@ -112,7 +112,7 @@ ishexnumber(c) int c; { - return (__istype(c, _CTYPE_X)); + return (__sbistype(c, _CTYPE_X)); } #undef isideogram @@ -120,7 +120,7 @@ isideogram(c) int c; { - return (__istype(c, _CTYPE_I)); + return (__sbistype(c, _CTYPE_I)); } #undef islower @@ -128,7 +128,7 @@ islower(c) int c; { - return (__istype(c, _CTYPE_L)); + return (__sbistype(c, _CTYPE_L)); } #undef isnumber @@ -136,7 +136,7 @@ isnumber(c) int c; { - return (__istype(c, _CTYPE_D)); + return (__sbistype(c, _CTYPE_D)); } #undef isphonogram @@ -144,7 +144,7 @@ isphonogram(c) int c; { - return (__istype(c, _CTYPE_Q)); + return (__sbistype(c, _CTYPE_Q)); } #undef isprint @@ -152,7 +152,7 @@ isprint(c) int c; { - return (__istype(c, _CTYPE_R)); + return (__sbistype(c, _CTYPE_R)); } #undef ispunct @@ -160,7 +160,7 @@ ispunct(c) int c; { - return (__istype(c, _CTYPE_P)); + return (__sbistype(c, _CTYPE_P)); } #undef isrune @@ -168,7 +168,7 @@ isrune(c) int c; { - return (__istype(c, 0xFFFFFF00L)); + return (__sbistype(c, 0xFFFFFF00L)); } #undef isspace @@ -176,7 +176,7 @@ isspace(c) int c; { - return (__istype(c, _CTYPE_S)); + return (__sbistype(c, _CTYPE_S)); } #undef isspecial @@ -184,7 +184,7 @@ isspecial(c) int c; { - return (__istype(c, _CTYPE_T)); + return (__sbistype(c, _CTYPE_T)); } #undef isupper @@ -192,7 +192,7 @@ isupper(c) int c; { - return (__istype(c, _CTYPE_U)); + return (__sbistype(c, _CTYPE_U)); } #undef isxdigit @@ -216,7 +216,7 @@ tolower(c) int c; { - return (__tolower(c)); + return (__sbtolower(c)); } #undef toupper @@ -224,6 +224,6 @@ toupper(c) int c; { - return (__toupper(c)); + return (__sbtoupper(c)); } --- iswctype.c.old 2007-09-16 22:31:30.000000000 +0400 +++ iswctype.c 2007-09-21 06:29:59.000000000 +0400 @@ -61,7 +61,7 @@ iswascii(wc) wint_t wc; { - return ((wc & ~0x7F) == 0); + return (wc < 0x80); } #undef iswblank --- mskanji.c.old 2007-09-19 09:02:56.000000000 +0400 +++ mskanji.c 2007-09-21 21:44:31.000000000 +0400 @@ -47,6 +47,8 @@ #include #include "mblocal.h" +extern int __mb_sb_limit; + static size_t _MSKanji_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _MSKanji_mbsinit(const mbstate_t *); @@ -66,6 +68,7 @@ __mbsinit = _MSKanji_mbsinit; _CurrentRuneLocale = rl; __mb_cur_max = 2; + __mb_sb_limit = 256; return (0); } --- none.c.old 2007-09-19 08:56:40.000000000 +0400 +++ none.c 2007-09-21 21:44:31.000000000 +0400 @@ -58,6 +58,11 @@ static size_t _none_wcsnrtombs(char * __restrict, const wchar_t ** __restrict, size_t, size_t, mbstate_t * __restrict); +/* setup defaults */ + +int __mb_cur_max = 1; +int __mb_sb_limit = 256; /* Expected to be <= _CACHED_RUNES */ + int _none_init(_RuneLocale *rl) { @@ -69,6 +74,7 @@ __wcsnrtombs = _none_wcsnrtombs; _CurrentRuneLocale = rl; __mb_cur_max = 1; + __mb_sb_limit = 256; return(0); } @@ -176,7 +182,6 @@ /* setup defaults */ -int __mb_cur_max = 1; size_t (*__mbrtowc)(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict) = _none_mbrtowc; int (*__mbsinit)(const mbstate_t *) = _none_mbsinit; --- setrunelocale.c.old 2007-09-19 09:03:59.000000000 +0400 +++ setrunelocale.c 2007-09-21 21:44:31.000000000 +0400 @@ -45,6 +45,8 @@ #include "mblocal.h" #include "setlocale.h" +extern int __mb_sb_limit; + extern _RuneLocale *_Read_RuneMagi(FILE *); static int __setrunelocale(const char *); @@ -59,6 +61,7 @@ static char ctype_encoding[ENCODING_LEN + 1]; static _RuneLocale *CachedRuneLocale; static int Cached__mb_cur_max; + static int Cached__mb_sb_limit; static size_t (*Cached__mbrtowc)(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static size_t (*Cached__wcrtomb)(char * __restrict, wchar_t, @@ -85,6 +88,7 @@ strcmp(encoding, ctype_encoding) == 0) { _CurrentRuneLocale = CachedRuneLocale; __mb_cur_max = Cached__mb_cur_max; + __mb_sb_limit = Cached__mb_sb_limit; __mbrtowc = Cached__mbrtowc; __mbsinit = Cached__mbsinit; __mbsnrtowcs = Cached__mbsnrtowcs; @@ -147,6 +151,7 @@ } CachedRuneLocale = _CurrentRuneLocale; Cached__mb_cur_max = __mb_cur_max; + Cached__mb_sb_limit = __mb_sb_limit; Cached__mbrtowc = __mbrtowc; Cached__mbsinit = __mbsinit; Cached__mbsnrtowcs = __mbsnrtowcs; --- utf8.c.old 2007-09-19 08:18:40.000000000 +0400 +++ utf8.c 2007-09-21 21:44:31.000000000 +0400 @@ -35,6 +35,8 @@ #include #include "mblocal.h" +extern int __mb_sb_limit; + static size_t _UTF8_mbrtowc(wchar_t * __restrict, const char * __restrict, size_t, mbstate_t * __restrict); static int _UTF8_mbsinit(const mbstate_t *); @@ -63,6 +65,7 @@ __wcsnrtombs = _UTF8_wcsnrtombs; _CurrentRuneLocale = rl; __mb_cur_max = 6; + __mb_sb_limit = 128; return (0); } --- wctype.h.old 2007-09-16 21:59:37.000000000 +0400 +++ wctype.h 2007-09-21 06:08:40.000000000 +0400 @@ -106,7 +106,7 @@ #define towupper(wc) __toupper(wc) #if __BSD_VISIBLE -#define iswascii(wc) (((wc) & ~0x7F) == 0) +#define iswascii(wc) ((wc) < 0x80) #define iswhexnumber(wc) __istype((wc), _CTYPE_X) #define iswideogram(wc) __istype((wc), _CTYPE_I) #define iswnumber(wc) __istype((wc), _CTYPE_D) --LQksG6bCIzRHxTLp-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 18:06:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96CD116A41A; Fri, 21 Sep 2007 18:06:18 +0000 (UTC) (envelope-from SRS0=d0c8b9c90915d0208f62c239425c5d64ac37ac8e=465=es.net=oberman@es.net) Received: from postal1.es.net (postal4.es.net [IPv6:2001:400:6000:1::66]) by mx1.freebsd.org (Postfix) with ESMTP id 937DF13C447; Fri, 21 Sep 2007 18:06:17 +0000 (UTC) (envelope-from SRS0=d0c8b9c90915d0208f62c239425c5d64ac37ac8e=465=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id ABB35415; Fri, 21 Sep 2007 11:06:15 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C60D445027; Fri, 21 Sep 2007 11:06:13 -0700 (PDT) To: ttw+bsd@cobbled.net In-Reply-To: Your message of "Fri, 21 Sep 2007 10:06:30 -0000." <20070921100630.GA10718@holyman.cobbled.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1190397973_67439P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 21 Sep 2007 11:06:13 -0700 From: "Kevin Oberman" Message-Id: <20070921180613.C60D445027@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; ; ; X-Sender: X-To_Name: X-To_Domain: cobbled.net X-To: ttw+bsd@cobbled.net X-To_Email: ttw+bsd@cobbled.net X-To_Alias: ttw+bsd Cc: Darren Reed , Olivier Warin , freebsd-current@freebsd.org, John Birrell Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 18:06:18 -0000 --==_Exmh_1190397973_67439P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Fri, 21 Sep 2007 10:06:30 +0000 > From: ttw+bsd@cobbled.net > Sender: owner-freebsd-current@freebsd.org > > On 21.09-02:14, Darren Reed wrote: > [ ... ] > > >Only if it is clean-room coded. > > > > So find someone who hasn't read that email, write up a spec for the missing > > fields that dtrace requires and ask them to implement and commit the change > > to the dtrace branch on freebsd.org ? :) > > this has merit. > > to be honest, within copyright (UK and EU), i think you could > reasonably use structure definitions as they are fundamental to the > interaction, not the operation of the code. this has support, though > it's not been specifically ruled on in court (certainally not that > i'm aware of). there is a much bigger problem around patents and no > amount of clean room coding is going to avoid those. > ... having said that, nethier is adding some secondary structure -- > that is not how patent coverage works, only copyright. IANAL. Maybe the FreeBSD Foundation can help to get advice from a real lawyer, but this came up at least twice in past court cases, AT&T v. University of California, et. al. and the more recent SCO v. IBM Linux licensing case. The former is clearly directly applicable to FreeBSD. If the header files can be generated by someone who has not been exposed to the Sun code based on descriptions from someone who has the code, they should be fine. That's what was done for BSDlite and I don't see this as any different. Of course, anyone who this thread is not disqualified. (Actually, probably not as the short example would almost certainly meet fair-use qualification. -- 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_1190397973_67439P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG9AgVkn3rs5h7N1ERAqsmAJ9IvTThTFBH9NgWJ//nomGy++Hi7wCfcr3R +iwhayn3WV3y68QcYMG8KOA= =NINC -----END PGP SIGNATURE----- --==_Exmh_1190397973_67439P-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 18:10:04 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4062116A418; Fri, 21 Sep 2007 18:10:04 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 0359F13C478; Fri, 21 Sep 2007 18:10:03 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l8LI9xW3011679; Fri, 21 Sep 2007 13:09:59 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 21 Sep 2007 13:09:59 -0500 (CDT) From: "Sean C. Farley" To: Sergei Kolobov In-Reply-To: <20070921064707.GB80642@gondor.elendil.ru> Message-ID: References: <200709201606.l8KG6B3C037902@lurza.secnetix.de> <20070921064707.GB80642@gondor.elendil.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.farley.org Cc: freebsd-current@FreeBSD.org Subject: Re: /libexec/ld-elf.so.1: environment corrupt; missing value for X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 18:10:04 -0000 On Fri, 21 Sep 2007, Sergei Kolobov wrote: > On 2007-09-20 at 18:06 +0200, Oliver Fromme wrote: >> Sean C. Farley wrote: >> > [...] zsh 4.3.4 has a bug where it was mixing calls >> > to *env() functions with direct manipulation of environ. The CVS >> > version of zsh is fixed. I created PR ports/115094[1] to patch it in >> > the ports tree about a month ago. *nudging sergei* :) > > Oops - sorry, Sean! I must have overlooked it or something - will take > care of it shortly. Thanks! No problem. Thank you for looking into it. Would you mind also looking into ports/115702. It improves some completion issues with locate, mount and umount (sort of). Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 18:17:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB03F16A41B for ; Fri, 21 Sep 2007 18:17:26 +0000 (UTC) (envelope-from becky@3tera.com) Received: from srv.odcnet.com (mail2.odcnet.com [24.248.98.112]) by mx1.freebsd.org (Postfix) with ESMTP id 8A62813C458 for ; Fri, 21 Sep 2007 18:17:26 +0000 (UTC) (envelope-from becky@3tera.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Sep 2007 11:05:26 -0700 Message-ID: <2AF7DD0CE564C24EBACDABFAE55CC642BF9198@srv.odcnet.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD/Xen DOMU w/PAE support Thread-Index: Acf8efy+TuaJ+ajxSkKkpDkHpDWxBw== From: "Becky Hester" To: Subject: FreeBSD/Xen DOMU w/PAE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 18:17:26 -0000 I am currently trying to get FreeBSD 7-CURRENT running as DomU under CentOS 4.4 and XEN 3.0.4. However, the kernel provided at http://www.fsmware.com/xenofreebsd/7.0/download/ does not include PAE support. I have a few questions related to building the kernel from sources: I currently have FreeBSD 7-CURRENT installed on native hardware - FreeBSD 7.0-CURRENT-200708 - and was able to successfully rebuild the kernel w/o xen support and w/ PAE support resulting in FreeBSD being able to see all 8G of memory on the machine. I downloaded the sources from www.fsmware.com (fbsd_xen3.tgz) and tried to build the kernel with the following commands: cd /usr/src/sys/i386-xen/conf config XENCONF cd ../compile/XENCONF make cleandepend make depend=20 The 'make depend' command fails (see below for output of make depend as well as the contents of the kernel configuration file. Any help/suggestions would be appreciated. Here is the last part of the output from 'make depend' =3D=3D=3D> xl (obj) /usr/src/sys.both/i386-xen/compile/XENCONF/modules/usr/src/sys.both/modu les/xl created for /usr/src/sys.both/modules/xl =3D=3D=3D> zlib (obj) /usr/src/sys.both/i386-xen/compile/XENCONF/modules/usr/src/sys.both/modu les/zlib created for /usr/src/sys.both/modules/zlib cd ../../../modules; MAKEOBJDIRPREFIX=3D/usr/src/sys.both/i386-xen/compile/XENCONF/modules KMODDIR=3D/boot/kernel DEBUG_FLAGS=3D"-g" MACHINE=3Di386-xen KERNBUILDDIR=3D"/usr/src/sys.both/i386-xen/compile/XENCONF" make depend =3D=3D=3D> 3dfx (depend) @ -> /usr/src/sys.both machine -> /usr/src/sys.both/i386-xen/include i386 -> /usr/src/sys.both/i386/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/src/sys.both/i386-xen/compile/XENCONF /usr/src/sys.both/modules/3dfx/../../dev/tdfx/tdfx_pci.c cc1: note: obsolete option -I- used, please use -iquote instead =3D=3D=3D> 3dfx_linux (depend) @ -> /usr/src/sys.both machine -> /usr/src/sys.both/i386-xen/include i386 -> /usr/src/sys.both/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/src/sys.both/i386-xen/compile/XENCONF /usr/src/sys.both/modules/3dfx_linux/../../dev/tdfx/tdfx_linux.c cc1: note: obsolete option -I- used, please use -iquote instead In file included from /usr/src/sys.both/modules/3dfx_linux/../../dev/tdfx/tdfx_linux.c:37: @/dev/tdfx/tdfx_linux.h:35:36: error: machine/../linux/linux.h: No such file or directory @/dev/tdfx/tdfx_linux.h:36:42: error: machine/../linux/linux_proto.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys.both/modules/3dfx_linux. *** Error code 1 Stop in /usr/src/sys.both/modules. *** Error code 1 Here are the contents of my config file: (ultimately I would like to build it with SMP & PAE support) # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-c onfig.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.394.2.3 2004/01/26 19:42:11 nectar Exp $ machine i386-xen cpu I686_CPU ident XEN #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. makeoptions DEBUG=3D-g #Build kernel with gdb(1) = debug symbols options SCHED_4BSD #4BSD scheduler options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server # options NFS_ROOT #NFS usable as /, requires NFSCLIENT #options MSDOSFS #MSDOS Filesystem #options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=3D15000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options CPU_DISABLE_SSE # don't turn on SSE framework with Xen #options PFIL_HOOKS # pfil(9) framework # Debugging for use in -current options KDB #Enable the kernel debugger options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS #Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # Bus support device pci # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor #device agp # support several AGP chipsets #defaults # Floating point support - do not disable. device npx device isa device mem device io ####################################### # Serial (COM) ports #device sio # 8250, 16[45]50 based serial ports # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop # Network loopback device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter options XEN options XEN_PHYSDEV_ACCESS options XEN_PRIVILEGED_GUEST options MCLSHIFT=3D12 # this has to be enabled for Xen as we can only have one cluster per page options MSIZE=3D256 options DIAGNOSTIC options MAXMEM=3D(256*1024) #options NOXENDEBUG=3D1 # Turn off Debugging printfs options DDB # Our stuff for testing device em # Intel PRO/1000 adapter Gigabit Ethernet Card device if_bridge # Bridging options XEN_NETDEV_BACKEND #options XEN_BLKDEV_BACKEND options XEN_PCIDEV_FRONTEND From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 18:35:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1C6516A418 for ; Fri, 21 Sep 2007 18:35:12 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: from corpmail.itlegion.ru (corpmail.itlegion.ru [84.21.226.211]) by mx1.freebsd.org (Postfix) with SMTP id 27DF913C465 for ; Fri, 21 Sep 2007 18:35:11 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: (qmail 57196 invoked from network); 21 Sep 2007 22:08:29 +0400 Received: from unknown (HELO Artem) (192.168.0.12) by 84.21.226.211 with SMTP; 21 Sep 2007 22:08:29 +0400 X-AntiVirus: Checked by Dr.Web [version: 4.33, engine: 4.33.5.10110, virus records: 253987, updated: 21.09.2007] Message-ID: <01c801c7fc7a$696ab900$0c00a8c0@Artem> From: "Artem Kuchin" To: Date: Fri, 21 Sep 2007 22:08:16 +0400 Organization: IT Legion MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Subject: TSP on em makes send of streams very slow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 18:35:13 -0000 Hello! Here is what i have experienced today. I just installed 7.0-CURRENT (cvsed and build on 2007/09/20) on a PRODUCTION web server (because, IHMO, this current is stable enough and i like too much :) This is intel MB with two built-in em intefaces. I sshed to the server. While i was in plain shell everything was fine, but when i stared midnight commander i saw how it very slowly draws scren part by part. It took about 3 monutes to almost completely draw a screen when i got disconnected. I tied again - the same. Then i connected via ftp and uploaded 10MB file at 900KB/sec. When i tried to download it back i got about 500 *BYTES*/sec and the got disconnected in a couple of minutes. Ping was just find, even flood ping from the server on the save switch with 15000 packets was fine (just one dot on the left). I went also crazy already when i desided to compare interface params with another server with em NICs. The dfference is that this is has the following options (by DEFAULT, i did not turn it on): VLAN_HWCSUM,TSO4 I've read about TSO on 'man ifconfig' and just for kicks decided to turn it off. VOILA!!! In a seconds send speed was up to 10 MBYTES/sec! I have googled about 'em tso slow ' etc.. and found a couple of seemingly the same problem dated back 2006. Is it supposed to be solved by now? What IS the problem with TSO? Another question, what is VLAN_HWCSUM? Is it good for anything on a web server? How to disable it? (this option is not descriobed on ifconfig man page). Weirdly enough, when i looked at pciconf i have noticed that two build in nic are different chips. Is it normal? em1@pci6:5:0: class=0x020000 card=0x30a18086 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82541EI Gigabit Ethernet Controller' class = network subclass = ethernet em0@pci5:0:0: class=0x020000 card=0x30a28086 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PM' class = network subclass = ethernet ifconfig: em0: flags=8843 metric 0 mtu 1500 options=8b ether 00:16:76:9b:a1:bc media: Ethernet autoselect (100baseTX ) status: active em1: flags=8843 metric 0 mtu 1500 options=8b ether 00:16:76:9b:a1:bd media: Ethernet autoselect status: no carrier Another em man page weirdness is that it says that if one does not specify full-duplex in mediaopt then driver is supposed top be in half-duplex even in autoselect mode. It definetely does not behave like this (you can see in my ifconfig output). Totally BTW: should i enable polling? does it give anything good at very low cost? -- Regards, Artem Kuchin IT Legion Moscow, Russia www.itlegion.ru +7 495 232-0338 From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 18:36:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE15A16A41B for ; Fri, 21 Sep 2007 18:36:25 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA8913C494 for ; Fri, 21 Sep 2007 18:36:25 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so632457wxd for ; Fri, 21 Sep 2007 11:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=+WYg61yG8WRgIn3DKxY1SdeC9TbUEV3IycPogRrCs24=; b=NEryLR5pswuj/RoJOJhOXDEgnupyeQwCgtJ3ovaolXFbTFdmfjHPReLYr+U4WI0Nitjt6Vr8xCFJQBNqgfnb/as/DzCJ0nR+tR8pMk0PAqQSV+R5+jU9T04TNYozzFFxTnqXmGiNkZ37O1m30YYE7CJD2zeHY+fpHcTD2INItoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dUpkNrMZW+h0ClDKytk6CKcPSjw1ZbK0RnFkQFT0SLHhdibTXtS9JV9vrxMkvSRGcOocpV6/1qLnm1mCTOSoWBW2L4RF5rDuJGQN8HmcmtDGRAG1HixK7/Smwu70TjQmV1Y5SFD1irGBqnfypzQ2oQV8eq14TKOzJ71u1c75TAY= Received: by 10.90.52.18 with SMTP id z18mr2841271agz.1190399784617; Fri, 21 Sep 2007 11:36:24 -0700 (PDT) Received: by 10.90.106.19 with HTTP; Fri, 21 Sep 2007 11:36:24 -0700 (PDT) Message-ID: Date: Fri, 21 Sep 2007 13:36:24 -0500 From: Matt To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Unexpected gcc linking behavior on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 18:36:25 -0000 Hello all. I've been working on getting VirtualBox to build on -CURRENT and have hit what I think might be a compiler snag based on the error and some of the mails I've seen to the freebsd-java mailing list over the last months. Any insights into how to isolate and hopefully correct this error would be greatly appreciated. The code builds cleanly on a 6.2-RELEASE box using gcc 3.4.6. The error on -CURRENT (from 9/13) using gcc 4.2.1 is as follows: kBuild: Linking VBoxSVCout/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x313): In function `__static_initialization_and_destruction_0': src/VBox/Main/linux/server.cpp:594: undefined reference to `_292' out/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x31d):src/VBox/Main/linux/server.cpp:594: undefined reference to `_292' out/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x327):src/VBox/Main/linux/server.cpp:594: undefined reference to `_292' out/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x331):src/VBox/Main/linux/server.cpp:594: undefined reference to `_292' kmk[3]: *** [out/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/VBoxSVC] Error 1 Thank you, Matt From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 18:39:32 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A357816A41A; Fri, 21 Sep 2007 18:39:32 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 0885213C44B; Fri, 21 Sep 2007 18:39:31 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 3632E691179; Fri, 21 Sep 2007 19:42:32 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id EED8C6911C8; Fri, 21 Sep 2007 19:42:31 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from [10.0.0.15] (unknown [83.144.143.98]) by core.fnop.net (Postfix) with ESMTP id 79648691179; Fri, 21 Sep 2007 19:42:27 +0100 (WEST) In-Reply-To: References: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> <46E9FC0C.70607@FreeBSD.org> <46F1A96F.2040602@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rui Paulo Date: Fri, 21 Sep 2007 17:16:02 +0100 To: Doug Barton X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP Cc: Alexander Leidinger , Shteryana Shopova , freebsd-current@FreeBSD.org, "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 18:39:32 -0000 On 21 Sep 2007, at 00:12, Doug Barton wrote: > On Wed, 19 Sep 2007, Constantine A. Murenin wrote: > >> Thanks for testing! > > Glad to help. In case it's interesting, I was doing the xorg update > with portmaster last night and I got several "PROCHOT asserted" > messages on my console at different times. I'm assuming that's > expected behavior, just curious if it's something bad, as in when > that happens it's time to turn off the laptop? (I didn't seem them > when the happened, they were there when I got back to check on the > compiling.) That basically means the digital sensor has detected a high temperature and it allows the operating system to do "something". I plan to work a bit more on coretemp(4) so that all these notifications go through devctl(4). Regards. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 18:42:50 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0BD216A418 for ; Fri, 21 Sep 2007 18:42:50 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 57A6613C468 for ; Fri, 21 Sep 2007 18:42:50 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from doc.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IYnSj-000BqQ-9o for freebsd-current@FreeBSD.org; Fri, 21 Sep 2007 22:42:49 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IYnUB-000584-HJ for freebsd-current@FreeBSD.org; Fri, 21 Sep 2007 22:44:19 +0400 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Fri, 21 Sep 2007 22:44:19 +0400 Message-ID: <96913676@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: duplicate lock of same type: "vnode interlock" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 18:42:50 -0000 Hi! Today at: # uname -a FreeBSD test.ipt.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Fri Sep 21 18:36:28 MSD 2007 bsam@test.ipt.ru:/usr/obj/usr/src/sys/TEST amd64 I've got: ----- Mounting local file systems:acquiring duplicate lock of same type: "vnode interlock" 1st vnode interlock @ /usr/src/sys/kern/vfs_vnops.c:807 2nd vnode interlock @ /usr/src/sys/kern/vfs_subr.c:2081 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x5f8 _mtx_lock_flags() at _mtx_lock_flags+0x75 vrefcnt() at vrefcnt+0x31 null_checkvp() at null_checkvp+0x1d null_lock() at null_lock+0x5b VOP_LOCK1_APV() at VOP_LOCK1_APV+0x79 _vn_lock() at _vn_lock+0x94 nullfs_root() at nullfs_root+0x59 vfs_donmount() at vfs_donmount+0x1150 nmount() at nmount+0x97 syscall() at syscall+0x1f6 Xfast_syscall() at Xfast_syscall+0xab --- syscall (378, FreeBSD ELF64, nmount), rip = 0x80068465c, rsp = 0x7fffffffe518, rbp = 0x7fffffffe520 --- ----- Should I worry about it? The system boots and seems to we fine... WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 18:56:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1441516A420 for ; Fri, 21 Sep 2007 18:56:14 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 034A613C481 for ; Fri, 21 Sep 2007 18:56:13 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 65B691CC02B; Fri, 21 Sep 2007 11:37:53 -0700 (PDT) Date: Fri, 21 Sep 2007 11:37:53 -0700 From: Jeremy Chadwick To: freebsd-current@freebsd.org Message-ID: <20070921183753.GA68493@eos.sc1.parodius.com> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Subject: dump(8) and "Approaching the limit on PV entries" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 18:56:14 -0000 I'm new to the present -CURRENT, so go easy on me. :-) I run periodic backups on my LAN at home, and since switching from RELENG_6 I've begun to see this kernel message emit when dump(8) runs with a dump level of 0 on one specific filesystem. Incrementals, at least so far, haven't caused this. Sep 20 03:09:58 icarus kernel: Approaching the limit on PV entries, consider increasing tunables vm.pmap.shpgperproc or vm.pmap.pv_entry_max The filesystem in question is a GEOM stripe class consisting of two disk members, ad4 and ad6. Sector sizes are default (512 bytes). I chose a stripe size of 256KB. Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/stripe/st0 946141880 80111848 790338688 9% /storage Additional tunefs parameters were used as well; everything is default except: tunefs: maximum blocks per file in a cylinder group: (-e) 16384 tunefs: average file size: (-f) 65536 tunefs: average number of files in a directory: (-s) 256 How I'm doing backups: /sbin/dump -0 -a -h0 -u -C16 -L -f- /storage | dd of=/backups/storage.0.dump I haven't tried removing the use of -C16 (16MB cache) to see if that makes a difference. I assumed vm.pmap.shpgperproc adjusted the number of shared VM pages available per process, so I opted to increase that from 200 (default) to 1000 using loader.conf and reboot. However, I still get the message, which indicates I may need to apply further tuning. But rather than blindly increase numbers, I thought I'd ask others for recommendations or clues as to what's going on. Thanks for educating me. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 18:58:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC66816A419 for ; Fri, 21 Sep 2007 18:58:55 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 82A5213C469 for ; Fri, 21 Sep 2007 18:58:55 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from doc.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1IYniI-000Btj-5e; Fri, 21 Sep 2007 22:58:54 +0400 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IYnjk-00058o-Dz; Fri, 21 Sep 2007 23:00:24 +0400 To: Kostik Belousov References: <96913676@srv.sem.ipt.ru> <20070921185050.GL79542@deviant.kiev.zoral.com.ua> From: Boris Samorodov Date: Fri, 21 Sep 2007 23:00:24 +0400 In-Reply-To: <20070921185050.GL79542@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Fri\, 21 Sep 2007 21\:50\:50 +0300") Message-ID: <30832711@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.99 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: duplicate lock of same type: "vnode interlock" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 18:58:55 -0000 On Fri, 21 Sep 2007 21:50:50 +0300 Kostik Belousov wrote: > > Should I worry about it? > No. Thanks. I've read your previous answers at similar questions but wasn't sure if you want to test some patches. ;-) WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 18:58:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0BAD16A496 for ; Fri, 21 Sep 2007 18:58:59 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (home.keithp.com [63.227.221.253]) by mx1.freebsd.org (Postfix) with ESMTP id A227F13C46E for ; Fri, 21 Sep 2007 18:58:58 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (localhost [127.0.0.1]) by vonnegut.anholt.net (8.14.1/8.14.1) with ESMTP id l8LIP8dI001509; Fri, 21 Sep 2007 11:25:09 -0700 (PDT) (envelope-from eric@anholt.net) Received: (from anholt@localhost) by vonnegut.anholt.net (8.14.1/8.14.1/Submit) id l8LIP7uw001508; Fri, 21 Sep 2007 11:25:07 -0700 (PDT) (envelope-from eric@anholt.net) X-Authentication-Warning: vonnegut.anholt.net: anholt set sender to eric@anholt.net using -f From: Eric Anholt To: "S.N.Grigoriev" In-Reply-To: <105091190304115@webmail34.yandex.ru> References: <105091190304115@webmail34.yandex.ru> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Bd+pkl51wHthQ8+/56Fd" Date: Fri, 21 Sep 2007 11:25:06 -0700 Message-Id: <1190399106.1327.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org Subject: Re: Xorg 7.3 problem on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 18:59:00 -0000 --=-Bd+pkl51wHthQ8+/56Fd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-09-20 at 20:01 +0400, S.N.Grigoriev wrote: > Hi, list, >=20 > I've upgraded to Xorg 7.3 my CURRENT amd64 machine (both source and port = trees > are fresh). All programs work correctly except for X session terminations= . > Every time I try to finish the current X session, the X server crashes wi= th > core dump (irrespective of how sessions were started with startx or xdm). > Upgrades of X on 6.2 i386 machines do not introduce this problem. > Does anybody know how this can be fixed? This is usually driver-specific, sometimes chipset specific. You should attach GDB to the X Server from a remote machine and try to reproduce it, and post a backtrace. --=20 Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com --=-Bd+pkl51wHthQ8+/56Fd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBG9Ax+HUdvYGzw6vcRAgPzAJwLUpClEkFVfbEe5MOiqI5V0o/C1QCfYSNG q3Flvy8lU5qTyGmVVIHyW9o= =B72o -----END PGP SIGNATURE----- --=-Bd+pkl51wHthQ8+/56Fd-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:03:33 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2A2816A41A for ; Fri, 21 Sep 2007 19:03:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 59B3A13C48A for ; Fri, 21 Sep 2007 19:03:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 9056 invoked by uid 399); 21 Sep 2007 19:03:32 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 21 Sep 2007 19:03:32 -0000 X-Originating-IP: 127.0.0.1 Date: Fri, 21 Sep 2007 12:03:30 -0700 (PDT) From: Doug Barton To: Rui Paulo In-Reply-To: Message-ID: References: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> <46E9FC0C.70607@FreeBSD.org> <46F1A96F.2040602@FreeBSD.org> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:03:33 -0000 On Fri, 21 Sep 2007, Rui Paulo wrote: > > On 21 Sep 2007, at 00:12, Doug Barton wrote: > >> On Wed, 19 Sep 2007, Constantine A. Murenin wrote: >> >>> Thanks for testing! >> >> Glad to help. In case it's interesting, I was doing the xorg update with >> portmaster last night and I got several "PROCHOT asserted" messages on my >> console at different times. I'm assuming that's expected behavior, just >> curious if it's something bad, as in when that happens it's time to turn >> off the laptop? (I didn't seem them when the happened, they were there when >> I got back to check on the compiling.) > > That basically means the digital sensor has detected a high temperature and > it allows the operating system to do "something". I plan to work a bit more > on coretemp(4) so that all these notifications go through devctl(4). Great, I look forward to that. :) Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:03:41 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58B1516A4AB for ; Fri, 21 Sep 2007 19:03:41 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 646AA13C459; Fri, 21 Sep 2007 19:03:40 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F4158D.6030208@FreeBSD.org> Date: Fri, 21 Sep 2007 21:03:41 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Petr Holub References: <002c01c7fc45$717e6400$5317fb93@KLOBOUCEK> In-Reply-To: <002c01c7fc45$717e6400$5317fb93@KLOBOUCEK> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: TCP socket problem on Sept. -CURRENT snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:03:41 -0000 Petr Holub wrote: > Hi, > > I've encountered the following problem while building xorg from > ports: > > TCP: [134.76.12.3]:21 to [147.251.54.186]:56914 tcpflags 0x18; tcp_do_ > segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo > ving tcpcb > TCP: [134.76.12.3]:21 to [147.251.54.186]:62424 tcpflags 0x18; tcp_do_ > segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo > ving tcpcb > TCP: [134.76.12.3]:21 to [147.251.54.186]:55989 tcpflags 0x18; tcp_do_ > segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo > ving tcpcb > TCP: [134.76.12.3]:21 to [147.251.54.186]:52923 tcpflags 0x18; tcp_do_ > segment: FIN_WAIT_1: Received data after socket was closed, sending RST and remo > ving tcpcb > > It occurred from several different addresses and results in being > unable event to ping that IP until reboot. These log messages are informational, if you see ICMP problems it must have another source. Kris From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:04:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 629B216A418 for ; Fri, 21 Sep 2007 19:04:31 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 9A5F213C4BB; Fri, 21 Sep 2007 19:04:30 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F415BF.9010500@FreeBSD.org> Date: Fri, 21 Sep 2007 21:04:31 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Larry Rosenman References: <20070921102946.T11189@borg> In-Reply-To: <20070921102946.T11189@borg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: panic: kmem_malloc(131072): kmem_map too small (AMD64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:04:31 -0000 Larry Rosenman wrote: > I'm a heavy ZFS user, and got the following panic on 2007-09-18 > source/world: This is a FAQ, please see the archives (you need to increase the vm.kmem_size to provide more memory to ZFS). kris From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:07:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DAE616A418 for ; Fri, 21 Sep 2007 19:07:12 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 313F413C48D for ; Fri, 21 Sep 2007 19:07:12 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org ([192.147.25.65]:54729) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IYnqI-000PGE-TY; Fri, 21 Sep 2007 14:07:11 -0500 Date: Fri, 21 Sep 2007 14:07:08 -0500 (CDT) From: Larry Rosenman To: Kris Kennaway In-Reply-To: <46F415BF.9010500@FreeBSD.org> Message-ID: <20070921140550.D96923@thebighonker.lerctr.org> References: <20070921102946.T11189@borg> <46F415BF.9010500@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -4.4 (----) X-LERCTR-Spam-Score: -4.4 (----) X-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8,BAYES_00=-2.599 X-LERCTR-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8,BAYES_00=-2.599 DomainKey-Status: no signature Cc: freebsd-current@freebsd.org Subject: Re: panic: kmem_malloc(131072): kmem_map too small (AMD64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:07:12 -0000 On Fri, 21 Sep 2007, Kris Kennaway wrote: > Larry Rosenman wrote: >> I'm a heavy ZFS user, and got the following panic on 2007-09-18 >> source/world: > > This is a FAQ, please see the archives (you need to increase the vm.kmem_size > to provide more memory to ZFS). I thought that was only for i386, and it hadn't been an issue before. scottl@ suggested that maybe the default for amd64 for vm.kmem_size should be increased drastically for 7.0-R.... I have increased it for now... > > kris > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:08:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D330116A419 for ; Fri, 21 Sep 2007 19:08:07 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id B7E7613C44B for ; Fri, 21 Sep 2007 19:08:07 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id B1C6611F07F9; Fri, 21 Sep 2007 11:50:20 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 963AB2805A; Fri, 21 Sep 2007 11:50:20 -0700 (PDT) X-AuditID: 11807130-a53c5bb000004daf-8d-46f4126ca7e2 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id 768EF28084; Fri, 21 Sep 2007 11:50:20 -0700 (PDT) In-Reply-To: <20070921180613.C60D445027@ptavv.es.net> References: <20070921180613.C60D445027@ptavv.es.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B27D824-2EE2-4197-8AF1-E5D8C9787A56@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 21 Sep 2007 11:50:19 -0700 To: Kevin Oberman X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: FreeBSD Current , John Birrell Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:08:07 -0000 On Sep 21, 2007, at 11:06 AM, Kevin Oberman wrote: >>> So find someone who hasn't read that email, write up a spec for >>> the missing >>> fields that dtrace requires and ask them to implement and commit >>> the change >>> to the dtrace branch on freebsd.org ? :) >> >> this has merit. >> >> to be honest, within copyright (UK and EU), i think you could >> reasonably use structure definitions as they are fundamental to the >> interaction, not the operation of the code. this has support, though >> it's not been specifically ruled on in court (certainally not that >> i'm aware of). there is a much bigger problem around patents and no >> amount of clean room coding is going to avoid those. >> ... having said that, neither is adding some secondary structure -- >> that is not how patent coverage works, only copyright. > > IANAL. Maybe the FreeBSD Foundation can help to get advice from a real > lawyer, but this came up at least twice in past court cases, AT&T > v. University of California, et. al. and the more recent SCO v. IBM > Linux licensing case. This is likely to be true in the US as well; the canonical legal decision here about how to understand software copyright infringement is known as "Computer Associates v. Altai" [1] which defined an "abstraction-filtration-comparison" test: The filtration test requires one to analyze the program modules via a flowchart, and decide whether each distinct module or section "shows only an idea" (if yes, the material is not copyrightable, but might be patentable), or is an expression of an idea. If the latter, the analysis requires consideration of whether the expression is (a) dictated by efficiency, (b) dictated by external factors (specifically interfaces, APIs), or (c) whether the expression is taken from the public domain. Unless the answer to (a)-(c) are all no, and the code does not represent a "protected combination", and unless it constitutes "enough copying to be a wrongful taking", it is considered "lawful copying" and not "copyright infringement". Notice (b) & (c) in particular; publicly published APIs generally cannot qualify or be used as grounds for software copyright infringement. On the other hand, IANAL, TINLA-- and I'd be much happier with FreeBSD being lilly-white and 100% clean in terms of the code it includes. -- -Chuck [1]: http://www.bitlaw.com/source/cases/copyright/altai.html From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:17:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDB7C16A417 for ; Fri, 21 Sep 2007 19:17:38 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2DB13C43E for ; Fri, 21 Sep 2007 19:17:38 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A564A5.dip.t-dialin.net [84.165.100.165]) by redbull.bpaserver.net (Postfix) with ESMTP id 0A3692E2B1; Fri, 21 Sep 2007 21:17:28 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 670F15B4812; Fri, 21 Sep 2007 21:17:00 +0200 (CEST) Date: Fri, 21 Sep 2007 21:15:41 +0200 From: Alexander Leidinger To: Matt Message-ID: <20070921211541.1b6d6ca0@deskjail> In-Reply-To: References: X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.14; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Unexpected gcc linking behavior on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:17:38 -0000 Quoting Matt (Fri, 21 Sep 2007 13:36:24 -0500): > Hello all. > > I've been working on getting VirtualBox to build on -CURRENT and have > hit what I think might be a compiler snag based on the error and some > of the mails I've seen to the freebsd-java mailing list over the last > months. > > Any insights into how to isolate and hopefully correct this error > would be greatly appreciated. The code builds cleanly on a > 6.2-RELEASE box using gcc 3.4.6. The error on -CURRENT (from 9/13) > using gcc 4.2.1 is as follows: > > kBuild: Linking > VBoxSVCout/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x313): > In function `__static_initialization_and_destruction_0': > src/VBox/Main/linux/server.cpp:594: undefined reference to `_292' > out/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x31d):src/VBox/Main/linux/server.cpp:594: > undefined reference to `_292' I've seen something like this because of compiler bugs depending on the optimization level. Try different optimization levels and have a look what happens (complete rebuild of the source in question). Bye, Alexander. -- Graduate life -- it's not just a job, it's an indenture. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:20:09 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ED1416A4C5 for ; Fri, 21 Sep 2007 19:20:09 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 0BD5A13C45D for ; Fri, 21 Sep 2007 19:20:08 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id A5C9211F1249; Fri, 21 Sep 2007 12:20:08 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 894BB28087; Fri, 21 Sep 2007 12:20:08 -0700 (PDT) X-AuditID: 11807130-a53c5bb000004daf-9f-46f419689301 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id 6F4662805A; Fri, 21 Sep 2007 12:20:08 -0700 (PDT) In-Reply-To: References: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> <46E9FC0C.70607@FreeBSD.org> <46F1A96F.2040602@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 21 Sep 2007 12:20:07 -0700 To: Rui Paulo , Doug Barton X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: Alexander Leidinger , Shteryana Shopova , FreeBSD Current , "Constantine A. Murenin" Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:20:09 -0000 On Sep 21, 2007, at 9:16 AM, Rui Paulo wrote: > On 21 Sep 2007, at 00:12, Doug Barton wrote: >> On Wed, 19 Sep 2007, Constantine A. Murenin wrote: >>> Thanks for testing! >> >> Glad to help. In case it's interesting, I was doing the xorg >> update with portmaster last night and I got several "PROCHOT >> asserted" messages on my console at different times. I'm assuming >> that's expected behavior, just curious if it's something bad, as >> in when that happens it's time to turn off the laptop? (I didn't >> seem them when the happened, they were there when I got back to >> check on the compiling.) > > That basically means the digital sensor has detected a high > temperature and it allows the operating system to do "something". I > plan to work a bit more on coretemp(4) so that all these > notifications go through devctl(4). The CPU itself has a thermal control circuit which puts the CPU into a reduced duty cycle (ie, it reduces the core voltage and stops the CPU for something like 10 clocks, and then allows one clock through) and continues to run the CPU at about 10% of normal workload until the temperature falls below the critical threshold. There's a good document here: http://www.intel.com/technology/magazine/computing/it04021.pdf [ There are plenty of others handy if you do a search on Intel's website, but that particular link is short and readable compared with the processor spec docs. :-) ] The threshold temperature varies depending on the exact part, but is generally around 65 Celsius-- and is hot enough that you don't really want to encounter it in normal operation, as it's a sign that cooling is not adequate for the system to continue to operate safely at full speed. Most of the Intel CPUs also include a second thermal circuit called THERMTRIP which fires around 95 Celsius which will shut the CPU down entirely to prevent a catastrophic failure. A longer article is here: http://www.intel.com/technology/itj/2006/volume10issue02/ art03_power_and_thermal_management/p03_power_management.htm -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:33:40 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A71516A41A for ; Fri, 21 Sep 2007 19:33:40 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7B44713C480 for ; Fri, 21 Sep 2007 19:33:40 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 51D561CC02B; Fri, 21 Sep 2007 12:33:40 -0700 (PDT) Date: Fri, 21 Sep 2007 12:33:40 -0700 From: Jeremy Chadwick To: Chuck Swiger Message-ID: <20070921193340.GA70365@eos.sc1.parodius.com> Mail-Followup-To: Chuck Swiger , Rui Paulo , Doug Barton , Alexander Leidinger , Shteryana Shopova , FreeBSD Current , "Constantine A. Murenin" References: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> <46E9FC0C.70607@FreeBSD.org> <46F1A96F.2040602@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Rui Paulo , Doug Barton , "Constantine A. Murenin" , Shteryana Shopova , FreeBSD Current , Alexander Leidinger Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:33:40 -0000 On Fri, Sep 21, 2007 at 12:20:07PM -0700, Chuck Swiger wrote: > The CPU itself has a thermal control circuit which puts the CPU into a > reduced duty cycle (ie, it reduces the core voltage and stops the CPU for > something like 10 clocks, and then allows one clock through) and continues > to run the CPU at about 10% of normal workload until the temperature falls > below the critical threshold. There's a good document here: Are you referring to the Core 2 Duo C1E (Enhanced Halt State) processor feature or the EIST feature? I'm guessing C1E. Note that for C1E to work, it has to be enabled/available in the BIOS. I'll add that C1E is really great, dropping temperatures during idle periods by about 5-6C from what I've seen. The additional C[234]E states (at least for desktops) don't provide much benefit, but C1E definitely does. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:35:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8717D16A420 for ; Fri, 21 Sep 2007 19:35:26 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id CE18713C507; Fri, 21 Sep 2007 19:35:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F41CFF.6080108@FreeBSD.org> Date: Fri, 21 Sep 2007 21:35:27 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Larry Rosenman References: <20070921102946.T11189@borg> <46F415BF.9010500@FreeBSD.org> <20070921140550.D96923@thebighonker.lerctr.org> In-Reply-To: <20070921140550.D96923@thebighonker.lerctr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: panic: kmem_malloc(131072): kmem_map too small (AMD64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:35:26 -0000 Larry Rosenman wrote: > On Fri, 21 Sep 2007, Kris Kennaway wrote: > >> Larry Rosenman wrote: >>> I'm a heavy ZFS user, and got the following panic on 2007-09-18 >>> source/world: >> >> This is a FAQ, please see the archives (you need to increase the >> vm.kmem_size to provide more memory to ZFS). > > I thought that was only for i386, and it hadn't been an issue before. Nope. It is also load-dependent. Kris From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:44:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27DCC16A417 for ; Fri, 21 Sep 2007 19:44:29 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id D689D13C448 for ; Fri, 21 Sep 2007 19:44:28 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so643859wxd for ; Fri, 21 Sep 2007 12:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=fPSVJSGOOLQml7nhnNvTyB+9+BNlVRq9WBqnYYkrOhw=; b=CBq6pKkWMwmi6GaILOzzjBvPU9j7iL4I+FsP2sLvu451apBh5he4kglprDaD892rrUfcZ7+nzd09VdzPOS6d+Mcv8aLYEu/wA4DNeryQdUfFGbqUKAa2DJWmOSYzk8SILFPI3603wa609RjuVv+m69JbZDmcOEmakghs1xWWGoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Za9LhpACey+adTk3KvATIixv4Sbh1Z/X7sWirrVxIm+qfE6donhNoNLOhQxD0ol+XPsp2ZI0dd8jBgb1zBS9mdI+/SD0ZRpkOilAfhVXebxuQCXcfSPLTI46yA0Zva5stPibOYk7RG+VkUmjPg9FAtkhc6d7NCASh/rktw+QuwQ= Received: by 10.90.63.16 with SMTP id l16mr2933084aga.1190403867131; Fri, 21 Sep 2007 12:44:27 -0700 (PDT) Received: by 10.90.106.19 with HTTP; Fri, 21 Sep 2007 12:44:27 -0700 (PDT) Message-ID: Date: Fri, 21 Sep 2007 14:44:27 -0500 From: Matt To: "Alexander Leidinger" In-Reply-To: <20070921211541.1b6d6ca0@deskjail> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070921211541.1b6d6ca0@deskjail> Cc: freebsd-current@freebsd.org Subject: Re: Unexpected gcc linking behavior on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:44:29 -0000 On 9/21/07, Alexander Leidinger wrote: > Quoting Matt (Fri, 21 Sep 2007 13:36:24 -0500): > > > > > kBuild: Linking > > VBoxSVCout/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x313): > > In function `__static_initialization_and_destruction_0': > > src/VBox/Main/linux/server.cpp:594: undefined reference to `_292' > > out/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x31d):src/VBox/Main/linux/server.cpp:594: > > undefined reference to `_292' > > I've seen something like this because of compiler bugs depending on the > optimization level. Try different optimization levels and have a look > what happens (complete rebuild of the source in question). > > Bye, > Alexander. > Thank you for the suggestion. I thought that a possibility as well, and I've changed all optimization levels to -O1 and added -fno-tree-vrp to CFLAGS as I've seen suggested for the various jdk15 and jdk16 build issues. This has unfortunately not helped. Matt From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:48:48 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C706616A469; Fri, 21 Sep 2007 19:48:48 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 9E38C13C4A5; Fri, 21 Sep 2007 19:48:48 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 7BA8B11F1DB9; Fri, 21 Sep 2007 12:48:48 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Mail Security) with ESMTP id 5683B2805B; Fri, 21 Sep 2007 12:48:48 -0700 (PDT) X-AuditID: 1180711d-a235dbb000006cd8-6d-46f4201fe1d2 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay13.apple.com (Apple SCV relay) with ESMTP id D06FC28097; Fri, 21 Sep 2007 12:48:47 -0700 (PDT) In-Reply-To: <20070921193340.GA70365@eos.sc1.parodius.com> References: <200709132302.l8DN2Tv5076033@repoman.freebsd.org> <46E9FC0C.70607@FreeBSD.org> <46F1A96F.2040602@FreeBSD.org> <20070921193340.GA70365@eos.sc1.parodius.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <386DE04B-11B1-47A9-BF12-73D770C6A851@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 21 Sep 2007 12:48:46 -0700 To: Jeremy Chadwick X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: Rui Paulo , Doug Barton , "Constantine A. Murenin" , Shteryana Shopova , FreeBSD Current , Alexander Leidinger Subject: Re: GSoC2007: cnst-sensors.2007-09-13.patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:48:48 -0000 On Sep 21, 2007, at 12:33 PM, Jeremy Chadwick wrote: > On Fri, Sep 21, 2007 at 12:20:07PM -0700, Chuck Swiger wrote: >> The CPU itself has a thermal control circuit which puts the CPU >> into a >> reduced duty cycle (ie, it reduces the core voltage and stops the >> CPU for >> something like 10 clocks, and then allows one clock through) and >> continues >> to run the CPU at about 10% of normal workload until the >> temperature falls >> below the critical threshold. There's a good document here: > > Are you referring to the Core 2 Duo C1E (Enhanced Halt State) > processor > feature or the EIST feature? I'm guessing C1E. Note that for C1E to > work, it has to be enabled/available in the BIOS. > > I'll add that C1E is really great, dropping temperatures during idle > periods by about 5-6C from what I've seen. The additional C[234]E > states (at least for desktops) don't provide much benefit, but C1E > definitely does. Nope, although the second link I mentioned does discuss the state diagram the Core processors use for transitioning between various ACPI sleep states also in order to reduce power usage and hence thermal dissipation. That does indeed require ACPI to be enabled/ supported in the BIOS, as you've said. Anyway, the PROCHOT signal originated back circa the Pentium-3's or Pentium-M/Centrino's and has been included with the P4/Xeon and now Core/Core2's also-- it's a fallback mechanism which does not require BIOS support, and involves changes which reduce the CPU core voltage supplied by the voltage regulator circuitry and what Intel calls "modulating" the CPU clock to reduce the effective clock frequency it is running at by running at roughly a 10% duty cycle (this varies depending on the specific part), even if the external clock doesn't change the way it does with SpeedStep/EIST. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 19:56:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C233016A417 for ; Fri, 21 Sep 2007 19:56:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from gnome.kiev.sovam.com (gnome.kiev.sovam.com [212.109.32.24]) by mx1.freebsd.org (Postfix) with ESMTP id 697CC13C465 for ; Fri, 21 Sep 2007 19:56:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com ([62.64.120.197]) by gnome.kiev.sovam.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IYobe-000M3r-KH for freebsd-current@freebsd.org; Fri, 21 Sep 2007 22:56:06 +0300 Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IYnaZ-0004mA-QH for freebsd-current@freebsd.org; Fri, 21 Sep 2007 21:51:04 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l8LIoobr087160; Fri, 21 Sep 2007 21:50:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l8LIoo2M087159; Fri, 21 Sep 2007 21:50:50 +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: Fri, 21 Sep 2007 21:50:50 +0300 From: Kostik Belousov To: Boris Samorodov Message-ID: <20070921185050.GL79542@deviant.kiev.zoral.com.ua> References: <96913676@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SvPICi00/oKz9jF1" Content-Disposition: inline In-Reply-To: <96913676@srv.sem.ipt.ru> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 5e2df25549de819b25d1bfd51e9f52eb X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1513 [September 21 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release X-Delayed: more then 1h on relay02.kiev.sovam.com Cc: freebsd-current@freebsd.org Subject: Re: duplicate lock of same type: "vnode interlock" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 19:56:07 -0000 --SvPICi00/oKz9jF1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 21, 2007 at 10:44:19PM +0400, Boris Samorodov wrote: > Hi! >=20 > Today at: > # uname -a > FreeBSD test.ipt.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Fri Sep 21 18:36:= 28 MSD 2007 bsam@test.ipt.ru:/usr/obj/usr/src/sys/TEST amd64 >=20 > I've got: > ----- > Mounting local file systems:acquiring duplicate lock of same type: "vnode= interlock" > 1st vnode interlock @ /usr/src/sys/kern/vfs_vnops.c:807 > 2nd vnode interlock @ /usr/src/sys/kern/vfs_subr.c:2081 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > witness_checkorder() at witness_checkorder+0x5f8 > _mtx_lock_flags() at _mtx_lock_flags+0x75 > vrefcnt() at vrefcnt+0x31 > null_checkvp() at null_checkvp+0x1d > null_lock() at null_lock+0x5b > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x79 > _vn_lock() at _vn_lock+0x94 > nullfs_root() at nullfs_root+0x59 > vfs_donmount() at vfs_donmount+0x1150 > nmount() at nmount+0x97 > syscall() at syscall+0x1f6 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x80068465c, rsp =3D 0x= 7fffffffe518, rbp =3D 0x7fffffffe520 --- > ----- >=20 > Should I worry about it? No. > The system boots and seems to we fine... --SvPICi00/oKz9jF1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG9BKJC3+MBN1Mb4gRAiUVAJ9XmPCjUUGv19uoAI3tpEHoNcIlTgCgztTS EsqcTxLoI5cuJ4qMglJiMaE= =3F/2 -----END PGP SIGNATURE----- --SvPICi00/oKz9jF1-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 20:25:24 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A75A16A420 for ; Fri, 21 Sep 2007 20:25:24 +0000 (UTC) (envelope-from cb@severious.net) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 87DAF13C467 for ; Fri, 21 Sep 2007 20:25:24 +0000 (UTC) (envelope-from cb@severious.net) Received: by ion.gank.org (Postfix, from userid 1001) id 337511158E; Fri, 21 Sep 2007 15:25:24 -0500 (CDT) Date: Fri, 21 Sep 2007 15:25:24 -0500 From: Craig Boston To: current@freebsd.org Message-ID: <20070921202523.GB4044@nowhere> Mail-Followup-To: Craig Boston , current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: nvidia driver on recent current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 20:25:24 -0000 I've been getting a lot of these panics on recent -current builds that are being caused by the nvidia driver: panic: spin locks can only use msleep_spin I managed to compile the part of the driver that there is source code for with debug symbols, but the only thing that's showing up in the stack trace are obfuscated function names from the binary module. Some of the addresses look very suspicious, so it seems the stack is likely corrupted. (the nvidia module exists at 0xc0c2e000 - 0xc13cf000, the ones in the 0xc590+ range don't seem to correspond to any loaded module) #3 0xc06de0e2 in unlock_spin (lock=Could not find the frame base for "unlock_spin". ) at /compile/src/sys/kern/kern_mutex.c:166 #4 0xc06b46fb in _cv_wait (cvp=0xc59d6a18, lock=0xc59d6a00) at /compile/src/sys/kern/kern_condvar.c:131 #5 0xc1012c71 in ?? () #6 0xc59d6a18 in ?? () #7 0xc59d6a00 in ?? () #8 0xc110a9b0 in ?? () #9 0x00000273 in ?? () #10 0xc5a17000 in ?? () #11 0xc593e800 in ?? () #12 0xff78e84c in ?? () #13 0xc0ce5316 in _nv009651rm () #14 0xc59d6a00 in ?? () #15 0x20000000 in ?? () #16 0x00000028 in ?? () #17 0xc5a2dd00 in ?? () #18 0xff78e86c in ?? () #19 0xc9c8e8e0 in ?? () #20 0xff78e86c in ?? () #21 0xc0cedda4 in _nv009831rm () #22 0xc59d6a00 in ?? () #23 0x00000001 in ?? () #24 0x00000000 in ?? () #25 0xc9c8e8e0 in ?? () #26 0xc9c8e8e0 in ?? () #27 0xc5a2dc00 in ?? () #28 0xff78e88c in ?? () #29 0xc1014ca8 in ?? () #30 0x00000000 in ?? () #31 0xc5a2dd00 in ?? () #32 0xc9332b00 in ?? () #33 0xc5a2dc00 in ?? () #34 0xc5a2dd00 in ?? () #35 0xc5a2de00 in ?? () #36 0xff78e8ac in ?? () #37 0xc1011e0b in ?? () #38 0xc5a2dc00 in ?? () #39 0xc5a2de00 in ?? () #40 0xd7769800 in ?? () #41 0xc5a2de00 in ?? () #42 0xca61faa0 in ?? () #43 0xc1365f60 in ?? () #44 0xff78e8cc in ?? () #45 0xc06b6c13 in giant_close (dev=0xc59d6a00, fflag=536870912, devtype=40, td=0xc5a2dd00) at /compile/src/sys/kern/kern_conf.c:327 (kgdb) up 3 166 panic("spin locks can only use msleep_spin"); (kgdb) print lock Could not find the frame base for "unlock_spin". (kgdb) up 1 #4 0xc06b46fb in _cv_wait (cvp=0xc59d6a18, lock=0xc59d6a00) at /compile/src/sys/kern/kern_condvar.c:131 131 lock_state = class->lc_unlock(lock); (kgdb) print *lock $8 = {lo_name = 0xc110a995 "rm.mutex_mtx", lo_type = 0xc110a995 "rm.mutex_mtx", lo_flags = 720896, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}} (kgdb) print *class $10 = {lc_name = 0xc095aba9 "spin mutex", lc_flags = 10, lc_ddb_show = 0, lc_lock = 0xc06de0f0 , lc_unlock = 0xc06de0d0 } rm.mutex_mtx is indeed created in nvidia_os.c with mtx_init(&mtx->mutex_mtx, "rm.mutex_mtx", NULL, MTX_SPIN | MTX_RECURSE); I don't see any explicit calls to unlock_spin in the part we have source for, just mtx_unlock_spin. I'm unsure why the spin mutex class has pointers to these dummy functions that simply panic, but I'm not very well versed on the internals of kernel lock primitives. Any suggestions? I'm not sure if this is an nvidia problem that we need to refer to them or if a change in the kernel has broken something it depends on. Craig From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 20:59:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FA6F16A419 for ; Fri, 21 Sep 2007 20:59:37 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0334413C4B6 for ; Fri, 21 Sep 2007 20:59:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so824297nfb for ; Fri, 21 Sep 2007 13:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=EyOAz5HMs73h6BpM6UY/hP8Q8HYxmNXtGjwgJUfA+4Q=; b=t4aFQtXbWlcR4mvXd9oQlfpCaAcayY7eU/4FRh+6QmozvQUehpWGGwmJy8UzGWI5HptSS2WmKGM0PCYZQykiXjoes2XozsVdPV7ZTqVuQzA3YNfoHG6H6c8WenTGewDUkqavtbYuioBpPtaLilOiIUhOfQjK/w7u5L+z0KFaiOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K4t7YN4/coJr7LD7YuiwTsc0zN4UzlIs/bqfgKO4cJHe8knfD69XjEnIJWD7gR1j7GVVshN/oKa4oTtT4mkZ3R1ItZuZpFN8hQS8+ZNivByO9YyzZJggjiLQ6N44NwiVX/J58ndPH86Lxyp5I+42kDPT2rkZVM8x/MWYY9ND8AI= Received: by 10.86.97.7 with SMTP id u7mr290624fgb.1190408375519; Fri, 21 Sep 2007 13:59:35 -0700 (PDT) Received: by 10.86.100.19 with HTTP; Fri, 21 Sep 2007 13:59:35 -0700 (PDT) Message-ID: <2a41acea0709211359w37ba779dsec94de504a9f4a9c@mail.gmail.com> Date: Fri, 21 Sep 2007 13:59:35 -0700 From: "Jack Vogel" To: "Artem Kuchin" In-Reply-To: <01c801c7fc7a$696ab900$0c00a8c0@Artem> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <01c801c7fc7a$696ab900$0c00a8c0@Artem> Cc: freebsd-current@freebsd.org Subject: Re: TSP on em makes send of streams very slow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 20:59:37 -0000 On 9/21/07, Artem Kuchin wrote: > Hello! > > Here is what i have experienced today. > > I just installed 7.0-CURRENT (cvsed and build on 2007/09/20) > on a PRODUCTION web server > (because, IHMO, this current is stable enough and i like > too much :) > > This is intel MB with two built-in em intefaces. > > I sshed to the server. > While i was in plain shell everything was fine, but when i > stared midnight commander i saw how it very slowly draws > scren part by part. It took about 3 monutes to almost > completely draw a screen when i got disconnected. I tied again > - the same. Then i connected via ftp and uploaded 10MB file > at 900KB/sec. When i tried to download it back i got about > 500 *BYTES*/sec and the got disconnected in a couple of minutes. > > Ping was just find, even flood ping from the server on the save > switch with 15000 packets was fine (just one dot on the left). > > I went also crazy already when i desided to compare interface params > with another server with em NICs. > > The dfference is that this is has the following options (by DEFAULT, > i did not turn it on): > > VLAN_HWCSUM,TSO4 > > I've read about TSO on 'man ifconfig' and just for kicks decided > to turn it off. VOILA!!! In a seconds send speed was up to 10 MBYTES/sec! > > I have googled about 'em tso slow ' etc.. and found a couple of seemingly > the same problem dated back 2006. Is it supposed to be solved by now? > What IS the problem with TSO? TSO is for some environments, it isn't gonna be useful at 100Mb (which you are), it can be useful at 1Gb but not always, when you get to 10G its a HUGE benefit. Just cuz you can shoot yourself in the foot doesn't mean the gun has a problem :) Jack From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 21:13:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A1DE16A418; Fri, 21 Sep 2007 21:13:38 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5A6D713C45D; Fri, 21 Sep 2007 21:13:38 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8LLDaT1098637 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 21 Sep 2007 17:13:37 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Fri, 21 Sep 2007 14:16:25 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Roman Bogorodskiy In-Reply-To: <20070921154033.GA46811@underworld.novel.ru> Message-ID: <20070921141348.I547@10.0.0.1> References: <20070916061932.GA93480@underworld.novel.ru> <20070915234855.G531@10.0.0.1> <20070916071421.GA1320@underworld.novel.ru> <20070916003323.U4507@10.0.0.1> <20070917044351.GA17565@underworld.novel.ru> <20070917162400.GA42669@underworld.novel.ru> <20070917141820.M558@10.0.0.1> <20070918155244.GA1336@underworld.novel.ru> <20070921154033.GA46811@underworld.novel.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 21:13:38 -0000 On Fri, 21 Sep 2007, Roman Bogorodskiy wrote: > > > Here's what I got today: > http://people.freebsd.org/~novel/misc/out.tar.bz2 > > I run this command when x11 windows became to take quite a long to > redraw (several seconds). Though it's not the worst thing I got, so I > will drop a mail as soon as I will be able to 'catch' harder 'freeze'. There's really nothing unusual in this trace. You only have a few seconds to record it though. Perhaps you missed the window. Thanks, Jeff > > Roman Bogorodskiy > From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 21:20:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4451D16A417; Fri, 21 Sep 2007 21:20:48 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9151913C44B; Fri, 21 Sep 2007 21:20:47 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup236.ach.sch.gr [81.186.70.236]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l8LLJcx9020566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Sep 2007 00:19:59 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l8LLJQnF002008; Sat, 22 Sep 2007 00:19:27 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l8LLJO9J002007; Sat, 22 Sep 2007 00:19:24 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sat, 22 Sep 2007 00:19:23 +0300 From: Giorgos Keramidas To: Boris Samorodov Message-ID: <20070921211923.GA1948@kobe.laptop> References: <20070920184201.GA72805@kobe.laptop> <20070920184606.GA73060@kobe.laptop> <20070920223015.GA88368@blazingdot.com> <20070920224336.GA94445@blazingdot.com> <30854022@srv.sem.ipt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30854022@srv.sem.ipt.ru> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.891, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.51, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org, Colin Percival Subject: Re: portsnap snapshot corruption? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 21:20:48 -0000 On 2007-09-21 02:56, Boris Samorodov wrote: > > I should provide a couple more details of what I've seen: > > > - The portsnap fetch downloads the 49MB .tgz, and it extracts > > properly. This file is not corrupted (passes gzip checksum). > > > - In the portsnap/snap directory, many of the .gz > > files are correct, but many (looks like 1/4?) of them are > > truncated somehow. They are gzip files, but they are corrupted. > > Isn't it related to a recent libarchive backout?: > . src/lib/libarchive/archive_write_disk.c rev.1.16 > . src/lib/libarchive/test/test_write_disk.c rev.1.5 It is, at least for me. Rebuilding to pull the libarchive update fixed portsnap, yay :) Thanks for the help everyon. From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 21:40:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7786016A41B; Fri, 21 Sep 2007 21:40:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 0BDE713C4C4; Fri, 21 Sep 2007 21:40:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8p) with ESMTP id 210673077-1834499 for multiple; Fri, 21 Sep 2007 17:22:43 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l8LLOATg064127; Fri, 21 Sep 2007 17:24:12 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Fri, 21 Sep 2007 17:15:17 -0400 User-Agent: KMail/1.9.6 References: <200709181516.11207.jkim@FreeBSD.org> In-Reply-To: <200709181516.11207.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709211715.17940.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 21 Sep 2007 17:24:12 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4357/Fri Sep 21 05:55:46 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [PATCH] OsdSynch.c modernization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 21:40:27 -0000 On Tuesday 18 September 2007 03:16:07 pm Jung-uk Kim wrote: > I have rewritten sys/dev/acpica/Osd/OsdSynch.c to match the modern > ACPI-CA and -CURRENT: > > http://people.freebsd.org/~jkim/acpica/OsdSynch.diff Why do you use a loop around tsleep() rather than just use sx_xlock() (which will block) for the WAIT_FOREVER case when waiting on a semaphore? Why don't you just use a spin mutex for the spin lock? That is a far better fit than the sx lock stuff you are doing. Manually doing spinlock_enter() (wrongly btw, you should use critical_enter(), not sched_pin() otherwise you can be preempted) just to avoid the assertion failure is just going to result in obscure hangs. Does ACPI-CA want to malloc() while holding an ACPI spin lock or something? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 21:53:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E16A16A417 for ; Fri, 21 Sep 2007 21:53:58 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 25E0413C4A8 for ; Fri, 21 Sep 2007 21:53:57 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from [217.184.120.61] (mnch-d9b8783d.pool.mediaWays.net [217.184.120.61]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l8LLrtbc020735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Sep 2007 23:53:56 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host mnch-d9b8783d.pool.mediaWays.net [217.184.120.61] claimed to be [217.184.120.61] Message-ID: <46F43D73.4010804@omnisec.de> Date: Fri, 21 Sep 2007 23:53:55 +0200 From: Harald Schmalzbauer User-Agent: Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: cpdup into base? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 21:53:58 -0000 Hello, I just set up a intermediate backup server and copied some view hundred Gig'bytes in a ssh session. Then it came to my mind that I'm on a dialup line which get's cut at day change, so if my last 76G transfer wouldn't finish before I had to repeat it. My first fault was not to use "screen", but like I wrote it's a improvised intermediate server. Now if I had cpdup this wasn't a big problem... Of course there's 'pkg_add -r', but I'm using -current and I don't know if there's a working package, nor that it's fetchable. Is there anything against merging cpdup into base? Thanks, -Harry From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 21:54:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CF5C16A41A for ; Fri, 21 Sep 2007 21:54:11 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.freebsd.org (Postfix) with ESMTP id 3869513C458 for ; Fri, 21 Sep 2007 21:54:11 +0000 (UTC) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 05F30732FF; Fri, 21 Sep 2007 21:57:10 +0000 (GMT) Date: Fri, 21 Sep 2007 21:57:09 +0000 From: John Birrell To: Doug Rabson Message-ID: <20070921215709.GA23720@what-creek.com> References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> <20070920203413.GA13737@what-creek.com> <46F367E0.4000300@freebsd.org> <20070921070347.GA17990@what-creek.com> <1190360869.1627.9.camel@herring.rabson.org> <20070921081106.GA18488@what-creek.com> <1190362467.1627.13.camel@herring.rabson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1190362467.1627.13.camel@herring.rabson.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 21:54:11 -0000 On Fri, Sep 21, 2007 at 09:14:27AM +0100, Doug Rabson wrote: > I see your problem. How about adding a char td_dtrace_reserved[some > number] which can be cast into a dtrace structure in dtrace code but > which is opaque to normal kernel code? I am going to allocate the DTrace part like the scheduler stuff gets allocated - at the end using the uma zone calls. That way it will really be opaque. When the DTrace modules want to get at their private variables they can just offset the thread pointer. Unlike the td_sched, there won't be a pointer in the visible struct thread to retain binary compatibility with the release. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 21:55:25 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A71EA16A41A for ; Fri, 21 Sep 2007 21:55:25 +0000 (UTC) (envelope-from cb@severious.net) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 9645413C478 for ; Fri, 21 Sep 2007 21:55:25 +0000 (UTC) (envelope-from cb@severious.net) Received: by ion.gank.org (Postfix, from userid 1001) id 5DE1D10F44; Fri, 21 Sep 2007 16:55:25 -0500 (CDT) Date: Fri, 21 Sep 2007 16:55:24 -0500 From: Craig Boston To: current@freebsd.org Message-ID: <20070921215514.GA1114@nowhere> Mail-Followup-To: Craig Boston , current@freebsd.org References: <20070921202523.GB4044@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070921202523.GB4044@nowhere> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: nvidia driver on recent current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 21:55:25 -0000 On Fri, Sep 21, 2007 at 03:25:24PM -0500, Craig Boston wrote: > Some of the addresses look very suspicious, so it seems the stack is > likely corrupted. Now that I think about it, the stack isn't corrupt. Those are just the arguments for the ?? functions that kgdb can't work out the prototype for. A little extra info, this is the newest nvidia driver -- 100.14.11. It happens on a kernel from last week, as well as an 8/31 build that I tried rolling back to. Before that it was stable for months, but as it's somewhat intermittent it may take a while to locate the exact change. Running multiple GL clients at once seems to be a good way, and it almost always happens just as one terminates. This is an SMP system. I habitually add -DKSE -DSMP to the nvidia driver CFLAGS between the 'make patch' and 'make build' steps in the port install, but taking those out doesn't seem to have any effect. Craig From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 21:57:22 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B6BC16A418 for ; Fri, 21 Sep 2007 21:57:22 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id 9279F13C447 for ; Fri, 21 Sep 2007 21:57:21 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so1873043pyb for ; Fri, 21 Sep 2007 14:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=W4XTmTZcyDqvMwy+OD+Lx4mWuxNkFIRzPEAdaa8RLPY=; b=PcIP7/plPNgaLSd+lr+0GLLruZMTC5+Lc3jW0ZhwYxaxNLMVUJTRngvMA/GO8m5BQoQbbLKQu2M8mKnYwbjKpcrRSZqwPrMcCAw2Wgx8ARtyUPS4p/zCVNu59eP1MZTeGiUq2kV8EpqDZjpZW5ywdB4T86BQIUi5muhSoupOj+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=SwJHpl8qHHH/mLScvSEZD3eZ7gvxa3BpPgKXdcBc3d8/kdOL0mkm4vpyb50dzOmZS+yK5gvb+U/JA5WrZ+ucVBS/bDehFerNcXC7Vo/HzIA9rgAoEkZX1iTRxrfbq8pIqvVxQs1i0qwIPput95+dGp1ymnb18fRfKHfTYdC3Yzw= Received: by 10.65.234.2 with SMTP id l2mr1875744qbr.1190411839753; Fri, 21 Sep 2007 14:57:19 -0700 (PDT) Received: by 10.64.233.13 with HTTP; Fri, 21 Sep 2007 14:57:19 -0700 (PDT) Message-ID: <8e10486b0709211457v7771bd66kf3df5ea45ab0d325@mail.gmail.com> Date: Fri, 21 Sep 2007 18:57:19 -0300 From: "Alexandre Biancalana" To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: process size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 21:57:22 -0000 Hi List, I'm trying to copy ~800GB to my new backup server via rsync, but the rsync process die when it's vsz is close to 1G with the following message: # rsync -av 192.168.0.13::root/backup/* . receiving file list ... ERROR: out of memory in make_file rsync error: error allocating core memory buffers (code 22) at util.c(120) [sender=2.6.8] rsync: connection unexpectedly closed (155637057 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(462) [receiver=2.6.9] Here is the last ps -aux line of the process before die: root 856 0.4 68.1 915248 707048 p0 S+ 6:32PM 0:12.51 rsync -av 192.168.0.13::root/backup/* . # limits Resource limits (current): cputime infinity secs filesize infinity kB datasize 4194304 kB stacksize 2097152 kB coredumpsize infinity kB memoryuse infinity kB memorylocked infinity kB maxprocesses 5547 openfiles 11095 sbsize infinity bytes vmemoryuse infinity kB I tried to set insane high values of data and stack: kern.maxdsiz="4294967296" kern.dfldsiz="4294967296" kern.maxssiz="2147483648" vm.kmem_size_max="1073741824" vm.kmem_size="1073741824" This is -CURRENT compiled today with 1GB Ram and ZFS. Am I tuning the wrong values ? Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #2: Fri Sep 21 18:06:33 BRT 2007 root@:/usr/obj/usr/src/sys/BACKUP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2409.69-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Logical CPUs per core: 2 usable memory = 1062912000 (1013 MB) avail memory = 1022889984 (975 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est1 attach returned 6 p4tcc1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 arcmsr0: mem 0x44100000-0x44101fff irq 16 at device 0.0 on pci2 ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 arcmsr0: [ITHREAD] pcib3: at device 28.0 on pci0 pci3: on pcib3 pcib4: at device 28.4 on pci0 pci4: on pcib4 pcib5: at device 28.5 on pci0 pci5: on pcib5 em0: port 0x1000-0x101f mem 0x44000000-0x4401ffff irq 17 at device 0.0 on pci5 em0: Ethernet address: 00:19:d1:11:f0:6c em0: [FILTER] uhci0: port 0x2080-0x209f irq 23 at device 29.0 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 uhci1: port 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2020-0x203f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0x44200400-0x442007ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib6: at device 30.0 on pci0 pci6: on pcib6 vgapci0: mem 0x40000000-0x43ffffff irq 18 at device 2.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20b0-0x20bf irq 18 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x20c8-0x20cf,0x20e4-0x20e7,0x20c0-0x20c7,0x20e0-0x20e3,0x20a0-0x20af mem 0x44200000-0x442003ff irq 19 at device 31.2 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] pci0: at device 31.3 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0 fdc0: [FILTER] 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: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range 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 ukbd0: on uhub1 kbd2 at ukbd0 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle ad0: 76319MB at ata0-master UDMA100 (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step SMP: AP CPU #1 Launched! da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: 3814696MB (7812497408 512 byte sectors: 255H 63S/T 486305C) Trying to mount root from ufs:/dev/ad0s1a WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 22:15:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC85B16A418 for ; Fri, 21 Sep 2007 22:15:09 +0000 (UTC) (envelope-from e.schuele@computer.org) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by mx1.freebsd.org (Postfix) with SMTP id B281513C481 for ; Fri, 21 Sep 2007 22:15:09 +0000 (UTC) (envelope-from e.schuele@computer.org) Received: (qmail 7237 invoked from network); 21 Sep 2007 22:15:08 -0000 Received: from unknown (96.226.25.79) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 21 Sep 2007 22:15:08 -0000 Message-ID: <46F4426B.50605@computer.org> Date: Fri, 21 Sep 2007 17:15:07 -0500 From: Eric Schuele User-Agent: Thunderbird 2.0.0.6 (X11/20070921) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <46E98E44.2070808@computer.org> <20070919125029.GB45191@heechee.tobez.org> <46F12770.30807@computer.org> <20070919144344.GA50818@heechee.tobez.org> <46F13A92.6000407@computer.org> <20070919215850.GA4229@heechee.tobez.org> <20070919222103.GB4229@heechee.tobez.org> In-Reply-To: <20070919222103.GB4229@heechee.tobez.org> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.ravenlock.us/files/pub_schuele.pgp Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig97E214CEDF010FF80BEBADAC" Cc: Subject: Re: Perl_mallloc() segfault (v5.8.8).... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 22:15:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig97E214CEDF010FF80BEBADAC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/19/2007 17:21, Anton Berezin wrote: > On Wed, Sep 19, 2007 at 11:58:50PM +0200, Anton Berezin wrote: >> On Wed, Sep 19, 2007 at 10:04:50AM -0500, Eric Schuele wrote: >>> On 09/19/2007 09:43, Anton Berezin wrote: >>>> On Wed, Sep 19, 2007 at 08:43:12AM -0500, Eric Schuele wrote: >>>>> On 09/19/2007 07:50, Anton Berezin wrote: >>>>>> What is the script? >>>>> Its called OnJoin for xchat. Performs actions when ppl join. >>>> Right. Do you have a link to it? Googling it seems to lead to a lo= t of >>>> dead links... >>> Attached is the zip file I pulled down originally. >> Thanks. >> >> Ok, I can reproduce it here. Stay tuned. :-) >=20 > Ok. You need to have threaded perl to use together with xchat. Recomp= ile > lang/perl5.8 with WITH_THREADS=3Dyes. Please note that all ports that = link > with perl will have to be reinstalled as well. Excellent! That did the trick. Thanks for your help! :) >=20 > In the next update to lang/perl5.8 I intend to fix this problem even fo= r > non-threaded perl, but for now that's the only way. >=20 > Cheers, > \Anton. --=20 Regards, Eric --------------enig97E214CEDF010FF80BEBADAC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG9EJrngSDRM3IXUoRAjAqAKCF4n3S0TqY/qXDM8xU0RHzkn1frQCfakfp trfpTh4pMAKuS1Ol0VFeuFI= =GHlb -----END PGP SIGNATURE----- --------------enig97E214CEDF010FF80BEBADAC-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 22:27:33 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB95416A418; Fri, 21 Sep 2007 22:27:33 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 8C74413C480; Fri, 21 Sep 2007 22:27:33 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8LMRWHP060818; Fri, 21 Sep 2007 18:27:32 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Fri, 21 Sep 2007 18:27:28 -0400 User-Agent: KMail/1.6.2 References: <200709181516.11207.jkim@FreeBSD.org> <200709211715.17940.jhb@freebsd.org> In-Reply-To: <200709211715.17940.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709211827.29763.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [PATCH] OsdSynch.c modernization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 22:27:33 -0000 On Friday 21 September 2007 05:15 pm, John Baldwin wrote: > On Tuesday 18 September 2007 03:16:07 pm Jung-uk Kim wrote: > > I have rewritten sys/dev/acpica/Osd/OsdSynch.c to match the > > modern ACPI-CA and -CURRENT: > > > > http://people.freebsd.org/~jkim/acpica/OsdSynch.diff > > Why do you use a loop around tsleep() rather than just use > sx_xlock() (which will block) for the WAIT_FOREVER case when > waiting on a semaphore? You mean for AcpiOsAcquireMutex()? sx_xlock() cannot be waken up by the wait channel. > Why don't you just use a spin mutex for the spin lock? > That is a far better fit than the sx lock stuff you are doing. > Manually doing spinlock_enter() (wrongly btw, you should use > critical_enter(), not sched_pin() otherwise you can be preempted) > just to avoid the assertion failure is just going to result in > obscure hangs. Does ACPI-CA want to malloc() while holding an ACPI > spin lock or something? I thought exactly the same when I started rewriting it (almost half year ago!). I have tried all of the above, spent numerous sleepless nights, and miserably failed. :-( Spin mutex is too restrictive (e.g., it cannot be used with other locks gracefully). critical_enter() causes: panic: blockable sleep lock (sleep mutex) 32 @ /usr/src/sys/vm/uma_core.c:1830 cpuid = 0 KDB: enter: panic [thread pid 21 tid 100013 ] Stopped at kdb_enter+0x32: leave http://docs.freebsd.org/cgi/mid.cgi?200709121927.46465.jkim I guess it wants to malloc() while holding spin lock although I haven't traced it down. I intend to investigate and fix further after RELENG_7 is branched and I really like to hear more ideas from you. Thanks, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 23:41:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B5DF16A41B for ; Fri, 21 Sep 2007 23:41:42 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 8793913C447; Fri, 21 Sep 2007 23:41:40 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F456B6.5060509@FreeBSD.org> Date: Sat, 22 Sep 2007 01:41:42 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jack Vogel References: <01c801c7fc7a$696ab900$0c00a8c0@Artem> <2a41acea0709211359w37ba779dsec94de504a9f4a9c@mail.gmail.com> In-Reply-To: <2a41acea0709211359w37ba779dsec94de504a9f4a9c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Artem Kuchin , freebsd-current@freebsd.org Subject: Re: TSP on em makes send of streams very slow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 23:41:42 -0000 Jack Vogel wrote: > On 9/21/07, Artem Kuchin wrote: >> Hello! >> >> Here is what i have experienced today. >> >> I just installed 7.0-CURRENT (cvsed and build on 2007/09/20) >> on a PRODUCTION web server >> (because, IHMO, this current is stable enough and i like >> too much :) >> >> This is intel MB with two built-in em intefaces. >> >> I sshed to the server. >> While i was in plain shell everything was fine, but when i >> stared midnight commander i saw how it very slowly draws >> scren part by part. It took about 3 monutes to almost >> completely draw a screen when i got disconnected. I tied again >> - the same. Then i connected via ftp and uploaded 10MB file >> at 900KB/sec. When i tried to download it back i got about >> 500 *BYTES*/sec and the got disconnected in a couple of minutes. >> >> Ping was just find, even flood ping from the server on the save >> switch with 15000 packets was fine (just one dot on the left). >> >> I went also crazy already when i desided to compare interface params >> with another server with em NICs. >> >> The dfference is that this is has the following options (by DEFAULT, >> i did not turn it on): >> >> VLAN_HWCSUM,TSO4 >> >> I've read about TSO on 'man ifconfig' and just for kicks decided >> to turn it off. VOILA!!! In a seconds send speed was up to 10 MBYTES/sec! >> >> I have googled about 'em tso slow ' etc.. and found a couple of seemingly >> the same problem dated back 2006. Is it supposed to be solved by now? >> What IS the problem with TSO? > > TSO is for some environments, it isn't gonna be useful at 100Mb (which you > are), it can be useful at 1Gb but not always, when you get to 10G its > a HUGE benefit. > > Just cuz you can shoot yourself in the foot doesn't mean the gun has a > problem :) So the card can't handle it? Note that the OP says it was enabled automatically. I wouldn't necessarily expect it to give a performance benefit, but it shouldn't destroy performance to that extent either. There seems to be a real problem to be addressed here. Kris From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 23:44:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EDDB16A419 for ; Fri, 21 Sep 2007 23:44:22 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 6A03A13C467; Fri, 21 Sep 2007 23:44:21 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F45757.9050303@FreeBSD.org> Date: Sat, 22 Sep 2007 01:44:23 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Harald Schmalzbauer References: <46F43D73.4010804@omnisec.de> In-Reply-To: <46F43D73.4010804@omnisec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cpdup into base? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 23:44:22 -0000 Harald Schmalzbauer wrote: > Hello, > > > I just set up a intermediate backup server and copied some view hundred > Gig'bytes in a ssh session. Then it came to my mind that I'm on a dialup > line which get's cut at day change, so if my last 76G transfer wouldn't > finish before I had to repeat it. > My first fault was not to use "screen", but like I wrote it's a > improvised intermediate server. > Now if I had cpdup this wasn't a big problem... > Of course there's 'pkg_add -r', but I'm using -current and I don't know > if there's a working package, nor that it's fetchable. > > > Is there anything against merging cpdup into base? Yep, it's not required. Your objection about not knowing whether there is a working package is silly since it's so easily answered. Kris From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 00:38:24 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64F8516A417 for ; Sat, 22 Sep 2007 00:38:24 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id 5624013C459 for ; Sat, 22 Sep 2007 00:38:24 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.208] (canonware.com [64.183.146.166]) by canonware.com (Postfix) with ESMTP id C95DB1298C8; Fri, 21 Sep 2007 17:14:31 -0700 (PDT) Message-ID: <46F45CE2.9080204@freebsd.org> Date: Fri, 21 Sep 2007 17:08:02 -0700 From: Jason Evans User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Alexandre Biancalana References: <8e10486b0709211457v7771bd66kf3df5ea45ab0d325@mail.gmail.com> In-Reply-To: <8e10486b0709211457v7771bd66kf3df5ea45ab0d325@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: process size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 00:38:24 -0000 Alexandre Biancalana wrote: > I'm trying to copy ~800GB to my new backup server via rsync, but the rsync > process die when it's vsz is close to 1G with the following message: > > # rsync -av 192.168.0.13::root/backup/* . > receiving file list ... ERROR: out of memory in make_file > rsync error: error allocating core memory buffers (code 22) at util.c(120) > [sender=2.6.8] > rsync: connection unexpectedly closed (155637057 bytes received so far) > [receiver] > rsync error: error in rsync protocol data stream (code 12) at io.c(462) > [receiver=2.6.9] > > > Here is the last ps -aux line of the process before die: > > root 856 0.4 68.1 915248 707048 p0 S+ 6:32PM 0:12.51 rsync -av > 192.168.0.13::root/backup/* . You're running your system as i386 rather than amd64, right? It looks like rsync is exhausting its address space while trying to reallocate the growing (and apparently very large) file list. There's nothing surprising here to me. If you use amd64 rather than i386 you won't have this problem, though you will still see poor performance due to swapping. The most prudent solution is probably to use multiple rsync calls to copy portions of your data at a time. Jason From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 01:55:14 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B807816A418 for ; Sat, 22 Sep 2007 01:55:14 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4363413C457 for ; Sat, 22 Sep 2007 01:55:14 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so1956420pyb for ; Fri, 21 Sep 2007 18:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=NWn3whW7jcDU58lBcttaPsjt7RN9LNkC3TFec6rnh9g=; b=RIzo3g2hylfYPhSgaQUcieVIY00qZJeMbPw4uYrWINWo/Er2IGSYk01itia4dtfQd+0xzXZjU4O/drOwifgVNxhxqe7Zfc9QM3vVu2jpFFxkDAKByHs+1IGdhb79ujL0khixhJLfmqufVTo6O/0JSF4ea9BfmROqqJYdLEZBRIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qP+qUKcmK+pyKAU0NMi+oCTZGl1LrudSysUBhQzavgAErslHljXYG8m63yhmhNI1ZZiem34h37n/IrG9phUeLnizbm3zTd33wS/xK8Vwr9NIv8KVtFaaL8M5TzqieWnu+crttE2XkSPde99QxeAkSYWQGlZ2Z0sudqerY2OQ0/I= Received: by 10.65.204.7 with SMTP id g7mr551710qbq.1190426113101; Fri, 21 Sep 2007 18:55:13 -0700 (PDT) Received: by 10.64.233.13 with HTTP; Fri, 21 Sep 2007 18:55:13 -0700 (PDT) Message-ID: <8e10486b0709211855pbc3b983tf3452890f8d9b9dc@mail.gmail.com> Date: Fri, 21 Sep 2007 22:55:13 -0300 From: "Alexandre Biancalana" To: "Jason Evans" In-Reply-To: <46F45CE2.9080204@freebsd.org> MIME-Version: 1.0 References: <8e10486b0709211457v7771bd66kf3df5ea45ab0d325@mail.gmail.com> <46F45CE2.9080204@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: process size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 01:55:14 -0000 > > You're running your system as i386 rather than amd64, right? It looks > like rsync is exhausting its address space while trying to reallocate > the growing (and apparently very large) file list. There's nothing > surprising here to me. If you use amd64 rather than i386 you won't have > this problem, though you will still see poor performance due to > swapping. The most prudent solution is probably to use multiple rsync > calls to copy portions of your data at a time. Hi Jason ! I agree that this could be the problem... but I=B4m not running i386. Look this: # uname -a FreeBSD 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Fri Sep 21 18:06:33 BRT 2007 root@:/usr/obj/usr/src/sys/BACKUP amd64 Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #2: Fri Sep 21 18:06:33 BRT 2007 root@:/usr/obj/usr/src/sys/BACKUP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2409.70-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x6f6 Stepping =3D 6 Features=3D0xbfebfbff Features2=3D0xe3bd AMD Features=3D0x20100800 AMD Features2=3D0x1 Logical CPUs per core: 2 usable memory =3D 1062912000 (1013 MB) avail memory =3D 1022889984 (975 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est1 attach returned 6 p4tcc1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 arcmsr0: mem 0x44100000-0x44101fff irq 16 at device 0.0 on pci2 ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 arcmsr0: [ITHREAD] pcib3: at device 28.0 on pci0 pci3: on pcib3 pcib4: at device 28.4 on pci0 pci4: on pcib4 pcib5: at device 28.5 on pci0 pci5: on pcib5 em0: port 0x1000-0x101f mem 0x44000000-0x4401ffff irq 17 at device 0.0 on pci5 em0: Ethernet address: 00:19:d1:11:f0:6c em0: [FILTER] uhci0: port 0x2080-0x209f irq 23 at device 29.0 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 uhci1: port 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2020-0x203f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0x44200400-0x442007f= f irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib6: at device 30.0 on pci0 pci6: on pcib6 vgapci0: mem 0x40000000-0x43ffffff irq 18 at devic= e 2.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20b0-0x20bf irq 18 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x20c8-0x20cf,0x20e4-0x20e7,0x20c0-0x20c7,0x20e0-0x20e3,0x20a0-0x20af mem 0x44200000-0x442003ff irq 19 at device 31.2 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] pci0: at device 31.3 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0 fdc0: [FILTER] 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: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> 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 ukbd0: on uhub1 kbd2 at ukbd0 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle ad0: 76319MB at ata0-master UDMA100 (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step SMP: AP CPU #1 Launched! da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: 3814696MB (7812497408 512 byte sectors: 255H 63S/T 486305C) Trying to mount root from ufs:/dev/ad0s1a WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6 Any hints ? From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 03:49:01 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EE8016A46C for ; Sat, 22 Sep 2007 03:49:01 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id 0341E13C459 for ; Sat, 22 Sep 2007 03:49:00 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.201] (canonware.com [64.183.146.166]) by canonware.com (Postfix) with ESMTP id 612731298C8; Fri, 21 Sep 2007 20:55:53 -0700 (PDT) Message-ID: <46F490A8.2010004@freebsd.org> Date: Fri, 21 Sep 2007 20:48:56 -0700 From: Jason Evans User-Agent: Thunderbird 1.5.0.12 (X11/20070718) MIME-Version: 1.0 To: Alexandre Biancalana References: <8e10486b0709211457v7771bd66kf3df5ea45ab0d325@mail.gmail.com> <46F45CE2.9080204@freebsd.org> <8e10486b0709211855pbc3b983tf3452890f8d9b9dc@mail.gmail.com> In-Reply-To: <8e10486b0709211855pbc3b983tf3452890f8d9b9dc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: process size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 03:49:01 -0000 Alexandre Biancalana wrote: >> You're running your system as i386 rather than amd64, right? It looks >> like rsync is exhausting its address space while trying to reallocate >> the growing (and apparently very large) file list. There's nothing >> surprising here to me. If you use amd64 rather than i386 you won't have >> this problem, though you will still see poor performance due to >> swapping. The most prudent solution is probably to use multiple rsync >> calls to copy portions of your data at a time. > > I agree that this could be the problem... but I´m not running i386. > > # uname -a > FreeBSD 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Fri Sep 21 18:06:33 BRT > 2007 root@:/usr/obj/usr/src/sys/BACKUP amd64 Hmm, okay, so much for that theory. I blame rsync. If you look it its util.c, you will see that it can't allocate over 2^31 bytes per allocation (MALLOC_MAX). Additionally, the code uses (unsigned int) in many places that would have to be changed to (unsigned long) or (size_t) in order for things to work correctly with a larger MALLOC_MAX. Basically, rsync loses. Jason From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 04:01:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BF6E16A417 for ; Sat, 22 Sep 2007 04:01:08 +0000 (UTC) (envelope-from w0lfie@clear.net.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id D867E13C457 for ; Sat, 22 Sep 2007 04:01:07 +0000 (UTC) (envelope-from w0lfie@clear.net.nz) Received: from clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp4.clear.net.nz (CLEAR Net Mail) with SMTP id <0JOR00KBG4HUIJ20@smtp4.clear.net.nz> for freebsd-current@freebsd.org; Sat, 22 Sep 2007 16:01:06 +1200 (NZST) Date: Sat, 22 Sep 2007 16:01:06 +1200 From: Sam Banks Sender: w0lfie@clear.net.nz To: freebsd-current@freebsd.org Message-id: <46f49382.166.de5.21408@clear.net.nz> MIME-version: 1.0 X-Mailer: CLEAR Net WebMail; webmail.clear.net.nz; user: w0lfie; ip: 121.73.22.121 Content-type: multipart/mixed; boundary="-=_fep1746f49382" Priority: normal Subject: Re: USB keyboard status indicators not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: w0lfie@clear.net.nz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 04:01:08 -0000 This is a multi-part message in MIME format. ---=_fep1746f49382 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit It appears, in my case at least, that the TD to change the LED state on the physical keyboard is stalling. I have attached the output of this with hw.usb.uhci.debug up high. Does anyone have any tips or documentation on debugging stalls? Cheers, Sam. ----- Original Message Follows ----- > Sam Banks wrote: > > Out of interest, what USB host controller are each of > > you running? UHCI or OHCI? > > > > Sam. > > > > I tried connecting the same keyboard to my Dell Inspiron > 1501 laptop, with similar results. Interestingly the > built-in keyboard indicator lights on the laptop changed > and worked as expected when I pressed the keys on the USB > keyboard, but the ones on the USB keyboard didn't - the > caps lock button came on once and then none of the lights > changed after that. > > usb0: OHCI version 1.0, legacy support > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: 1> on usb0 usb5: companion controllers, 2 ports each: usb0 > usb1 usb2 usb3 usb4 > > uhub0: 2 ports with 2 removable, self powered > ukbd0: addr 2> on uhub0 kbd2 at ukbd0 > > -- > Bruce Cran ---=_fep1746f49382 Content-Type: text/plain; name="capslock.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="capslock.txt" U2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6IHVoY2lfZGV2aWNlX2Nv bnRyb2wgdHlwZT0weDIxLCByZXF1ZXN0PTB4MDksIHdWYWx1ZT0weDAyMDAs IHdJbmRleD0weDAwMDAgbGVuPTEsIGFkZHI9MywgZW5kcHQ9MApTZXAgMjAg MDk6NTA6MDkgd29sZmllIGtlcm5lbDogdWhjaV9hbGxvY19zdGRfY2hhaW46 IGFkZHI9MyBlbmRwdD0wIGxlbj0xIHNwZWVkPTIgZmxhZ3M9MHgwClNlcCAy MCAwOTo1MDowOSB3b2xmaWUga2VybmVsOiB1aGNpX2FsbG9jX3N0ZF9jaGFp bjogbWF4cD04IG50ZD0xClNlcCAyMCAwOTo1MDowOSB3b2xmaWUga2VybmVs OiB1aGNpX2FsbG9jX3N0ZF9jaGFpbjogbmV4dHRvZz0wClNlcCAyMCAwOTo1 MDowOSB3b2xmaWUga2VybmVsOiB1aGNpX2RldmljZV9yZXF1ZXN0OiBiZWZv cmUgdHJhbnNmZXIKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6IFRE KDB4YzRkZjM1MTApIGF0IDAxMWQ4NTEwID0gbGluaz0weDAxMWQ4NGI0IHN0 YXR1cz0weDE4ODAwMDAwIHRva2VuPTB4MDBlMDAzMmQgYnVmZmVyPTB4MDEy OThlODAKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6IDExZDg0YjQ8 VkY+IDE4ODAwMDAwPEFDVElWRT4sZXJyY250PTMsYWN0bGVuPTEgcGlkPTJk LGFkZHI9MyxlbmRwdD0wLEQ9MCxtYXhsZW49OApTZXAgMjAgMDk6NTA6MDkg d29sZmllIGtlcm5lbDogVEQoMHhjNGRmMzRiMCkgYXQgMDExZDg0YjAgPSBs aW5rPTB4MDExZDg1NDQgc3RhdHVzPTB4MTg4MDAzZmYgdG9rZW49MHgwMDA4 MDNlMSBidWZmZXI9MHgwMjA5NWIwNwpTZXAgMjAgMDk6NTA6MDkgd29sZmll IGtlcm5lbDogMTFkODU0NDxWRj4gMTg4MDAzZmY8QUNUSVZFPixlcnJjbnQ9 MyxhY3RsZW49MCBwaWQ9ZTEsYWRkcj0zLGVuZHB0PTAsRD0xLG1heGxlbj0x ClNlcCAyMCAwOTo1MDowOSB3b2xmaWUga2VybmVsOiBURCgweGM0ZGYzNTQw KSBhdCAwMTFkODU0MCA9IGxpbms9MHgwMDAwMDAwMSBzdGF0dXM9MHgxOTgw MDAwMCB0b2tlbj0weGZmZTgwMzY5IGJ1ZmZlcj0weDAwMDAwMDAwClNlcCAy MCAwOTo1MDowOSB3b2xmaWUga2VybmVsOiAxPFQ+IDE5ODAwMDAwPEFDVElW RSxJT0M+LGVycmNudD0zLGFjdGxlbj0xIHBpZD02OSxhZGRyPTMsZW5kcHQ9 MCxEPTEsbWF4bGVuPTAKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6 IHVoY2lfYWRkX2N0cmw6IHNxaD0weGM0ZGYyZWEwClNlcCAyMCAwOTo1MDow OSB3b2xmaWUga2VybmVsOiB1aGNpX2VudGVyX2N0bF9xOiBmb2xsb3cgZnJv bSBbMF0KU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6IFREKDB4YzRk YThmOTApIGF0IDAxMThjZjkwID0gbGluaz0weDAxMWQ5ZjYyIHN0YXR1cz0w eDAyMDAwMDAwIHRva2VuPTB4MDAwMDAwMDAgYnVmZmVyPTB4MDAwMDAwMDAK U2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6IDExZDlmNjI8UT4gMjAw MDAwMDxJU08+LGVycmNudD0wLGFjdGxlbj0xIHBpZD0wMCxhZGRyPTAsZW5k cHQ9MCxEPTAsbWF4bGVuPTEKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJu ZWw6IFFIKDB4YzRkZjRmNjApIGF0IDAxMWQ5ZjYwOiBobGluaz0wMTFkN2Yw MiBlbGluaz0wMDAwMDAwMQpTZXAgMjAgMDk6NTA6MDkgd29sZmllIGtlcm5l bDogUUgoMHhjNGRmNGY2MCkgYXQgMDExZDlmNjA6IGhsaW5rPTAxMWQ3ZjAy IGVsaW5rPTAwMDAwMDAxClNlcCAyMCAwOTo1MDowOSB3b2xmaWUga2VybmVs OiBRSCgweGM0ZGYyZjAwKSBhdCAwMTFkN2YwMDogaGxpbms9MDExZDlmODIg ZWxpbms9MDExZDg2MDAKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6 IFFIKDB4YzRkZjRmODApIGF0IDAxMWQ5ZjgwOiBobGluaz0wMTFkOWZhMiBl bGluaz0wMDAwMDAwMQpTZXAgMjAgMDk6NTA6MDkgd29sZmllIGtlcm5lbDog UUgoMHhjNGRmNGZhMCkgYXQgMDExZDlmYTA6IGhsaW5rPTAxMWQ3ZWEyIGVs aW5rPTAwMDAwMDAxClNlcCAyMCAwOTo1MDowOSB3b2xmaWUga2VybmVsOiBR SCgweGM0ZGYyZWEwKSBhdCAwMTFkN2VhMDogaGxpbms9MDExZDlmYzIgZWxp bms9MDExZDg1MTAKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6IFFI KDB4YzRkZjRmYzApIGF0IDAxMWQ5ZmMwOiBobGluaz0wMTFkOWZlMiBlbGlu az0wMDAwMDAwMQpTZXAgMjAgMDk6NTA6MDkgd29sZmllIGtlcm5lbDogRW5x dWV1ZWQgUUg6ClNlcCAyMCAwOTo1MDowOSB3b2xmaWUga2VybmVsOiBRSCgw eGM0ZGYyZWEwKSBhdCAwMTFkN2VhMDogaGxpbms9MDExZDlmYzIgZWxpbms9 MDExZDg1MTAKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6IFREKDB4 YzRkZjM1MTApIGF0IDAxMWQ4NTEwID0gbGluaz0weDAxMWQ4NGI0IHN0YXR1 cz0weDE4ODAwMDAwIHRva2VuPTB4MDBlMDAzMmQgYnVmZmVyPTB4MDEyOThl ODAKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6IDExZDg0YjQ8VkY+ IDE4ODAwMDAwPEFDVElWRT4sZXJyY250PTMsYWN0bGVuPTEgcGlkPTJkLGFk ZHI9MyxlbmRwdD0wLEQ9MCxtYXhsZW49OApTZXAgMjAgMDk6NTA6MDkgd29s ZmllIGtlcm5lbDogVEQoMHhjNGRmMzRiMCkgYXQgMDExZDg0YjAgPSBsaW5r PTB4MDExZDg1NDQgc3RhdHVzPTB4MTg4MDAzZmYgdG9rZW49MHgwMDA4MDNl MSBidWZmZXI9MHgwMjA5NWIwNwpTZXAgMjAgMDk6NTA6MDkgd29sZmllIGtl cm5lbDogMTFkODU0NDxWRj4gMTg4MDAzZmY8QUNUSVZFPixlcnJjbnQ9Myxh Y3RsZW49MCBwaWQ9ZTEsYWRkcj0zLGVuZHB0PTAsRD0xLG1heGxlbj0xClNl cCAyMCAwOTo1MDowOSB3b2xmaWUga2VybmVsOiBURCgweGM0ZGYzNTQwKSBh dCAwMTFkODU0MCA9IGxpbms9MHgwMDAwMDAwMSBzdGF0dXM9MHgxOTgwMDAw MCB0b2tlbj0weGZmZTgwMzY5IGJ1ZmZlcj0weDAwMDAwMDAwClNlcCAyMCAw OTo1MDowOSB3b2xmaWUga2VybmVsOiAxPFQ+IDE5ODAwMDAwPEFDVElWRSxJ T0M+LGVycmNudD0zLGFjdGxlbj0xIHBpZD02OSxhZGRyPTMsZW5kcHQ9MCxE PTEsbWF4bGVuPTAKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6IHVo Y2lfaW50cjogcmVhbCBpbnRlcnJ1cHQKU2VwIDIwIDA5OjUwOjA5IHdvbGZp ZSBrZXJuZWw6IHVzYjA6IHVoY2lfaW50cjEKU2VwIDIwIDA5OjUwOjA5IHdv bGZpZSBrZXJuZWw6IHVzYjAgcmVnczogY21kPTAwODEsIHN0cz0wMDAyLCBp bnRyPTAwMGYsIGZybnVtPTA1ZTIsIGZsYmFzZT0wMTFjZTc4OCwgc29mPTAw NDAsIHBvcnRzYzE9MDA5NSwgcG9ydHNjMj0wMDgwClNlcCAyMCAwOTo1MDow OSB3b2xmaWUga2VybmVsOiB1c2IwOiB1aGNpX3NvZnRpbnRyICgwKQpTZXAg MjAgMDk6NTA6MDkgd29sZmllIGtlcm5lbDogdWhjaV9jaGVja19pbnRyOiBp aT0weGM1MDE5ZDc4ClNlcCAyMCAwOTo1MDowOSB3b2xmaWUga2VybmVsOiB1 aGNpX2NoZWNrX2ludHI6IGFjdGl2ZSBpaT0weGM1MDE5ZDc4ClNlcCAyMCAw OTo1MDowOSB3b2xmaWUga2VybmVsOiB1aGNpX2NoZWNrX2ludHI6IGlpPTB4 YzUwMTlkNzggZG9uZQpTZXAgMjAgMDk6NTA6MDkgd29sZmllIGtlcm5lbDog dWhjaV9pZG9uZTogaWk9MHhjNTAxOWQ3OApTZXAgMjAgMDk6NTA6MDkgd29s ZmllIGtlcm5lbDogdWhjaV9pZG9uZTogaWk9MHhjNTAxOWQ3OCwgeGZlcj0w eGM1MDE5YzAwLCBwaXBlPTB4YzRlN2UyMDAgcmVhZHkKU2VwIDIwIDA5OjUw OjA5IHdvbGZpZSBrZXJuZWw6IFREKDB4YzRkZjM1MTApIGF0IDAxMWQ4NTEw ID0gbGluaz0weDAxMWQ4NGI0IHN0YXR1cz0weDE4MDAwMDA3IHRva2VuPTB4 MDBlMDAzMmQgYnVmZmVyPTB4MDEyOThlODAKU2VwIDIwIDA5OjUwOjA5IHdv bGZpZSBrZXJuZWw6IDExZDg0YjQ8VkY+IDE4MDAwMDA3LGVycmNudD0zLGFj dGxlbj04IHBpZD0yZCxhZGRyPTMsZW5kcHQ9MCxEPTAsbWF4bGVuPTgKU2Vw IDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6IFREKDB4YzRkZjM0YjApIGF0 IDAxMWQ4NGIwID0gbGluaz0weDAxMWQ4NTQ0IHN0YXR1cz0weDE4NDAwMDAw IHRva2VuPTB4MDAwODAzZTEgYnVmZmVyPTB4MDIwOTViMDcKU2VwIDIwIDA5 OjUwOjA5IHdvbGZpZSBrZXJuZWw6IDExZDg1NDQ8VkY+IDE4NDAwMDAwPFNU QUxMRUQ+LGVycmNudD0zLGFjdGxlbj0xIHBpZD1lMSxhZGRyPTMsZW5kcHQ9 MCxEPTEsbWF4bGVuPTEKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6 IFREKDB4YzRkZjM1NDApIGF0IDAxMWQ4NTQwID0gbGluaz0weDAwMDAwMDAx IHN0YXR1cz0weDE5ODAwMDAwIHRva2VuPTB4ZmZlODAzNjkgYnVmZmVyPTB4 MDAwMDAwMDAKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6IDE8VD4g MTk4MDAwMDA8QUNUSVZFLElPQz4sZXJyY250PTMsYWN0bGVuPTEgcGlkPTY5 LGFkZHI9MyxlbmRwdD0wLEQ9MSxtYXhsZW49MApTZXAgMjAgMDk6NTA6MDkg d29sZmllIGtlcm5lbDogdWhjaV9pZG9uZTogYWN0bGVuPTEsIHN0YXR1cz0w eDQwMDAwMApTZXAgMjAgMDk6NTA6MDkgd29sZmllIGtlcm5lbDogdWhjaV9p ZG9uZTogZXJyb3IsIGFkZHI9MywgZW5kcHQ9MHgwMCwgc3RhdHVzIDB4NDAw MDAwPFNUQUxMRUQ+ClNlcCAyMCAwOTo1MDowOSB3b2xmaWUga2VybmVsOiB1 aGNpX3JlbW92ZV9oc19jdHJsOiBzcWg9MHhjNGRmMmVhMApTZXAgMjAgMDk6 NTA6MDkgd29sZmllIGtlcm5lbDogdWhjaV9maW5kX3ByZXZfcWg6IHBxaD0w eGM0ZGY0ZmEwIHNxaD0weGM0ZGYyZWEwClNlcCAyMCAwOTo1MDowOSB3b2xm aWUga2VybmVsOiB1aGNpX2RldmljZV9jdHJsX2RvbmU6IGxlbmd0aD0xClNl cCAyMCAwOTo1MDowOSB3b2xmaWUga2VybmVsOiB1aGNpX2lkb25lOiBpaT0w eGM1MDE5ZDc4IGRvbmUKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6 IHVoY2lfY2hlY2tfaW50cjogaWk9MHhjNGUxZjE3OApTZXAgMjAgMDk6NTA6 MDkgd29sZmllIGtlcm5lbDogdWhjaV9jaGVja19pbnRyOiBhY3RpdmUgaWk9 MHhjNGUxZjE3OApTZXAgMjAgMDk6NTA6MDkgd29sZmllIGtlcm5lbDogdWhj aV9jaGVja19pbnRyOiBpaT0weGM0ZTFmMTc4IHN0ZD0weGM0ZGYzNDgwIHN0 aWxsIGFjdGl2ZQpTZXAgMjAgMDk6NTA6MDkgd29sZmllIGtlcm5lbDogdWhj aV9jaGVja19pbnRyOiBpaT0weGM0ZGM0Nzc4ClNlcCAyMCAwOTo1MDowOSB3 b2xmaWUga2VybmVsOiB1aGNpX2NoZWNrX2ludHI6IGFjdGl2ZSBpaT0weGM0 ZGM0Nzc4ClNlcCAyMCAwOTo1MDowOSB3b2xmaWUga2VybmVsOiB1aGNpX2No ZWNrX2ludHI6IGlpPTB4YzRkYzQ3Nzggc3RkPTB4YzRkZjM2MDAgc3RpbGwg YWN0aXZlClNlcCAyMCAwOTo1MDowOSB3b2xmaWUga2VybmVsOiB1c2IwOiB1 aGNpX2ludHI6IGV4aXQKU2VwIDIwIDA5OjUwOjA5IHdvbGZpZSBrZXJuZWw6 IHVoY2lfaW50cjogcmVhbCBpbnRlcnJ1cHQKU2VwIDIwIDA5OjUwOjA5IHdv bGZpZSBrZXJuZWw6IHVzYjM6IHVoY2lfaW50cjEKU2VwIDIwIDA5OjUwOjA5 IHdvbGZpZSBrZXJuZWw6IHVzYjMgcmVnczogY21kPTAwODEsIHN0cz0wMDAw LCBpbnRyPTAwMGYsIGZybnVtPTA3NGQsIGZsYmFzZT0wMTIyZmQzNCwgc29m PTAwNDAsIHBvcnRzYzE9MDA4MCwgcG9ydHNjMj0wMDgwClNlcCAyMCAwOTo1 MDowOSB3b2xmaWUga2VybmVsOiB1aGNpX3BvbGxfaHViCg== ---=_fep1746f49382-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 04:22:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3B2E16A46B; Sat, 22 Sep 2007 04:22:54 +0000 (UTC) (envelope-from mnag@FreeBSD.org) Received: from corp.grupos.com.br (corp.grupos.com.br [200.193.29.43]) by mx1.freebsd.org (Postfix) with ESMTP id 91FA013C49D; Sat, 22 Sep 2007 04:22:54 +0000 (UTC) (envelope-from mnag@FreeBSD.org) Received: from [192.168.20.100] (cm-net-poa-C8B0C830.dynamic.brdterra.com.br [200.176.200.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcus@corp.grupos.com.br) by corp.grupos.com.br (Postfix) with ESMTP id 7BA625CE7; Sat, 22 Sep 2007 01:03:11 -0300 (BRT) Message-ID: <46F493FB.6020603@FreeBSD.org> Date: Sat, 22 Sep 2007 01:03:07 -0300 From: Marcus Alves Grand User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org, andre@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: sendfile() without struct sf_hdtr broken since rev 1.256 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 04:22:54 -0000 People, Since rev 1.256 sendfile broken lighttpd sendfile() that doesn´t use struct sf_hdtr. Sometimes sendfile works sometimes not like you can see below: ------- # wget -O /dev/null http://another.host/30M --00:58:22-- http://another.host/30M => `/dev/null' Resolving another.host... X.X.X.X Connecting to another.host|X.X.X.X|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 31,457,280 (30M) [text/plain] 100%[====================================================================================================>] 31,457,280 10.60M/s 00:58:25 (10.59 MB/s) - `/dev/null' saved [31457280/31457280] # wget -O /dev/null http://another.host/30M --00:58:26-- http://another.host/30M => `/dev/null' Resolving another.host... X.X.X.X Connecting to another.host|X.X.X.X|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 31,457,280 (30M) [text/plain] 1% [> ] 409,600 --.--K/s 00:58:26 (5.51 MB/s) - Connection closed at byte 409600. Retrying. --00:58:27-- http://another.host/30M (try: 2) => `/dev/null' Connecting to another.host|X.X.X.X|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 31,457,280 (30M), 31,047,680 (30M) remaining [text/plain] 2% [+> ] 774,144 --.--K/s 00:58:27 (4.27 MB/s) - Connection closed at byte 774144. Retrying. ------ rev 1.256: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_syscalls.c.diff?r1=1.255;r2=1.256 Regards From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 04:24:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78CA716A419 for ; Sat, 22 Sep 2007 04:24:34 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from mail.btshosting.co.uk (mail.btshosting.co.uk [213.228.232.37]) by mx1.freebsd.org (Postfix) with ESMTP id 80DB613C455 for ; Sat, 22 Sep 2007 04:24:33 +0000 (UTC) (envelope-from bazerka@beardz.net) Received: from [192.168.0.3] (host86-152-238-75.range86-152.btcentralplus.com [86.152.238.75]) (authenticated bits=0) by mail.btshosting.co.uk (8.13.8/8.13.8) with ESMTP id l8M3Y9YI015003 for ; Sat, 22 Sep 2007 04:34:15 +0100 Message-ID: <46F48D35.4060108@beardz.net> Date: Sat, 22 Sep 2007 04:34:13 +0100 From: Jase Thew User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------020508030204040905010203" X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on mail.btshosting.co.uk X-Virus-Status: Clean Subject: USB mouse problem (attaches to uhid(4) instead of ums(4) in -CURRENT, works correctly in RELENG_6 however). X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bazerka@beardz.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 04:24:34 -0000 This is a multi-part message in MIME format. --------------020508030204040905010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I've installed -CURRENT amd64 yesterday to see how well it plays with my desktop hardware and to get some testing done in the run up to 7.0-REL. The install has been csup'd and rebuilt using the latest sources from HEAD yesterday. The kernel is pretty much GENERIC with the exception of ULE replacing 4BSD, and the debugging options (WITNESS/INVARIANTS/etc) removed. Unfortunately, it seems as though my mouse fails to attach to ums(4) and attaches to uhid(4) instead (this happens with both my custom ULE kernel and a stock GENERIC kernel). The programmable mouse buttons which have been configured to emulate keypresses, work fine via the attachment to ukbd(4) however. The mouse in question is a Razor Copperhead running the latest firmware (v6.20) and attaches successfully to ums(4) on my 6.2-STABLE amd64 install. I've included a full verbose boot log and also the output of usbdevs -dv as attachments. Any help with getting this mouse working would be appreciated, I don't fancy having to buy another mouse just for 7.0-REL ;) Thanks in advance, Jase Thew. --------------020508030204040905010203 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #0: Fri Sep 21 20:07:20 BST 2007 root@sheesh7.localdomain:/usr/obj/usr/src/sys/SHEESH7 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80b42000. Calibrating clock(s) ... i8254 clock: 1193213 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2133342232 Hz CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2133.34-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 3141451776 (2995 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000c3f000 - 0x00000000b671afff, 3048062976 bytes (744156 pages) avail memory = 3037179904 (2896 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ACPI: RSDP @ 0x0xfae70/0x0014 (v 0 ACPIAM) ACPI: RSDT @ 0x0xbbf90000/0x0038 (v 1 MSTEST TESTONLY 0x08000714 MSFT 0x00000097) ACPI: FACP @ 0x0xbbf90200/0x0084 (v 2 MSTEST OEMFACP 0x08000714 MSFT 0x00000097) ACPI: DSDT @ 0x0xbbf905c0/0x8E7D (v 1 A0483 A0483035 0x00000035 INTL 0x20060113) ACPI: FACS @ 0x0xbbf9e000/0x0040 ACPI: APIC @ 0x0xbbf90390/0x006C (v 1 MSTEST OEMAPIC 0x08000714 MSFT 0x00000097) ACPI: MCFG @ 0x0xbbf90400/0x003C (v 1 MSTEST OEMMCFG 0x08000714 MSFT 0x00000097) ACPI: OEMB @ 0x0xbbf9e040/0x007B (v 1 MSTEST AMI_OEM 0x08000714 MSFT 0x00000097) ACPI: HPET @ 0x0xbbf99440/0x0038 (v 1 MSTEST OEMHPET 0x08000714 MSFT 0x00000097) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 wlan_amrr: null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Sep 21 2007 20:07:13) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 1 hz: 14318180 opts: leg_route count_size Timecounter "HPET" frequency 14318180 Hz quality 900 acpi0: Power Button (fixed) pci_open(1): mode 1 addr port (0x0cf8) is 0x80010064 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=29a08086) AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bbf00000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 14 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 cpu0: on acpi0 cpu0: switching to generic Cx mode est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 828082806000828 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 828082806000828 device_attach: est1 attach returned 6 p4tcc1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x29a0, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x29a1, revid=0x02 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x283f, revid=0x02 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0106, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2847, revid=0x02 bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2849, revid=0x02 bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2830, revid=0x02 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0xd800, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2831, revid=0x02 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=15 map[20]: type I/O Port, range 32, base 0xd880, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2832, revid=0x02 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=3 map[20]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2833, revid=0x02 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type I/O Port, range 32, base 0xe000, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2836, revid=0x02 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfebffc00, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xf2 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2810, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2820, revid=0x02 bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=15 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xec00, size 3, enabled map[14]: type I/O Port, range 32, base 0xe880, size 2, enabled map[18]: type I/O Port, range 32, base 0xe800, size 3, enabled map[1c]: type I/O Port, range 32, base 0xe480, size 2, enabled map[20]: type I/O Port, range 32, base 0xe400, size 4, enabled map[24]: type I/O Port, range 32, base 0xe080, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x283e, revid=0x02 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[10]: type Memory, range 32, base 0, size 8, memory disabled map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2825, revid=0x02 bus=0, slot=31, func=5 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=15 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xd480, size 3, enabled map[14]: type I/O Port, range 32, base 0xd400, size 2, enabled map[18]: type I/O Port, range 32, base 0xd080, size 3, enabled map[1c]: type I/O Port, range 32, base 0xd000, size 2, enabled map[20]: type I/O Port, range 32, base 0xcc00, size 4, enabled map[24]: type I/O Port, range 32, base 0xc880, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: irq 16 at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x8000-0x8fff pcib1: memory decode 0xfa700000-0xfe7fffff pcib1: prefetched decode 0xbfe00000-0xdfdfffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x10de, dev=0x0292, revid=0xa1 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfd000000, size 24, enabled pcib1: requested memory range 0xfd000000-0xfdffffff: good map[14]: type Prefetchable Memory, range 64, base 0xc0000000, size 28, enabled pcib1: requested memory range 0xc0000000-0xcfffffff: good map[1c]: type Memory, range 64, base 0xfc000000, size 24, enabled pcib1: requested memory range 0xfc000000-0xfcffffff: good map[24]: type I/O Port, range 32, base 0x8c00, size 7, enabled pcib1: requested I/O range 0x8c00-0x8c7f: in range pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 vgapci0: port 0x8c00-0x8c7f mem 0xfd000000-0xfdffffff,0xc0000000-0xcfffffff,0xfc000000-0xfcffffff irq 16 at device 0.0 on pci1 pcib2: irq 16 at device 28.0 on pci0 pcib2: secondary bus 4 pcib2: subordinate bus 4 pcib2: I/O decode 0x0-0x0 pcib2: prefetched decode 0xdfe00000-0xdfefffff pci4: on pcib2 pci4: physical bus=4 pcib3: irq 16 at device 28.4 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xa000-0xafff pcib3: memory decode 0xfe900000-0xfe9fffff pcib3: no prefetched decode pci3: on pcib3 pci3: physical bus=3 found-> vendor=0x197b, dev=0x2363, revid=0x02 bus=3, slot=0, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xac00, size 3, enabled pcib3: requested I/O range 0xac00-0xac07: in range map[14]: type I/O Port, range 32, base 0xa880, size 2, enabled pcib3: requested I/O range 0xa880-0xa883: in range map[18]: type I/O Port, range 32, base 0xa800, size 3, enabled pcib3: requested I/O range 0xa800-0xa807: in range map[1c]: type I/O Port, range 32, base 0xa480, size 2, enabled pcib3: requested I/O range 0xa480-0xa483: in range map[20]: type I/O Port, range 32, base 0xa400, size 4, enabled pcib3: requested I/O range 0xa400-0xa40f: in range map[24]: type Memory, range 32, base 0xfe9fe000, size 13, enabled pcib3: requested memory range 0xfe9fe000-0xfe9fffff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 atapci0: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f mem 0xfe9fe000-0xfe9fffff irq 16 at device 0.0 on pci3 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xa400 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xfe9fe000 atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: SATA connect status=00000000 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: SATA connect status=00000000 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xac00 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xa880 ata4: reset tp1 mask=03 ostat0=50 ostat1=50 ata4: stat0=0x50 err=0x01 lsb=0x14 msb=0xeb ata4: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata4: reset tp2 stat0=50 stat1=00 devices=0xc ata4: [MPSAFE] ata4: [ITHREAD] pcib4: irq 17 at device 28.5 on pci0 pcib4: secondary bus 2 pcib4: subordinate bus 2 pcib4: I/O decode 0x9000-0x9fff pcib4: memory decode 0xfe800000-0xfe8fffff pcib4: no prefetched decode pci2: on pcib4 pci2: physical bus=2 found-> vendor=0x11ab, dev=0x4364, revid=0x12 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe8fc000, size 14, enabled pcib4: requested memory range 0xfe8fc000-0xfe8fffff: good map[18]: type I/O Port, range 32, base 0x9800, size 8, enabled pcib4: requested I/O range 0x9800-0x98ff: in range pcib4: matched entry for 2.0.INTA pcib4: slot 0 INTA hardwired to IRQ 17 mskc0: port 0x9800-0x98ff mem 0xfe8fc000-0xfe8fffff irq 17 at device 0.0 on pci2 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfe8fc000 mskc0: MSI count : 1 mskc0: RAM buffer size : 128KB mskc0: Port 0 : Rx Queue 96KB(0x00000000:0x00017fff) mskc0: Port 0 : Tx Queue 32KB(0x00018000:0x0001ffff) msk0: on mskc0 msk0: bpf attached msk0: Ethernet address: 00:17:31:8c:ea:52 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto ioapic0: routing intpin 17 (PCI IRQ 17) to vector 50 mskc0: [MPSAFE] mskc0: [FILTER] uhci0: port 0xd800-0xd81f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd800 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 51 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd880-0xd89f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd880 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 52 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xdc00-0xdc1f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdc00 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 53 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xe000-0xe01f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe000 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfebffc00-0xfebfffff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfebffc00 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib5: at device 30.0 on pci0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xb000-0xbfff pcib5: memory decode 0xfea00000-0xfeafffff pcib5: no prefetched decode pcib5: Subtractively decoded bridge. pci5: on pcib5 pci5: physical bus=5 found-> vendor=0x168c, dev=0x0013, revid=0x01 bus=5, slot=1, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0016, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfeaf0000, size 16, enabled pcib5: requested memory range 0xfeaf0000-0xfeafffff: good pcib5: matched entry for 5.1.INTA pcib5: slot 1 INTA hardwired to IRQ 22 found-> vendor=0x1102, dev=0x0004, revid=0x04 bus=5, slot=2, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xb880, size 6, enabled pcib5: requested I/O range 0xb880-0xb8bf: in range pcib5: matched entry for 5.2.INTA pcib5: slot 2 INTA hardwired to IRQ 23 found-> vendor=0x1102, dev=0x7003, revid=0x04 bus=5, slot=2, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xbc00, size 3, enabled pcib5: requested I/O range 0xbc00-0xbc07: in range found-> vendor=0x1102, dev=0x4001, revid=0x04 bus=5, slot=2, func=2 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0016, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=b, irq=14 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfeaef800, size 11, enabled pcib5: requested memory range 0xfeaef800-0xfeaeffff: good map[14]: type Memory, range 32, base 0xfeae8000, size 14, enabled pcib5: requested memory range 0xfeae8000-0xfeaebfff: good pcib5: matched entry for 5.2.INTB pcib5: slot 2 INTB hardwired to IRQ 20 found-> vendor=0x11ab, dev=0x4320, revid=0x14 bus=5, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x17 (5750 ns), maxlat=0x1f (7750 ns) intpin=a, irq=15 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfeae4000, size 14, enabled pcib5: requested memory range 0xfeae4000-0xfeae7fff: good map[14]: type I/O Port, range 32, base 0xb400, size 8, enabled pcib5: requested I/O range 0xb400-0xb4ff: in range pcib5: matched entry for 5.4.INTA pcib5: slot 4 INTA hardwired to IRQ 19 ath0: mem 0xfeaf0000-0xfeafffff irq 22 at device 1.0 on pci5 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfeaf0000 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 54 ath0: [MPSAFE] ath0: [ITHREAD] ath0: hal channel 2412/a0 -> 1 ath0: hal channel 2412/c0 -> 1 ath0: hal channel 2417/a0 -> 2 ath0: hal channel 2417/c0 -> 2 ath0: hal channel 2422/a0 -> 3 ath0: hal channel 2422/c0 -> 3 ath0: hal channel 2427/a0 -> 4 ath0: hal channel 2427/c0 -> 4 ath0: hal channel 2432/a0 -> 5 ath0: hal channel 2432/c0 -> 5 ath0: hal channel 2437/a0 -> 6 ath0: hal channel 2437/c0 -> 6 ath0: hal channel 2437/d0 -> 6 ath0: hal channel 2442/a0 -> 7 ath0: hal channel 2442/c0 -> 7 ath0: hal channel 2447/a0 -> 8 ath0: hal channel 2447/c0 -> 8 ath0: hal channel 2452/a0 -> 9 ath0: hal channel 2452/c0 -> 9 ath0: hal channel 2457/a0 -> 10 ath0: hal channel 2457/c0 -> 10 ath0: hal channel 2462/a0 -> 11 ath0: hal channel 2462/c0 -> 11 ath0: using obsoleted if_watchdog interface ath0: bpf attached ath0: Ethernet address: 00:0f:b5:89:c4:9d ath0: bpf attached ath0: bpf attached ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: mac 7.9 phy 4.5 radio 5.6 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons pci5: at device 2.0 (no driver attached) pci5: at device 2.1 (no driver attached) fwohci0: vendor=1102, dev=4001 fwohci0: vendor=1102, dev=4001 fwohci0: <1394 Open Host Controller Interface> mem 0xfeaef800-0xfeaeffff,0xfeae8000-0xfeaebfff irq 20 at device 2.2 on pci5 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfeaef800 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 55 fwohci0: [MPSAFE] fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:02:3c:01:51:09:5b:1b fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x2368000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:02:3c:09:5b:1b fwe0: bpf attached fwe0: Ethernet address: 02:02:3c:09:5b:1b fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:02:3c:01:51:09:5b:1b @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode skc0: port 0xb400-0xb4ff mem 0xfeae4000-0xfeae7fff irq 19 at device 4.0 on pci5 skc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfeae4000 skc0: interrupt moderation is 100 us skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) skc0: chip ver = 0xb1 skc0: chip rev = 0x09 skc0: SK_EPROM0 = 0x10 skc0: SRAM size = 0x010000 sk0: on skc0 sk0: bpf attached sk0: Ethernet address: 00:17:31:8c:fa:5c miibus1: on sk0 e1000phy1: PHY 0 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto skc0: [MPSAFE] skc0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe40f,0xe080-0xe08f irq 19 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xe400 atapci1: [MPSAFE] atapci1: [ITHREAD] ata5: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xec00 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xe880 ata5: reset tp1 mask=03 ostat0=50 ostat1=00 ata5: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata5: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata5: reset tp2 stat0=50 stat1=00 devices=0x1 ata5: [MPSAFE] ata5: [ITHREAD] ata6: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xe480 ata6: reset tp1 mask=03 ostat0=50 ostat1=00 ata6: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata6: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata6: reset tp2 stat0=50 stat1=00 devices=0x1 ata6: [MPSAFE] ata6: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f,0xc880-0xc88f irq 19 at device 31.5 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xcc00 atapci2: [MPSAFE] atapci2: [ITHREAD] ata7: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0xd480 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xd400 ata7: reset tp1 mask=03 ostat0=50 ostat1=00 ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata7: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata7: reset tp2 stat0=50 stat1=00 devices=0x1 ata7: [MPSAFE] ata7: [ITHREAD] ata8: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0xd080 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xd000 ata8: reset tp1 mask=03 ostat0=7f ostat1=7f ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat0=0x7f err=0xff lsb=0xff msb=0xff ata8: stat1=0x7f err=0xff lsb=0xff msb=0xff ata8: reset tp2 stat0=ff stat1=ff devices=0x0 ata8: [MPSAFE] ata8: [ITHREAD] acpi_button0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 sio0: [FILTER] ahc_isa_probe 8: ioport 0x8c00 alloc failed ahc_isa_probe 10: ioport 0xac00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed ex_isa_identify() sio: sio0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcdfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0065 psm0: failed to reset the aux device. fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices uhid0: on uhub0 ukbd0: on uhub0 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 ukbd1: on uhub0 kbd3 at ukbd1 kbd3: ukbd1, generic (0), config:0x0, flags:0x3d0000 uhid1: on uhub0 ugen0: on uhub1 Device configuration finished. Reducing kern.maxvnodes 192241 -> 100000 procfs registered lapic: Divisor 2, Frequency 133333897 hz Timecounter "TSC" frequency 2133342232 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: nofirewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) controller detected. ata4-slave: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire acd0: DVDROM drive at ata4 as master acd0: read 687KB/s (2750KB/s), 512KB buffer, UDMA100 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: 120mm data disc acd1: DVDR drive at ata4 as slave acd1: read 6890KB/s (6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, UDMA66 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd1: Writes: CDR, CDRW, DVDR, test write, burnproof acd1: Audio: play, 256 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad10: 305245MB at ata5-master SATA150 ad10: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad10: Intel check1 failed ad10: Adaptec check1 failed ad10: LSI (v3) check1 failed ad10: LSI (v2) check1 failed ad10: FreeBSD check1 failed ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad12: 305245MB at ata6-master SATA150 ad12: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad12: Intel check1 failed ad12: Adaptec check1 failed ad12: LSI (v3) check1 failed ad12: LSI (v2) check1 failed ad12: FreeBSD check1 failed ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad14: 38146MB at ata7-master SATA150 ad14: 78125000 sectors [77504C/16H/63S] 16 sectors/interrupt 1 depth queue ad14: Intel check1 failed ad14: Adaptec check1 failed ad14: LSI (v3) check1 failed ad14: LSI (v2) check1 failed ad14: FreeBSD check1 failed GEOM_LABEL: Label for provider acd0 is iso9660/FINAL_SUB_BB_ADD. GEOM: new disk ad10 GEOM: new disk ad12 GEOM: new disk ad14 GEOM_LABEL: Label for provider ad10s1 is ntfs/System. GEOM_LABEL: Label for provider ad10s2 is ntfs/Games. GEOM_LABEL: Label for provider ad10s3 is ntfs/Dump. GEOM_LABEL: Label for provider ad12s1 is ntfs/Dump2. (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning PCI IRQ 16 to local APIC 1 ioapic0: Assigning PCI IRQ 17 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 20 to local APIC 1 ioapic0: Assigning PCI IRQ 22 to local APIC 0 ioapic0: Assigning PCI IRQ 23 to local APIC 1 Trying to mount root from ufs:/dev/ad14s1a start_init: trying /sbin/init ath0: link state changed to UP --------------020508030204040905010203 Content-Type: text/plain; name="usbdevs.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="usbdevs.txt" Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 uhub0 port 1 addr 2: full speed, power 100 mA, config 1, Razer Copperhead Laser Mouse(0x0101), Razer(0x1532), rev 21.00 uhid0 ukbd0 port 2 addr 3: low speed, power 100 mA, config 1, DELL USB Keyboard(0x2003), DELL(0x413c), rev 1.00 ukbd1 uhid1 Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 uhub1 port 1 addr 2: low speed, power 2 mA, config 1, USB Receiver(0x0004), X10 Wireless Technology Inc(0x0bc7), rev 1.00 ugen0 port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 uhub2 port 1 powered port 2 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 uhub3 port 1 powered port 2 powered Controller /dev/usb4: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x0000), rev 1.00 uhub4 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 powered --------------020508030204040905010203-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 05:08:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2970A16A469 for ; Sat, 22 Sep 2007 05:08:30 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id E47E113C457 for ; Sat, 22 Sep 2007 05:08:29 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so2012149pyb for ; Fri, 21 Sep 2007 22:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=IxVjeWU0T0K7j9mp7bE8R728N3l3YI9uBqS7JhFeXzI=; b=IJXpyvVhyj9MXgRdW6oBz5nnrkcHaV3hptYoF/JSVgnUr3kf4N6diHP/aZYOdF4aD6tJP2KMeHoS/xGbHkmq0HOJ/ft8v7IwsJvPc/8/Tnn81P+WpYtbbO5ssslETjYjnsVhun/+E6OO7lVsKBUgPQT2QFrlOttaQlTi1dtzGNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BMm2vOwXKtdnZh6tvvII35wh8j8DUSo8RfVX3SbgTnPJpxuYskIia1Hq4pWgtgQHxpwi6hCz05i+R2qnnk1g8nXMSllC/+zHdOizNG5UFkQoNuG/NPT1SUIDWf3hIF6YwFtGeD/n9XBHqfZIxkKn5P3fgFLymKjAu5jMOkpgBb0= Received: by 10.65.15.19 with SMTP id s19mr2244381qbi.1190437708080; Fri, 21 Sep 2007 22:08:28 -0700 (PDT) Received: by 10.64.196.4 with HTTP; Fri, 21 Sep 2007 22:08:28 -0700 (PDT) Message-ID: <6eb82e0709212208o6d52c1bdgc4999f7432d4d7d2@mail.gmail.com> Date: Sat, 22 Sep 2007 13:08:28 +0800 From: "Rong-en Fan" To: "Marcus Alves Grand" In-Reply-To: <46F493FB.6020603@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <46F493FB.6020603@FreeBSD.org> Cc: freebsd-current@freebsd.org, andre@freebsd.org Subject: Re: sendfile() without struct sf_hdtr broken since rev 1.256 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 05:08:30 -0000 T24gOS8yMi8wNywgTWFyY3VzIEFsdmVzIEdyYW5kIDxtbmFnQGZyZWVic2Qub3JnPiB3cm90ZToK PiBQZW9wbGUsCj4KPiBTaW5jZSByZXYgMS4yNTYgc2VuZGZpbGUgYnJva2VuIGxpZ2h0dHBkIHNl bmRmaWxlKCkgdGhhdCBkb2VzbsK0dCB1c2UKPiBzdHJ1Y3Qgc2ZfaGR0ci4KPgo+IFNvbWV0aW1l cyBzZW5kZmlsZSB3b3JrcyBzb21ldGltZXMgbm90IGxpa2UgeW91IGNhbiBzZWUgYmVsb3c6Cj4K Wy4uLl0KPgo+IHJldiAxLjI1NjoKPiBodHRwOi8vd3d3LmZyZWVic2Qub3JnL2NnaS9jdnN3ZWIu Y2dpL3NyYy9zeXMva2Vybi91aXBjX3N5c2NhbGxzLmMuZGlmZj9yMT0xLjI1NTtyMj0xLjI1NgoK VGhhbmsgeW91IGZvciBmaW5kaW5nIHRoaXMgb3V0LiBJIGVuY291bnRlcmVkIGV4YWN0bHkgdGhl IHNhbWUKcHJvYmxlbSBidXQgaGF2ZSBubyB0aW1lIHRvIGludmVzdGlnYXRlLgoKQlRXLCBpZiBJ IGRvd25ncmFkZSBsaWdodHRwZCB0byAxLjQuMTYgZnJvbSAxLjQuMTcvMS40LjE4LCB3aXRoCnJl diAxLjI1NiB1aXBjX3N5c2NhbGxzLmMgaXQgd29ya3MuCgpSZWdhcmRzLApSb25nLUVuIEZhbgoK Pgo+IFJlZ2FyZHMKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwo+IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKPiBodHRwOi8v bGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWN1cnJlbnQKPiBUbyB1 bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1jdXJyZW50LXVuc3Vic2NyaWJl QGZyZWVic2Qub3JnIgo+Cg== From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 09:50:03 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2241416A417 for ; Sat, 22 Sep 2007 09:50:03 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 91B7F13C474 for ; Sat, 22 Sep 2007 09:50:02 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l8M9a8qp042886; Sat, 22 Sep 2007 11:36:08 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l8M9ZxxJ089143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Sep 2007 11:35:59 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l8M9ZwXN035505; Sat, 22 Sep 2007 11:35:58 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l8M9ZwJx035504; Sat, 22 Sep 2007 11:35:58 +0200 (CEST) (envelope-from ticso) Date: Sat, 22 Sep 2007 11:35:58 +0200 From: Bernd Walter To: Luigi Rizzo Message-ID: <20070922093557.GC32918@cicely12.cicely.de> References: <20070921103829.A43801@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070921103829.A43801@xorpc.icir.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: current@freebsd.org Subject: Re: Why USB must be so hard to use ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 09:50:03 -0000 On Fri, Sep 21, 2007 at 10:38:29AM -0700, Luigi Rizzo wrote: > i recently tried to attach one of the Openbeacon USB devices > > http://wiki.openbeacon.org/wiki/OpenBeacon_USB > > to a -stable box, and "of course" attach failed, even though the > same thing is claimed to work right away on Linux and XP without > any special driver. > > It wasn't too hard to convince umodem.c to attach to the device, > but i had to put the ids in the list of devices > explicitly recognised, and further disable the extra check for > capabilities at the end of umodem.c::USB_MATCH (or umodem_match in > -current). The device itself returns a class UICLASS_CDC, but > subclass and protocol are 0, i.e. this is a very basic serial device > as probably many gadget we are going to see in the future. Since it's using an Atmel ARM. I had to create the following umodem patch to get a pseudo serial port for accessing the sam-ba CDC for flashing the controller: Index: umodem.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/umodem.c,v retrieving revision 1.57 diff -u -r1.57 umodem.c --- umodem.c 31 Jan 2005 13:58:10 -0000 1.57 +++ umodem.c 20 Aug 2006 17:05:34 -0000 @@ -256,6 +260,15 @@ id->bInterfaceProtocol == UIPROTO_CDC_AT) ret = UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; +#if 1 + if (ret == UMATCH_NONE && + id->bInterfaceClass == UICLASS_CDC_DATA && + id->bInterfaceSubClass == UISUBCLASS_DATA && + id->bInterfaceProtocol == 0x00) + ret = UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; + return ret; +#endif + if (ret == UMATCH_NONE) return (ret); I was told that it just works under Linux and Windows has such a generic driver as well. But the sam-ba firmware in the AT91SAM7X256 wasn't able to build a tty under Mac OS X as well. We should really have a generic CDC tty driver, since it is used very often for simple USB projects. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 13:07:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8873616A46B for ; Sat, 22 Sep 2007 13:07:58 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: from corpmail.itlegion.ru (corpmail.itlegion.ru [84.21.226.211]) by mx1.freebsd.org (Postfix) with SMTP id C1BC413C469 for ; Sat, 22 Sep 2007 13:07:57 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: (qmail 40498 invoked from network); 22 Sep 2007 17:07:55 +0400 Received: from unknown (HELO Artem) (192.168.0.12) by 84.21.226.211 with SMTP; 22 Sep 2007 17:07:55 +0400 X-AntiVirus: Checked by Dr.Web [version: 4.33, engine: 4.33.5.10110, virus records: 254117, updated: 22.09.2007] Message-ID: <00c901c7fd19$9696bf60$0c00a8c0@Artem> From: "Artem Kuchin" To: "Kris Kennaway" , "Jack Vogel" References: <01c801c7fc7a$696ab900$0c00a8c0@Artem> <2a41acea0709211359w37ba779dsec94de504a9f4a9c@mail.gmail.com> <46F456B6.5060509@FreeBSD.org> Date: Sat, 22 Sep 2007 17:07:51 +0400 Organization: IT Legion MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: freebsd-current@freebsd.org Subject: Re: TSP on em makes send of streams very slow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 13:07:58 -0000 Kris Kennaway wrote: > Jack Vogel wrote: >> On 9/21/07, Artem Kuchin wrote: >>> Hello! >>> >>> Here is what i have experienced today. >>> >>> I just installed 7.0-CURRENT (cvsed and build on 2007/09/20) >>> on a PRODUCTION web server >>> (because, IHMO, this current is stable enough and i like >>> too much :) >>> >>> This is intel MB with two built-in em intefaces. >>> >>> I sshed to the server. >>> While i was in plain shell everything was fine, but when i >>> stared midnight commander i saw how it very slowly draws >>> scren part by part. It took about 3 monutes to almost >>> completely draw a screen when i got disconnected. I tied again >>> - the same. Then i connected via ftp and uploaded 10MB file >>> at 900KB/sec. When i tried to download it back i got about >>> 500 *BYTES*/sec and the got disconnected in a couple of minutes. >>> >>> Ping was just find, even flood ping from the server on the save >>> switch with 15000 packets was fine (just one dot on the left). >>> >>> I went also crazy already when i desided to compare interface params >>> with another server with em NICs. >>> >>> The dfference is that this is has the following options (by DEFAULT, >>> i did not turn it on): >>> >>> VLAN_HWCSUM,TSO4 >>> >>> I've read about TSO on 'man ifconfig' and just for kicks decided >>> to turn it off. VOILA!!! In a seconds send speed was up to 10 >>> MBYTES/sec! >>> >>> I have googled about 'em tso slow ' etc.. and found a couple of >>> seemingly the same problem dated back 2006. Is it supposed to be >>> solved by now? What IS the problem with TSO? >> >> TSO is for some environments, it isn't gonna be useful at 100Mb >> (which you are), it can be useful at 1Gb but not always, when you >> get to 10G its >> a HUGE benefit. >> >> Just cuz you can shoot yourself in the foot doesn't mean the gun has >> a problem :) > > So the card can't handle it? Note that the OP says it was enabled > automatically. > > I wouldn't necessarily expect it to give a performance benefit, but it > shouldn't destroy performance to that extent either. There seems to > be a real problem to be addressed here. I have sent this message to freebsdnic@mailbox.intel.com I took this address from README for em device driver (/usr/src/sys/dev/em) But email returned from mailer-daemon because there is no such email address anymore. Who is responsible for this driver nowadays? -- Regards Artem From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 15:22:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2812516A419; Sat, 22 Sep 2007 15:22:59 +0000 (UTC) (envelope-from prvs=17853746c3=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7F7DA13C45A; Sat, 22 Sep 2007 15:22:58 +0000 (UTC) (envelope-from prvs=17853746c3=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1190473502; x=1191078302; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=ogZoC/quGckVcvb01pDh5 IfujfKEr45qs+dL5WT5ZAg=; b=oUBmahrqaEe7trcLtFvex7ggb8aDmPcJkhVLQ VTDpoepEXIyO+GkCDdEAn+o3USDzbdfZ760+XdJHSFap815RAux8a/lSkIF3gIpl pLLdEmCZpoVQ48El0/W+pr73nnOBNCOijYt1qdK2j97elfkYcpl0iNjg23O2LDIk zqHwKY= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.8 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v9.6.0) with ESMTP id md50004233816.msg; Sat, 22 Sep 2007 16:05:00 +0100 Message-ID: <011c01c7fd29$e9c8dcd0$b6db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Artem Kuchin" , "Kris Kennaway" , "Jack Vogel" References: <01c801c7fc7a$696ab900$0c00a8c0@Artem><2a41acea0709211359w37ba779dsec94de504a9f4a9c@mail.gmail.com><46F456B6.5060509@FreeBSD.org> <00c901c7fd19$9696bf60$0c00a8c0@Artem> Date: Sat, 22 Sep 2007 16:04:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 212.135.219.182 X-Return-Path: prvs=17853746c3=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-Spam-Processed: mail1.multiplay.co.uk, Sat, 22 Sep 2007 16:05:01 +0100 X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 22 Sep 2007 16:05:02 +0100 Cc: freebsd-current@freebsd.org Subject: Re: TSP on em makes send of streams very slow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 15:22:59 -0000 That's likely to be Jack. ----- Original Message ----- From: "Artem Kuchin" > I have sent this message to freebsdnic@mailbox.intel.com > I took this address from README for em device driver > (/usr/src/sys/dev/em) > But email returned from mailer-daemon because there is no such > email address anymore. > > Who is responsible for this driver nowadays? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 17:27:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0231916A41A for ; Sat, 22 Sep 2007 17:27:12 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: from corpmail.itlegion.ru (corpmail.itlegion.ru [84.21.226.211]) by mx1.freebsd.org (Postfix) with SMTP id 2EE5813C474 for ; Sat, 22 Sep 2007 17:27:10 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: (qmail 45883 invoked from network); 22 Sep 2007 21:27:09 +0400 Received: from unknown (HELO Artem) (192.168.0.12) by 84.21.226.211 with SMTP; 22 Sep 2007 21:27:09 +0400 X-AntiVirus: Checked by Dr.Web [version: 4.33, engine: 4.33.5.10110, virus records: 254163, updated: 22.09.2007] Message-ID: <019101c7fd3d$cd15f870$0c00a8c0@Artem> From: "Artem Kuchin" To: "Jack Vogel" References: <01c801c7fc7a$696ab900$0c00a8c0@Artem> <2a41acea0709211359w37ba779dsec94de504a9f4a9c@mail.gmail.com> Date: Sat, 22 Sep 2007 21:27:05 +0400 Organization: IT Legion MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: freebsd-current@freebsd.org Subject: Re: TSP on em makes send of streams very slow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 17:27:12 -0000 > TSO is for some environments, it isn't gonna be useful at 100Mb > (which you are), it can be useful at 1Gb but not always, when you get > to 10G its > a HUGE benefit. > > Just cuz you can shoot yourself in the foot doesn't mean the gun has a > problem :) But wait, i did not shoot myself. I have been shot by the driver w/o any preliminary warning. TSO4 was enabled by DEFAULT (i did not enable it), so anybody can be in my place if used the same driver on the similar hardware (which is plenty). So, i think this is a problem which really need to be addressed. -- Regards, Artem From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 21:21:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5208016A417 for ; Sat, 22 Sep 2007 21:21:21 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 35F1F13C457 for ; Sat, 22 Sep 2007 21:21:21 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 1D05B2E855; Sat, 22 Sep 2007 17:21:20 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 22 Sep 2007 17:21:20 -0400 X-Sasl-enc: v4u8gyflqHoqQUrW9WaG5JMW82iFtZvZLbTU3Hz7s4n9 1190496079 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id 885945150; Sat, 22 Sep 2007 17:21:19 -0400 (EDT) Message-ID: <46F58799.1030702@freebsd.org> Date: Sat, 22 Sep 2007 14:22:33 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Kris Kennaway References: <20070921102946.T11189@borg> <46F415BF.9010500@FreeBSD.org> <20070921140550.D96923@thebighonker.lerctr.org> <46F41CFF.6080108@FreeBSD.org> In-Reply-To: <46F41CFF.6080108@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Larry Rosenman Subject: Re: panic: kmem_malloc(131072): kmem_map too small (AMD64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 21:21:21 -0000 Kris Kennaway wrote: > Larry Rosenman wrote: >> On Fri, 21 Sep 2007, Kris Kennaway wrote: >> >>> Larry Rosenman wrote: >>>> I'm a heavy ZFS user, and got the following panic on 2007-09-18 >>>> source/world: >>> >>> This is a FAQ, please see the archives (you need to increase the >>> vm.kmem_size to provide more memory to ZFS). >> >> I thought that was only for i386, and it hadn't been an issue before. > > Nope. It is also load-dependent. So I just received this courtesy of ZFS: panic: kmem_malloc(131072): kmem_map too small: 343027712 total allocated cpuid = 0 KDB: enter: panic This was with these settings in loader.conf: vm.kmem_size=419430400 vm.kmem_size_max=419430400 vfs.zfs.arc_max=409715200 (That's 400M, 400M and 40M, respectively.) Stupid question, perhaps, but is vm.kmem_size/vm.kmem_size_max limited by physical RAM? Darren From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 21:37:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A8F716A418; Sat, 22 Sep 2007 21:37:41 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 8039913C45D; Sat, 22 Sep 2007 21:37:38 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F58B21.8030307@FreeBSD.org> Date: Sat, 22 Sep 2007 23:37:37 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Darren Reed References: <20070921102946.T11189@borg> <46F415BF.9010500@FreeBSD.org> <20070921140550.D96923@thebighonker.lerctr.org> <46F41CFF.6080108@FreeBSD.org> <46F58799.1030702@freebsd.org> In-Reply-To: <46F58799.1030702@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Larry Rosenman Subject: Re: panic: kmem_malloc(131072): kmem_map too small (AMD64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 21:37:41 -0000 Darren Reed wrote: > Kris Kennaway wrote: >> Larry Rosenman wrote: >>> On Fri, 21 Sep 2007, Kris Kennaway wrote: >>> >>>> Larry Rosenman wrote: >>>>> I'm a heavy ZFS user, and got the following panic on 2007-09-18 >>>>> source/world: >>>> >>>> This is a FAQ, please see the archives (you need to increase the >>>> vm.kmem_size to provide more memory to ZFS). >>> >>> I thought that was only for i386, and it hadn't been an issue before. >> >> Nope. It is also load-dependent. > > So I just received this courtesy of ZFS: > panic: kmem_malloc(131072): kmem_map too small: 343027712 total allocated > cpuid = 0 > KDB: enter: panic > > This was with these settings in loader.conf: > vm.kmem_size=419430400 > vm.kmem_size_max=419430400 > vfs.zfs.arc_max=409715200 > > (That's 400M, 400M and 40M, respectively.) > > Stupid question, perhaps, but is vm.kmem_size/vm.kmem_size_max limited > by physical RAM? Yes. Kris From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 23:32:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B3F6116A420; Sat, 22 Sep 2007 23:32:12 +0000 (UTC) (envelope-from mnag@FreeBSD.org) Message-ID: <46F5A5FF.8010906@FreeBSD.org> Date: Sat, 22 Sep 2007 20:32:15 -0300 From: Marcus Alves Grando Organization: FreeBSD.org User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Rong-en Fan References: <46F493FB.6020603@FreeBSD.org> <6eb82e0709212208o6d52c1bdgc4999f7432d4d7d2@mail.gmail.com> In-Reply-To: <6eb82e0709212208o6d52c1bdgc4999f7432d4d7d2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, andre@freebsd.org Subject: Re: sendfile() without struct sf_hdtr broken since rev 1.256 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 23:32:14 -0000 Rong-en Fan wrote: > On 9/22/07, Marcus Alves Grand wrote: >> People, >> >> Since rev 1.256 sendfile broken lighttpd sendfile() that doesn´t use >> struct sf_hdtr. >> >> Sometimes sendfile works sometimes not like you can see below: >> > [...] >> rev 1.256: >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_syscalls.c.diff?r1=1.255;r2=1.256 > > Thank you for finding this out. I encountered exactly the same > problem but have no time to investigate. > > BTW, if I downgrade lighttpd to 1.4.16 from 1.4.17/1.4.18, with > rev 1.256 uipc_syscalls.c it works. Ok. I commit one fix for lighttpd. But i still think there´s a problem in sendfile(). For example, if i revert rev 1.256 sendfile return "off_t *sbytes" > 0 otherwise sendfile() return 0 in sbytes many times. Someone know if this new behavior are correct? Regards > > Regards, > Rong-En Fan > >> Regards >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Marcus Alves Grando marcus(at)sbh.eng.br | Personal mnag(at)FreeBSD.org | FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 23:36:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDAF216A418 for ; Sat, 22 Sep 2007 23:36:46 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: from redundancy.redundancy.org (redundancy.redundancy.org [64.147.160.152]) by mx1.freebsd.org (Postfix) with SMTP id 941AB13C43E for ; Sat, 22 Sep 2007 23:36:46 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: (qmail 62954 invoked by uid 1001); 22 Sep 2007 23:37:09 -0000 Date: Sat, 22 Sep 2007 16:37:09 -0700 From: "David E. Thiel" To: freebsd-current@freebsd.org Message-ID: <20070922233709.GG59731@redundancy.redundancy.org> Mail-Followup-To: freebsd-current@freebsd.org References: <20070916061932.GA93480@underworld.novel.ru> <20070918061806.GA85425@blazingdot.com> <20070918004027.G558@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070918004027.G558@10.0.0.1> X-OpenPGP-Key-fingerprint: 482A 8C46 C844 7E7C 8CBC 2313 96EE BEE5 1F4B CA13 X-OpenPGP-Key-available: http://redundancy.redundancy.org/lx.gpg User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: SCHED_ULE on desktop system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 23:36:46 -0000 On Tue, Sep 18, 2007 at 12:44:52AM -0700, Jeff Roberson wrote: > What has happened is that you have run an x application that is so > expensive we no longer consider it interactive. Unfortunately, due to the > nature of the x server architecture, much of the compute time is spent in > x11 rather than the offending application. There really isn't anything to > be done in this case other than mark X as real-time. You can try to tune > up the interactivity heuristic limit by setting kern.sched.interact to a > higher value. This will help with short term bursts of x server cpu > utilization, however, sustained, expensive x windows processing will always > trigger poorer interactive behavior. FWIW, Sept 20th's current has gotten rid of the audio stuttering for me. Redraw and mouse movement still gets some slowdowns (even with X rtprio'd), but I think I'll wait for the new nvidia driver to come out before I can blame it on anything scheduler-related. So, something in the recent ULE commits has worked. Thanks! (for the record, I was never swapping) -David From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 23:47:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E712116A417 for ; Sat, 22 Sep 2007 23:47:38 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 747CF13C44B for ; Sat, 22 Sep 2007 23:47:38 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1450770mue for ; Sat, 22 Sep 2007 16:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=gj16fjx9jJADHCP1jASPT9fasMecKmBC4uCc6ytY4ss=; b=Hoc8SxVRxjUyFibV1KlWQFjyffWUFLvpGV8S2hx+eF4eXPOVyLdskf+1whOAQNRpImNAMH8FC3DrohPcBwsMLFgLH82ygKQgNOu4kehDYNynqVUHkbD8iG+0GKRz70ishQRDenAsQkF1WMDsRd0fc2Bp7wxSNlt1iXnDVaD7GYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TDV4eOClfJxM71VgaYS1j2Ja6crBYYOfOFWOeG66RChdNo4Xe41L88VAT3J8BKXgivFi1Sr9jvll3+EaxqCGe+u94vYkx6A5BZS8USlC/b2QZ/M4ajMq+WkaIGOliOQfc20qUFdwRyk98xBTv0c60KTiBmZyywiIzLRUlqRC73A= Received: by 10.86.84.5 with SMTP id h5mr3452614fgb.1190504856750; Sat, 22 Sep 2007 16:47:36 -0700 (PDT) Received: by 10.86.100.19 with HTTP; Sat, 22 Sep 2007 16:47:36 -0700 (PDT) Message-ID: <2a41acea0709221647o3cdcb72pf6194c54782c61fb@mail.gmail.com> Date: Sat, 22 Sep 2007 16:47:36 -0700 From: "Jack Vogel" To: "Artem Kuchin" In-Reply-To: <019101c7fd3d$cd15f870$0c00a8c0@Artem> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <01c801c7fc7a$696ab900$0c00a8c0@Artem> <2a41acea0709211359w37ba779dsec94de504a9f4a9c@mail.gmail.com> <019101c7fd3d$cd15f870$0c00a8c0@Artem> Cc: freebsd-current@freebsd.org Subject: Re: TSP on em makes send of streams very slow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 23:47:39 -0000 On 9/22/07, Artem Kuchin wrote: > > TSO is for some environments, it isn't gonna be useful at 100Mb > > (which you are), it can be useful at 1Gb but not always, when you get > > to 10G its > > a HUGE benefit. > > > > Just cuz you can shoot yourself in the foot doesn't mean the gun has a > > problem :) > > But wait, i did not shoot myself. I have been shot by the driver w/o any > preliminary warning. TSO4 was enabled by DEFAULT (i did not enable it), > so anybody can be in my place if used the same driver on the similar hardware > (which is plenty). > > So, i think this is a problem which really need to be addressed. It is on by default because it the majority of cases its a benefit, you found it to be a problem and turned it off, your problem is solved. I admit, at one point I considered disabling it automatically for anything under Gig speed, but a large community has used this driver with this feature for over a year, no one has lobbied to have to disabled, so I have not. If there are others who think this would be a good idea, speak up, and I will do so. Cheers, Jack From owner-freebsd-current@FreeBSD.ORG Sat Sep 22 23:56:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AA4D16A41A for ; Sat, 22 Sep 2007 23:56:54 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id 10E6B13C45B for ; Sat, 22 Sep 2007 23:56:53 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so1528931fka for ; Sat, 22 Sep 2007 16:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=E+jrFCRrF3HRtmxPqTvkdUDAEZ3VGxxzyOf8q8B8Tr4=; b=jU1CeO+G7aK0QZFSFKbm6WqXtjQ6DWQsTExMsVWlZwa2u6MbKOIf486EIV4+Iy1gRP5BDB5Wy4CTH3f92laQvdD4GYGd1e+M/oMrgwU+r3OET2WFJgH6xuNKsmp/W2JhHlrvSwmRsq9bykrpzhZTuqwwM/lmT3JniAkrdH3Tmfw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=h/Tg9SDLslmLAmdp3KijOBUyPCfu6o5FI2TWCz+nFfOaS01tCytVfdDw7WMY7Eo0whi1eHQnNVkCoN3Xy64gO+mxqbQLtR505Y82sPmQA3ShbSFgEBNeXJ5De74vDUL0dibXCCReTNxzl+mfhwVJEUX8dcMnSlqp7M0AwYbluLU= Received: by 10.86.100.7 with SMTP id x7mr3450173fgb.1190505412339; Sat, 22 Sep 2007 16:56:52 -0700 (PDT) Received: by 10.86.100.19 with HTTP; Sat, 22 Sep 2007 16:56:52 -0700 (PDT) Message-ID: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> Date: Sat, 22 Sep 2007 16:56:52 -0700 From: "Jack Vogel" To: "freebsd-net@freebsd.org" , "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: TX Multiqueue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 23:56:54 -0000 Our newest E1000 nic, the 82575, and the Oplin 10G hardware are capable of multiple queues both on the receive and the send side. On the receive end for the Oplin driver the queues actually help distribute interrupts and improve performance without any special support in the stack. I have been asked about multiple queues on the TX side, embedded appliance type system builders for instance are interested I suppose for priority queueing. Is anyone working on this right now, and if not does this sound like something anyone is interested in doing? I would like to see MQ on both TX and RX that drivers could use if able. Jack