From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 01:12:50 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3136616A422 for ; Sun, 29 Jan 2006 01:12:50 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C7D143D46 for ; Sun, 29 Jan 2006 01:12:43 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail05.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k0T1CdIR026662 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 29 Jan 2006 12:12:40 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k0T1Cd7e004678; Sun, 29 Jan 2006 12:12:39 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k0T1CcSb004677; Sun, 29 Jan 2006 12:12:38 +1100 (EST) (envelope-from peter) Date: Sun, 29 Jan 2006 12:12:38 +1100 From: Peter Jeremy To: Christian Brueffer Message-ID: <20060129011238.GG2341@turion.vk2pj.dyndns.org> References: <20060128110522.GA1224@haakonia.hitnet.RWTH-Aachen.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060128110522.GA1224@haakonia.hitnet.RWTH-Aachen.DE> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: current@freebsd.org Subject: Re: panic: vm_page_insert: page already inserted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2006 01:12:50 -0000 On Sat, 2006-Jan-28 12:05:22 +0100, Christian Brueffer wrote: >from time to time I'm getting the following panic when doing a 'gbde attach' >on my external USB drive. The panic only occurs when the box has been >running for a while (when contiguous memory is more scarce i presume). Whilst that particular panic may have been fixed, there is an underlying problem with an incompatibility between bus_dmamem_alloc() and contigmalloc(). See kern/78179 -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 01:34:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C566616A423 for ; Sun, 29 Jan 2006 01:34:21 +0000 (GMT) (envelope-from devon.odell@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 168DF43D66 for ; Sun, 29 Jan 2006 01:34:14 +0000 (GMT) (envelope-from devon.odell@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so534342wxc for ; Sat, 28 Jan 2006 17:34:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JTCp94B+7XvkuXz/18CFnOtacQMzr/Upv3gsxcDwMxC0MDfnWavZ2qr+PyZA+9gT//JSu+0oTXKO4eYXLV+adkaHJcoNaGYYObOVBMkUevjZfjxmDBVezY2m0zoUwPoKSrCRHcCLml7plSLQFZgiPVWnoN2iwNQxYTse3CVvBKE= Received: by 10.70.126.14 with SMTP id y14mr5358921wxc; Sat, 28 Jan 2006 17:34:14 -0800 (PST) Received: by 10.70.67.16 with HTTP; Sat, 28 Jan 2006 17:34:14 -0800 (PST) Message-ID: <9ab217670601281734v71a2f5a8q@mail.gmail.com> Date: Sat, 28 Jan 2006 17:34:14 -0800 From: "Devon H. O'Dell" To: Christian Brueffer In-Reply-To: <20060128120638.GB1224@haakonia.hitnet.RWTH-Aachen.DE> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060128110522.GA1224@haakonia.hitnet.RWTH-Aachen.DE> <20060128120638.GB1224@haakonia.hitnet.RWTH-Aachen.DE> Cc: current@freebsd.org Subject: Re: panic: vm_page_insert: page already inserted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2006 01:34:21 -0000 2006/1/28, Christian Brueffer : > On Sat, Jan 28, 2006 at 12:05:22PM +0100, Christian Brueffer wrote: > > Hi, > > > > from time to time I'm getting the following panic when doing a 'gbde at= tach' > > on my external USB drive. The panic only occurs when the box has been > > running for a while (when contiguous memory is more scarce i presume). > > > > System built of sources from Jan 24 19:19:07 CET. > > > > panic: vm_page_insert: page already inserted > > Alex Leidinger pointed out, that this panic was fixed a couple of days > ago. Sorry for the noise. > > - Christian It was? That's great! It looks very, VERY much like something that I'm seeing on random machines here, and indeed I'm not getting it with HEAD from yesterday (which was confusing me this morning, but now it makes sense :)). Will this be MFC'ed back to 6 and 5? Various machines of ours have been failing with these panics in 5.x, and 6.x both FreeBSD/i386 and FreeBSD/amd64. --Devon From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 02:45:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C63A216A420 for ; Sun, 29 Jan 2006 02:45:08 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail22.syd.optusnet.com.au (mail22.syd.optusnet.com.au [211.29.133.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E67A43D45 for ; Sun, 29 Jan 2006 02:45:07 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail22.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k0T2j6Wj011632 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 29 Jan 2006 13:45:06 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k0T2j6l6005067; Sun, 29 Jan 2006 13:45:06 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k0T2j6le005066; Sun, 29 Jan 2006 13:45:06 +1100 (EST) (envelope-from peter) Date: Sun, 29 Jan 2006 13:45:06 +1100 From: Peter Jeremy To: "Devon H. O'Dell" Message-ID: <20060129024506.GM2341@turion.vk2pj.dyndns.org> References: <20060128110522.GA1224@haakonia.hitnet.RWTH-Aachen.DE> <20060128120638.GB1224@haakonia.hitnet.RWTH-Aachen.DE> <9ab217670601281734v71a2f5a8q@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ab217670601281734v71a2f5a8q@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: current@freebsd.org Subject: Re: panic: vm_page_insert: page already inserted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2006 02:45:08 -0000 On Sat, 2006-Jan-28 17:34:14 -0800, Devon H. O'Dell wrote: >2006/1/28, Christian Brueffer : >> Alex Leidinger pointed out, that this panic was fixed a couple of days >> ago. Sorry for the noise. > >It was? That's great! It looks very, VERY much like something that I'm >seeing on random machines here, and indeed I'm not getting it with >HEAD from yesterday (which was confusing me this morning, but now it >makes sense :)). The bug that was fixed was introduced into head at the end of 2005. If you're seeing problems in 6.x or 5.x, it is a different problem. Do you have the panic message and a backtrace? -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 05:55:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2612A16A420; Sun, 29 Jan 2006 05:55:53 +0000 (GMT) (envelope-from nate@root.org) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6268743D5D; Sun, 29 Jan 2006 05:55:49 +0000 (GMT) (envelope-from nate@root.org) Received: from ylpvm01.prodigy.net (ylpvm01-int.prodigy.net [207.115.5.207]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k0T5tieY005770; Sun, 29 Jan 2006 00:55:45 -0500 X-ORBL: [71.139.114.10] Received: from [10.0.0.115] (ppp-71-139-114-10.dsl.snfc21.pacbell.net [71.139.114.10]) by ylpvm01.prodigy.net (8.13.4 dk-milter linux/8.13.4) with ESMTP id k0T5tlrY006925; Sun, 29 Jan 2006 00:55:48 -0500 Message-ID: <43DC58F4.5040506@root.org> Date: Sat, 28 Jan 2006 21:56:04 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050723) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org References: <20060129055214.E93B916A43E@hub.freebsd.org> In-Reply-To: <20060129055214.E93B916A43E@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: cvs commit: src/etc/defaults rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2006 05:55:53 -0000 Nate Lawson wrote: > njl 2006-01-29 05:51:58 UTC > > FreeBSD src repository > > Modified files: > etc/defaults rc.conf > Log: > Enable the lowest Cx state by default. This will save power and we have > had enough testing of acpi_cpu to know this is stable now. > > Revision Changes Path > 1.272 +2 -2 src/etc/defaults/rc.conf This has been tested in 5, 6, and 7.x for a year and a half so it should be stable. Still, if your system starts hanging, try resetting this back to its previous value by putting the following in /etc/rc.conf: performance_cx_lowest="HIGH" economy_cx_lowest="HIGH" Only notify me if you experience a new problem that the above rc.conf change fixes, and only if it's with 7-CURRENT. Thanks. -- Nate From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 07:46:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 128AE16A424; Sun, 29 Jan 2006 07:46:47 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75F4043D46; Sun, 29 Jan 2006 07:46:46 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id k0T7sZOE072914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jan 2006 02:54:41 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org Date: Sun, 29 Jan 2006 02:49:17 -0500 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_VOH3D8QYbbI4KBz" Message-Id: <200601290249.41648.mistry.7@osu.edu> X-Spam-Status: No, score=-10.5 required=5.0 tests=ALL_TRUSTED,BAYES_00, J_CHICKENPOX_66,MYFREEBSD2,MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.88/1255/Sat Jan 28 04:55:09 2006 on mail.united-ware.com X-Virus-Status: Clean Cc: colazelli@gmail.com, Brandon Mitchell Subject: [PATCH] acpi_fujitsu UPDATE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2006 07:46:47 -0000 --Boundary-00=_VOH3D8QYbbI4KBz Content-Type: multipart/signed; boundary="nextPart2333793.72tP5KujUY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2333793.72tP5KujUY Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I've attached a patch for acpi_fujitsu that SHOULD allow non-P=20 laptops to attach the device. I need other people to test this=20 because the P-Series (My laptop P2110) has all of the methods so the=20 conditional method probing always works. If you could report back=20 soon, hopefully we can get a commiter to squeeze it in before the=20 freeze. The major changes are: - Individual method probing - So if you are missing a few methods you=20 only lose that functionality. - I finally figured out what the RBLL, RVOL, GHKS, GSIF RBLL - lcd_brightness radix RVOL - volume radix GHKS - Currently activated hotkey (internal) GSIF - Hotkey mask (internal) Also at: http://am-productions.biz/docs/acpi_fujitsu.patch =2D-=20 Anish Mistry --nextPart2333793.72tP5KujUY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD3HOVxqA5ziudZT0RAh/PAJ9fMuXAHgP9ozNf8S+DtIQ/fyw5wACeJbBY EzFTFQqYaO9IZsy42ivsPt4= =7n2S -----END PGP SIGNATURE----- --nextPart2333793.72tP5KujUY-- --Boundary-00=_VOH3D8QYbbI4KBz Content-Type: text/x-diff; charset="us-ascii"; name="acpi_fujitsu.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi_fujitsu.patch" --- acpi_fujitsu.c.orig Sun Jan 29 02:19:52 2006 +++ acpi_fujitsu.c Sun Jan 29 02:35:36 2006 @@ -1,6 +1,6 @@ /*- * Copyright (c) 2002 Sean Bullington - * 2003-2005 Anish Mistry + * 2003-2006 Anish Mistry * 2004 Mark Santcroos * All Rights Reserved. * @@ -44,11 +44,8 @@ #define _COMPONENT ACPI_OEM ACPI_MODULE_NAME("Fujitsu") -/* Change and update bits for the buttons */ -#define MOUSE_UPDATED_BIT 0x80000000 +/* Change and update bits for the hotkeys */ #define VOLUME_MUTE_BIT 0x40000000 -#define VOLUME_CHANGE_BIT 0x80000000 -#define BRIGHTNESS_CHANGE_BIT 0x80000000 /* Values of settings */ #define GENERAL_SETTING_BITS 0x0fffffff @@ -57,9 +54,20 @@ #define BRIGHTNESS_SETTING_BITS GENERAL_SETTING_BITS /* Possible state changes */ -#define VOLUME_CHANGED 1 -#define BRIGHT_CHANGED 2 -#define MOUSE_CHANGED 3 +/* + * These are NOT arbitrary values. They are the + * GHKS return value from the device that says which + * hotkey is active. They should match up with a bit + * from the GSIF bitmask. + */ +#define BRIGHT_CHANGED 0x01 +#define VOLUME_CHANGED 0x04 +#define MOUSE_CHANGED 0x08 +/* + * It is unknown which hotkey this bit is supposed to indicate, but + * according to values from GSIF this is a valid flag. + */ +#define UNKNOWN_CHANGED 0x10 /* sysctl values */ #define FN_MUTE 0 @@ -72,6 +80,10 @@ #define METHOD_GMOU 2 #define METHOD_GVOL 3 #define METHOD_MUTE 4 +#define METHOD_RBLL 5 +#define METHOD_RVOL 6 +#define METHOD_GSIF 7 +#define METHOD_GHKS 8 /* Notify event */ #define ACPI_NOTIFY_STATUS_CHANGED 0x80 @@ -83,6 +95,7 @@ struct int_nameval { char *name; int value; + int exists; }; /* @@ -95,12 +108,13 @@ /* Control methods */ struct int_nameval _sta, /* unused */ gbll, /* brightness */ - ghks, /* unused */ + ghks, /* hotkey selector */ + gbuf, /* unused (buffer?) */ gmou, /* mouse */ - gsif, /* unused */ + gsif, /* function key bitmask */ gvol, /* volume */ - rbll, /* unused */ - rvol; /* unused */ + rbll, /* number of brightness levels (radix) */ + rvol; /* number of volume levels (radix) */ /* State variables */ uint8_t bIsMuted; /* Is volume muted */ @@ -126,6 +140,7 @@ /* Utility function declarations */ static uint8_t acpi_fujitsu_update(struct acpi_fujitsu_softc *sc); static uint8_t acpi_fujitsu_init(struct acpi_fujitsu_softc *sc); +static uint8_t acpi_fujitsu_check_hardware(struct acpi_fujitsu_softc *sc); /* Driver/Module specific structure definitions. */ static device_method_t acpi_fujitsu_methods[] = { @@ -144,13 +159,13 @@ sizeof(struct acpi_fujitsu_softc), }; -/* Prototype for function buttons for getting/setting a value. */ +/* Prototype for function hotkeys for getting/setting a value. */ static int acpi_fujitsu_method_get(struct acpi_fujitsu_softc *sc, int method); static int acpi_fujitsu_method_set(struct acpi_fujitsu_softc *sc, int method, int value); static char *fujitsu_ids[] = { "FUJ02B1", NULL }; -ACPI_SERIAL_DECL(fujitsu, "Fujitsu Function Buttons"); +ACPI_SERIAL_DECL(fujitsu, "Fujitsu Function Hotkeys"); /* sysctl names and function calls */ static struct { @@ -178,6 +193,16 @@ .method = METHOD_GVOL, .description = "Speakers/headphones volume level" }, + { + .name = "volume_radix", + .method = METHOD_RVOL, + .description = "Number of volume level steps" + }, + { + .name = "lcd_brightness_radix", + .method = METHOD_RBLL, + .description = "Number of brightness level steps" + }, { NULL, 0, NULL } }; @@ -197,7 +222,7 @@ device_get_unit(dev) != 0) return (ENXIO); - device_set_desc(dev, "Fujitsu Function Buttons"); + device_set_desc(dev, "Fujitsu Function Hotkeys"); return (0); } @@ -217,10 +242,10 @@ AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY, acpi_fujitsu_notify_handler, sc); - /* Snag our default values for the buttons / button states. */ + /* Snag our default values for the hotkys / hotkey states. */ ACPI_SERIAL_BEGIN(fujitsu); if (!acpi_fujitsu_init(sc)) - device_printf(dev, "Couldn't initialize button states!\n"); + device_printf(dev, "Couldn't initialize hotkey states!\n"); ACPI_SERIAL_END(fujitsu); return (0); @@ -316,13 +341,13 @@ /* * Initializes the names of the ACPI control methods and grabs - * the current state of all of the ACPI buttons into the softc. + * the current state of all of the ACPI hotkeys into the softc. */ static uint8_t acpi_fujitsu_init(struct acpi_fujitsu_softc *sc) { struct acpi_softc *acpi_sc; - int i; + int i, exists; ACPI_SERIAL_ASSERT(fujitsu); @@ -333,9 +358,14 @@ sc->gmou.name = "GMOU"; sc->gsif.name = "GSIF"; sc->gvol.name = "GVOL"; + sc->ghks.name = "GHKS"; + sc->gsif.name = "GSIF"; sc->rbll.name = "RBLL"; sc->rvol.name = "RVOL"; + /* Determine what hardware functionality is available */ + acpi_fujitsu_check_hardware(sc); + /* Build the sysctl tree */ acpi_sc = acpi_device_get_parent_softc(sc->dev); sysctl_ctx_init(&sc->sysctl_ctx); @@ -344,6 +374,31 @@ OID_AUTO, "fujitsu", CTLFLAG_RD, 0, ""); for (i = 0; sysctl_table[i].name != NULL; i++) { + exists = 0; + switch(sysctl_table[i].method) { + case METHOD_GMOU: + exists = sc->gmou.exists; + break; + case METHOD_GBLL: + exists = sc->gbll.exists; + break; + case METHOD_GVOL: + case METHOD_MUTE: + exists = sc->gvol.exists; + break; + case METHOD_RVOL: + exists = sc->rvol.exists; + break; + case METHOD_RBLL: + exists = sc->rbll.exists; + break; + default: + /* Allow by default */ + exists = 1; + break; + } + if(!exists) + continue; SYSCTL_ADD_PROC(&sc->sysctl_ctx, SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO, sysctl_table[i].name, @@ -352,9 +407,10 @@ sysctl_table[i].description); } - /* Set the buttons to their initial states */ + + /* Set the hotkeys to their initial states */ if (!acpi_fujitsu_update(sc)) { - device_printf(sc->dev, "Couldn't init button states\n"); + device_printf(sc->dev, "Couldn't init hotkey states\n"); return (FALSE); } @@ -409,6 +465,18 @@ case METHOD_MUTE: nv = sc->gvol; break; + case METHOD_GHKS: + nv = sc->ghks; + break; + case METHOD_GSIF: + nv = sc->gsif; + break; + case METHOD_RBLL: + nv = sc->rbll; + break; + case METHOD_RVOL: + nv = sc->rvol; + break; default: return (FALSE); } @@ -479,86 +547,156 @@ } /* - * Query each of the ACPI control methods that contain information we're - * interested in. We check the return values from the control methods and - * adjust any state variables if they should be adjusted. + * Query the get methods to determine what functionality is available + * from the hardware function hotkeys. */ static uint8_t -acpi_fujitsu_update(struct acpi_fujitsu_softc *sc) +acpi_fujitsu_check_hardware(struct acpi_fujitsu_softc *sc) { + int val; struct acpi_softc *acpi_sc; acpi_sc = acpi_device_get_parent_softc(sc->dev); ACPI_SERIAL_ASSERT(fujitsu); - - /* System Volume Level */ + /* save the hotkey bitmask */ if (ACPI_FAILURE(acpi_GetInteger(sc->handle, - sc->gvol.name, &(sc->gvol.value)))) { - device_printf(sc->dev, "Couldn't query volume level\n"); + sc->gsif.name, &(sc->gsif.value)))) { + sc->gsif.exists = 0; + device_printf(sc->dev, "Couldn't query bitmask value\n"); return (FALSE); } + sc->gsif.exists = 1; - if (sc->gvol.value & VOLUME_CHANGE_BIT) { - sc->bIsMuted = - (uint8_t)((sc->gvol.value & VOLUME_MUTE_BIT) != 0); - - /* Clear the modification bit */ - sc->gvol.value &= VOLUME_SETTING_BITS; - - if (sc->bIsMuted) { - acpi_UserNotify("FUJITSU", sc->handle, FN_MUTE); - ACPI_VPRINT(sc->dev, acpi_sc, "Volume is now mute\n"); - } else - ACPI_VPRINT(sc->dev, acpi_sc, "Volume is now %d\n", - sc->gvol.value); - - acpi_UserNotify("FUJITSU", sc->handle, FN_VOLUME); - - sc->lastValChanged = VOLUME_CHANGED; + /* System Volume Level */ + if (ACPI_FAILURE(acpi_GetInteger(sc->handle, + sc->gvol.name, &val))) { + sc->gvol.exists = 0; + } else { + sc->gvol.exists = 1; } - /* Internal mouse pointer (eraserhead) */ if (ACPI_FAILURE(acpi_GetInteger(sc->handle, - sc->gmou.name, &(sc->gmou.value)))) { - device_printf(sc->dev, "Couldn't query pointer state\n"); - return (FALSE); + sc->gbll.name, &val))) { + sc->gbll.exists = 0; + } else { + sc->gbll.exists = 1; } - if (sc->gmou.value & MOUSE_UPDATED_BIT) { - sc->bIntPtrEnabled = (uint8_t)(sc->gmou.value & 0x1); - - /* Clear the modification bit */ - sc->gmou.value &= MOUSE_SETTING_BITS; - - acpi_UserNotify("FUJITSU", sc->handle, FN_POINTER_ENABLE); + if (ACPI_FAILURE(acpi_GetInteger(sc->handle, + sc->ghks.name, &val))) { + sc->ghks.exists = 0; + } else { + sc->ghks.exists = 1; + } - ACPI_VPRINT(sc->dev, acpi_sc, "Internal pointer is now %s\n", - (sc->bIntPtrEnabled) ? "enabled" : "disabled"); + if (ACPI_FAILURE(acpi_GetInteger(sc->handle, + sc->gmou.name, &val))) { + sc->gmou.exists = 0; + } else { + sc->gmou.exists = 1; + } - sc->lastValChanged = MOUSE_CHANGED; + if (ACPI_FAILURE(acpi_GetInteger(sc->handle, + sc->rbll.name, &val))) { + sc->rbll.exists = 0; + } else { + sc->rbll.exists = 1; } - /* Screen Brightness Level */ if (ACPI_FAILURE(acpi_GetInteger(sc->handle, - sc->gbll.name, &(sc->gbll.value)))) { - device_printf(sc->dev, "Couldn't query brightness level\n"); - return (FALSE); + sc->rvol.name, &val))) { + sc->rvol.exists = 0; + } else { + sc->rvol.exists = 1; } - if (sc->gbll.value & BRIGHTNESS_CHANGE_BIT) { - /* No state to record here. */ + return (TRUE); +} - /* Clear the modification bit */ - sc->gbll.value &= BRIGHTNESS_SETTING_BITS; +/* + * Query each of the ACPI control methods that contain information we're + * interested in. We check the return values from the control methods and + * adjust any state variables if they should be adjusted. + */ +static uint8_t +acpi_fujitsu_update(struct acpi_fujitsu_softc *sc) +{ + int changed; + struct acpi_softc *acpi_sc; - acpi_UserNotify("FUJITSU", sc->handle, FN_LCD_BRIGHTNESS); + acpi_sc = acpi_device_get_parent_softc(sc->dev); - ACPI_VPRINT(sc->dev, acpi_sc, "Brightness level is now %d\n", - sc->gbll.value); + ACPI_SERIAL_ASSERT(fujitsu); + changed = sc->gsif.value & acpi_fujitsu_method_get(sc,METHOD_GHKS); + + /* System Volume Level */ + if(sc->gvol.exists) { + if (ACPI_FAILURE(acpi_GetInteger(sc->handle, + sc->gvol.name, &(sc->gvol.value)))) { + device_printf(sc->dev, "Couldn't query volume level\n"); + return (FALSE); + } + + if (changed & VOLUME_CHANGED) { + sc->bIsMuted = + (uint8_t)((sc->gvol.value & VOLUME_MUTE_BIT) != 0); + + /* Clear the modification bit */ + sc->gvol.value &= VOLUME_SETTING_BITS; + + if (sc->bIsMuted) { + acpi_UserNotify("FUJITSU", sc->handle, FN_MUTE); + ACPI_VPRINT(sc->dev, acpi_sc, "Volume is now mute\n"); + } else + ACPI_VPRINT(sc->dev, acpi_sc, "Volume is now %d\n", + sc->gvol.value); + + acpi_UserNotify("FUJITSU", sc->handle, FN_VOLUME); + } + } - sc->lastValChanged = BRIGHT_CHANGED; + /* Internal mouse pointer (eraserhead) */ + if(sc->gmou.exists) { + if (ACPI_FAILURE(acpi_GetInteger(sc->handle, + sc->gmou.name, &(sc->gmou.value)))) { + device_printf(sc->dev, "Couldn't query pointer state\n"); + return (FALSE); + } + + if (changed & MOUSE_CHANGED) { + sc->bIntPtrEnabled = (uint8_t)(sc->gmou.value & 0x1); + + /* Clear the modification bit */ + sc->gmou.value &= MOUSE_SETTING_BITS; + + acpi_UserNotify("FUJITSU", sc->handle, FN_POINTER_ENABLE); + + ACPI_VPRINT(sc->dev, acpi_sc, "Internal pointer is now %s\n", + (sc->bIntPtrEnabled) ? "enabled" : "disabled"); + } } + /* Screen Brightness Level */ + if(sc->gbll.exists) { + if (ACPI_FAILURE(acpi_GetInteger(sc->handle, + sc->gbll.name, &(sc->gbll.value)))) { + device_printf(sc->dev, "Couldn't query brightness level\n"); + return (FALSE); + } + + if (changed & BRIGHT_CHANGED) { + /* No state to record here. */ + + /* Clear the modification bit */ + sc->gbll.value &= BRIGHTNESS_SETTING_BITS; + + acpi_UserNotify("FUJITSU", sc->handle, FN_LCD_BRIGHTNESS); + + ACPI_VPRINT(sc->dev, acpi_sc, "Brightness level is now %d\n", + sc->gbll.value); + } + } + sc->lastValChanged = changed; return (TRUE); } --Boundary-00=_VOH3D8QYbbI4KBz-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 08:07:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 171BC16A420 for ; Sun, 29 Jan 2006 08:07:31 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id D18A343D46 for ; Sun, 29 Jan 2006 08:07:30 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.10]) ([10.251.60.23]) by a50.ironport.com with ESMTP; 29 Jan 2006 00:07:29 -0800 Message-ID: <43DC77C1.8060308@elischer.org> Date: Sun, 29 Jan 2006 00:07:29 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <20060126195647.GA2559@turion.vk2pj.dyndns.org> <20060128134625.GA2384@turion.vk2pj.dyndns.org> In-Reply-To: <20060128134625.GA2384@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Unreferenced files not being deleted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2006 08:07:31 -0000 Peter Jeremy wrote: >On Fri, 2006-Jan-27 06:56:47 +1100, Peter Jeremy wrote: > > >>On my recent -current, I've noticed that /var is filling up with >>unreferenced files. >> >> > >Updated data point: The files do disappear on a clean shutdown >so the kernel seems to be aware that they have no name but >neither fstat nor lsof can find any processes holding them open. >I have a core dump demonstrating the problem and will poke around >in it as a background task. > > > You know it occured to me that a process that is not in the process list would still work.. could be an easy way to effect a rootkit if one had root access. wouldn't show up in ps, fstat etc. it could be another answer to your mystery.. :-/ From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 12:04:54 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0554816A420; Sun, 29 Jan 2006 12:04:54 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DF8243D49; Sun, 29 Jan 2006 12:04:53 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id k0TC4qfc015304; Sun, 29 Jan 2006 07:04:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4/8.13.4) with ESMTP id k0TC4hSj056522; Sun, 29 Jan 2006 07:04:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CBBF57302F; Sun, 29 Jan 2006 07:04:51 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060129120451.CBBF57302F@freebsd-current.sentex.ca> Date: Sun, 29 Jan 2006 07:04:51 -0500 (EST) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 12:04:54 -0000 TB --- 2006-01-29 10:26:47 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-01-29 10:26:47 - starting HEAD tinderbox run for alpha/alpha TB --- 2006-01-29 10:26:47 - cleaning the object tree TB --- 2006-01-29 10:27:14 - checking out the source tree TB --- 2006-01-29 10:27:14 - cd /tinderbox/HEAD/alpha/alpha TB --- 2006-01-29 10:27:14 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-01-29 10:33:53 - building world (CFLAGS=-O2 -pipe) TB --- 2006-01-29 10:33:53 - cd /src TB --- 2006-01-29 10:33:53 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-01-29 11:39:39 - generating LINT kernel config TB --- 2006-01-29 11:39:39 - cd /src/sys/alpha/conf TB --- 2006-01-29 11:39:39 - /usr/bin/make -B LINT TB --- 2006-01-29 11:39:40 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-01-29 11:39:40 - cd /src TB --- 2006-01-29 11:39:40 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 29 11:39:40 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Jan 29 12:00:44 UTC 2006 TB --- 2006-01-29 12:00:44 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-01-29 12:00:44 - cd /src TB --- 2006-01-29 12:00:44 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jan 29 12:00:44 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/kern/kern_prot.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/kern/kern_rwlock.c /src/sys/kern/kern_rwlock.c: In function `_rw_assert': /src/sys/kern/kern_rwlock.c:519: error: `RW_RLOCKED' undeclared (first use in this function) /src/sys/kern/kern_rwlock.c:519: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_rwlock.c:519: error: for each function it appears in.) /src/sys/kern/kern_rwlock.c:520: error: invalid operands to binary & *** Error code 1 Stop in /obj/alpha/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-01-29 12:04:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-01-29 12:04:51 - ERROR: failed to build GENERIC kernel TB --- 2006-01-29 12:04:51 - tinderbox aborted TB --- 0.66 user 3.67 system 5884.23 real From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 13:04:42 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE8FF16A420 for ; Sun, 29 Jan 2006 13:04:42 +0000 (GMT) (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 008F443D70 for ; Sun, 29 Jan 2006 13:04:35 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k0TD4ZWT005993 for ; Sun, 29 Jan 2006 05:04:35 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k0TD4ZXu005992 for current@freebsd.org; Sun, 29 Jan 2006 05:04:35 -0800 (PST) (envelope-from rizzo) Date: Sun, 29 Jan 2006 05:04:35 -0800 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20060129050435.A5945@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: for review: sys/dev/md/md.c 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: Sun, 29 Jan 2006 13:04:43 -0000 just discovered, trying to resurrect picobsd on -current, that the compiler in 6.x/7.x has become smart and, at least with the default compilation flags, will optimize out the "end_mfs_root" string from the object. As a consequence, any checks that the preloaded module does not overflow the allocated space (looking at the 'MFS Filesystem had better STOP here' string in the patched object) will fail. The attached patch fixes the issue. Any objection if i commit it ? cheers luigi Index: md.c =================================================================== RCS file: /prova/home/ncvs/src/sys/dev/md/md.c,v retrieving revision 1.159 diff -u -p -r1.159 md.c --- md.c 31 Oct 2005 15:41:19 -0000 1.159 +++ md.c 29 Jan 2006 12:57:22 -0000 @@ -102,8 +102,13 @@ SYSCTL_INT(_debug, OID_AUTO, mddebug, CT #if defined(MD_ROOT) && defined(MD_ROOT_SIZE) /* Image gets put here: */ -static u_char mfs_root[MD_ROOT_SIZE*1024] = "MFS Filesystem goes here"; -static u_char end_mfs_root[] __unused = "MFS Filesystem had better STOP here"; +static struct { + u_char start[MD_ROOT_SIZE*1024]; + u_char end[128]; +} mfs_root = { + .start = "MFS Filesystem goes here", + .end = "MFS Filesystem had better STOP here", +}; #endif static g_init_t g_md_init; @@ -1139,7 +1144,7 @@ g_md_init(struct g_class *mp __unused) g_topology_unlock(); #ifdef MD_ROOT_SIZE sx_xlock(&md_sx); - md_preloaded(mfs_root, MD_ROOT_SIZE * 1024); + md_preloaded(mfs_root.start, MD_ROOT_SIZE * 1024); sx_xunlock(&md_sx); #endif /* XXX: are preload_* static or do they need Giant ? */ From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 20:35:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 147CE16A420 for ; Sun, 29 Jan 2006 20:35:00 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DC6A43D73 for ; Sun, 29 Jan 2006 20:34:54 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.6]) ([10.251.60.63]) by a50.ironport.com with ESMTP; 29 Jan 2006 12:34:53 -0800 Message-ID: <43DD26EE.50608@elischer.org> Date: Sun, 29 Jan 2006 12:34:54 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20060129050435.A5945@xorpc.icir.org> In-Reply-To: <20060129050435.A5945@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: for review: sys/dev/md/md.c 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: Sun, 29 Jan 2006 20:35:00 -0000 Luigi Rizzo wrote: >just discovered, trying to resurrect picobsd on -current, >that the compiler in 6.x/7.x has become smart and, at least >with the default compilation flags, will optimize out >the "end_mfs_root" string from the object. >As a consequence, any checks that the preloaded module >does not overflow the allocated space (looking at the >'MFS Filesystem had better STOP here' string in the patched >object) will fail. > >The attached patch fixes the issue. Any objection if i commit it ? > > seems fair to me. can't hurt anything unless MD_ROOT_SIZE is defined.. I LIKE PicoBSD.. and it woul dbe a shame if it was lost as a capacity. It's a pitty everythng has grown so much.. last I tried (on 5.x) you could JUST get a kenrel plus a shell and one small app. (in my case ssh). onto a floppy.. I hav eserious doubts about being able to do that now.. pitty.. I have an old laptop with no HD that was a good little VPN endpoint using the 5.x based picoBSD. > cheers > luigi > >Index: md.c >=================================================================== >RCS file: /prova/home/ncvs/src/sys/dev/md/md.c,v >retrieving revision 1.159 >diff -u -p -r1.159 md.c >--- md.c 31 Oct 2005 15:41:19 -0000 1.159 >+++ md.c 29 Jan 2006 12:57:22 -0000 >@@ -102,8 +102,13 @@ SYSCTL_INT(_debug, OID_AUTO, mddebug, CT > > #if defined(MD_ROOT) && defined(MD_ROOT_SIZE) > /* Image gets put here: */ >-static u_char mfs_root[MD_ROOT_SIZE*1024] = "MFS Filesystem goes here"; >-static u_char end_mfs_root[] __unused = "MFS Filesystem had better STOP here"; >+static struct { >+ u_char start[MD_ROOT_SIZE*1024]; >+ u_char end[128]; >+} mfs_root = { >+ .start = "MFS Filesystem goes here", >+ .end = "MFS Filesystem had better STOP here", >+}; > #endif > > static g_init_t g_md_init; >@@ -1139,7 +1144,7 @@ g_md_init(struct g_class *mp __unused) > g_topology_unlock(); > #ifdef MD_ROOT_SIZE > sx_xlock(&md_sx); >- md_preloaded(mfs_root, MD_ROOT_SIZE * 1024); >+ md_preloaded(mfs_root.start, MD_ROOT_SIZE * 1024); > sx_xunlock(&md_sx); > #endif > /* XXX: are preload_* static or do they need Giant ? */ >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 20:20:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D251F16A420 for ; Sun, 29 Jan 2006 20:20:29 +0000 (GMT) (envelope-from magicsmoke@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9350543D49 for ; Sun, 29 Jan 2006 20:20:28 +0000 (GMT) (envelope-from magicsmoke@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so849096wra for ; Sun, 29 Jan 2006 12:20:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=WJLfz8ceEFQ5TU5iq6PmR/tuK0Ha/WThdtjXwfsgz0cdZB6+LXXbXEC6binE56NY5dzgB2hfj13A1+HgYcCwddgKDnzDqUUQOAQkHGzY8HUMsfguFn8hHiTFkX9K80i5A4t0GsqizCOShUqKAITn4zWsNnPr+F40o8WWT790ltE= Received: by 10.64.142.7 with SMTP id p7mr1471093qbd; Sun, 29 Jan 2006 12:20:27 -0800 (PST) Received: by 10.64.184.18 with HTTP; Sun, 29 Jan 2006 12:20:27 -0800 (PST) Message-ID: <97bedf530601291220l74ee4cb9g834bd63d510adc4a@mail.gmail.com> Date: Sun, 29 Jan 2006 12:20:27 -0800 From: Brandon Mitchell To: Anish Mistry In-Reply-To: <200601290249.41648.mistry.7@osu.edu> MIME-Version: 1.0 References: <200601290249.41648.mistry.7@osu.edu> X-Mailman-Approved-At: Sun, 29 Jan 2006 20:56:58 +0000 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: freebsd-current@freebsd.org, colazelli@gmail.com Subject: Re: [PATCH] acpi_fujitsu UPDATE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2006 20:20:30 -0000 Anish, This patch attached just fine, though no noticable change in functionality was found. Thanks. Brandon Mitchell On 1/28/06, Anish Mistry wrote: > > I've attached a patch for acpi_fujitsu that SHOULD allow non-P > laptops to attach the device. I need other people to test this > because the P-Series (My laptop P2110) has all of the methods so the > conditional method probing always works. If you could report back > soon, hopefully we can get a commiter to squeeze it in before the > freeze. > The major changes are: > - Individual method probing - So if you are missing a few methods > you > only lose that functionality. > - I finally figured out what the RBLL, RVOL, GHKS, GSIF > RBLL - lcd_brightness radix > RVOL - volume radix > GHKS - Currently activated hotkey (internal) > GSIF - Hotkey mask (internal) > > Also at: > http://am-productions.biz/docs/acpi_fujitsu.patch > > -- > Anish Mistry > > > -- If UNIX doesn't have the solution you have the wrong problem. UNIX is simple, but it takes a genius to understand it's simplicity. From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 21:21:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D151716A420 for ; Sun, 29 Jan 2006 21:21:43 +0000 (GMT) (envelope-from erik.winge@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id E97C543D46 for ; Sun, 29 Jan 2006 21:21:42 +0000 (GMT) (envelope-from erik.winge@gmail.com) Received: by uproxy.gmail.com with SMTP id y2so674336uge for ; Sun, 29 Jan 2006 13:21:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qG6nNMO/4aa7CwOTWsdfeM9X+b3+estxvl7G5KI5/rQDJAAXyMsH6O7x/uAjySYDnYGBot2YtTrefXX8+DhvCYU4N2ugk2nk4+2zDziXyJARe9DPBcR82iqqM9dv+ipgt9cohIZ412YIXWlXVpm5JwCvYOmgCVsON/0XCMTqMXA= Received: by 10.48.220.3 with SMTP id s3mr568459nfg; Sun, 29 Jan 2006 13:21:41 -0800 (PST) Received: by 10.49.94.16 with HTTP; Sun, 29 Jan 2006 13:21:41 -0800 (PST) Message-ID: <4cf221cc0601291321i586012dbnb7125e4973bce1bd@mail.gmail.com> Date: Sun, 29 Jan 2006 22:21:41 +0100 From: Erik Winge To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: lor in drm_drv/vm_glue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2006 21:21:43 -0000 Hi all, I got the following LOR with -current from yesterday. lock order reversal: (sleepable after non-sleepable) 1st 0xc2f304d4 drm device (drm device) @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 2nd 0xc332d464 user map (user map) @ /usr/src/sys/vm/vm_glue.c:182 KDB: stack backtrace: witness_checkorder(c332d464,9,c0636c35,b6,c0626c4b) at witness_checkorder+0= x67a _sx_xlock(c332d464,c0636c35,b6,c0677d14,1000008) at _sx_xlock+0x5c useracc(aa6e600,8,1,c04cfcd3,c33c3012) at useracc+0x66 i915_batchbuffer(c3330400,80186443,c345f8c0,3,c3417d00) at i915_batchbuffer+0x358 drm_ioctl(c3330400,80186443,c345f8c0,3,c3417d00) at drm_ioctl+0x1af giant_ioctl(c3330400,80186443,c345f8c0,3,c3417d00) at giant_ioctl+0x56 devfs_ioctl_f(c337f4c8,80186443,c345f8c0,c346aa80,c3417d00) at devfs_ioctl_f+0x66 ioctl(c3417d00,d63bed04,c,d63bec9c,3) at ioctl+0x118 syscall(3b,2862003b,bfbf003b,af89c10,10) at syscall+0x164 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x28602123, esp =3D 0xbfbfe3ec, ebp=3D 0xbfbfe408 --- Erik From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 21:40:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF33116A422; Sun, 29 Jan 2006 21:40:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1B9243D45; Sun, 29 Jan 2006 21:40:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id F3E5D1FFAD3; Sun, 29 Jan 2006 22:40:07 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 413761FFAD1; Sun, 29 Jan 2006 22:40:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5689544487E; Sun, 29 Jan 2006 21:38:29 +0000 (UTC) Date: Sun, 29 Jan 2006 21:38:29 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Erik Winge In-Reply-To: <4cf221cc0601291321i586012dbnb7125e4973bce1bd@mail.gmail.com> Message-ID: <20060129213726.G24703@maildrop.int.zabbadoz.net> References: <4cf221cc0601291321i586012dbnb7125e4973bce1bd@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: Eric Anholt , freebsd-current@freebsd.org Subject: Re: lor in drm_drv/vm_glue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2006 21:40:12 -0000 On Sun, 29 Jan 2006, Erik Winge wrote: > Hi all, > > I got the following LOR with -current from yesterday. > > lock order reversal: (sleepable after non-sleepable) > 1st 0xc2f304d4 drm device (drm device) @ > /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 > 2nd 0xc332d464 user map (user map) @ /usr/src/sys/vm/vm_glue.c:182 I added this with LOR ID 178 to "the LOR page": http://sources.zabbadoz.net/freebsd/lor.html#178 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 22:17:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 428C816A44A for ; Sun, 29 Jan 2006 22:17:05 +0000 (GMT) (envelope-from erik.winge@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90F9243D45 for ; Sun, 29 Jan 2006 22:17:03 +0000 (GMT) (envelope-from erik.winge@gmail.com) Received: by uproxy.gmail.com with SMTP id y2so689452uge for ; Sun, 29 Jan 2006 14:16:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=DxDbQTt7ufrGZB3QjfhauogLPkRcE1aXlVSux2vrPkqcFpBLgcJ300bUVykFxTwMG0En4gYYNo84BWye4BH7RAtJl2gPndSj10gOTGBb/dnI/94pCONMqYxinxsGZTo7juvD6CrDVvXGN1Gl5O/G5WagufntjW7SGsPWEkEbFkg= Received: by 10.48.220.3 with SMTP id s3mr573117nfg; Sun, 29 Jan 2006 13:52:06 -0800 (PST) Received: by 10.49.94.16 with HTTP; Sun, 29 Jan 2006 13:52:06 -0800 (PST) Message-ID: <4cf221cc0601291352x314a0260k274de215aee01e96@mail.gmail.com> Date: Sun, 29 Jan 2006 22:52:06 +0100 From: Erik Winge To: freebsd-current@freebsd.org In-Reply-To: <20060120172340.GA24889@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5213_25040169.1138571526420" References: <20060120172340.GA24889@troutmask.apl.washington.edu> Subject: Re: Stack backtrace for drm and malloc(M_WAITOK) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2006 22:17:05 -0000 ------=_Part_5213_25040169.1138571526420 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 1/20/06, Steve Kargl wrote: > With Jason's new malloc implementation, I had to install > xorg-server-snap to get a functioning x server on a amd64 > system. When the drm module is loaded, I'm see numerous > backtraces in /var/log/messages. > [...] > malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepab= le \ > locks held: > exclusive sleep mutex drmdma r =3D 0 (0xffffff02323b0130) locked @ \ > /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_bufs.c:846 I also get a bunch of messages almost like this one when starting X. I am running X.Org 6.9.0 on -current from January 28 (userland from Jan 26), and X is working well despite these warnings. See the attached /var/log/messages. Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r =3D 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Erik ------=_Part_5213_25040169.1138571526420 Content-Type: text/plain; name=messages.txt; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="messages.txt" Jan 29 22:18:33 anduin syslogd: kernel boot file is /boot/kernel/kernel Jan 29 22:18:33 anduin kernel: Copyright (c) 1992-2006 The FreeBSD Project. Jan 29 22:18:33 anduin kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 29 22:18:33 anduin kernel: The Regents of the University of California. All rights reserved. Jan 29 22:18:33 anduin kernel: FreeBSD 7.0-CURRENT #1: Sat Jan 28 20:48:10 CET 2006 Jan 29 22:18:33 anduin kernel: root@anduin:/usr/obj/usr/src/sys/ANDUIN Jan 29 22:18:33 anduin kernel: WARNING: WITNESS option enabled, expect reduced performance. Jan 29 22:18:33 anduin kernel: ACPI APIC Table: Jan 29 22:18:33 anduin kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 29 22:18:33 anduin kernel: CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.02-MHz 686-class CPU) Jan 29 22:18:33 anduin kernel: Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Jan 29 22:18:33 anduin kernel: Features=0xbfebfbff Jan 29 22:18:33 anduin kernel: Features2=0x441d> Jan 29 22:18:33 anduin kernel: Logical CPUs per core: 2 Jan 29 22:18:33 anduin kernel: real memory = 526934016 (502 MB) Jan 29 22:18:33 anduin kernel: avail memory = 510406656 (486 MB) Jan 29 22:18:33 anduin kernel: ioapic0: Changing APIC ID to 8 Jan 29 22:18:33 anduin kernel: ioapic0 irqs 0-23 on motherboard Jan 29 22:18:33 anduin kernel: lapic0: Forcing LINT1 to edge trigger Jan 29 22:18:33 anduin kernel: npx0: [FAST] Jan 29 22:18:33 anduin kernel: npx0: on motherboard Jan 29 22:18:33 anduin kernel: npx0: INT 16 interface Jan 29 22:18:33 anduin kernel: acpi0: on motherboard Jan 29 22:18:33 anduin kernel: acpi0: Power Button (fixed) Jan 29 22:18:33 anduin kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 Jan 29 22:18:33 anduin kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 29 22:18:33 anduin kernel: cpu0: on acpi0 Jan 29 22:18:33 anduin kernel: acpi_button0: on acpi0 Jan 29 22:18:33 anduin kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 29 22:18:33 anduin kernel: pci0: on pcib0 Jan 29 22:18:33 anduin kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 29 22:18:33 anduin kernel: pci1: on pcib1 Jan 29 22:18:33 anduin kernel: vgapci0: port 0xe898-0xe89f mem 0xdff00000-0xdff7ffff,0xc0000000-0xcfffffff,0xdfec0000-0xdfefffff irq 16 at device 2.0 on pci0 Jan 29 22:18:33 anduin kernel: agp0: on vgapci0 Jan 29 22:18:33 anduin kernel: agp0: detected 7932k stolen memory Jan 29 22:18:33 anduin kernel: agp0: aperture size is 256M Jan 29 22:18:33 anduin kernel: vgapci1: mem 0xdff80000-0xdfffffff at device 2.1 on pci0 Jan 29 22:18:33 anduin kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 29 22:18:33 anduin kernel: pci2: on pcib2 Jan 29 22:18:33 anduin kernel: pci2: at device 0.0 (no driver attached) Jan 29 22:18:33 anduin kernel: uhci0: port 0xff80-0xff9f irq 21 at device 29.0 on pci0 Jan 29 22:18:33 anduin kernel: uhci0: [GIANT-LOCKED] Jan 29 22:18:33 anduin kernel: usb0: on uhci0 Jan 29 22:18:33 anduin kernel: usb0: USB revision 1.0 Jan 29 22:18:33 anduin kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jan 29 22:18:33 anduin kernel: uhub0: 2 ports with 2 removable, self powered Jan 29 22:18:33 anduin kernel: uhci1: port 0xff60-0xff7f irq 22 at device 29.1 on pci0 Jan 29 22:18:33 anduin kernel: uhci1: [GIANT-LOCKED] Jan 29 22:18:33 anduin kernel: usb1: on uhci1 Jan 29 22:18:33 anduin kernel: usb1: USB revision 1.0 Jan 29 22:18:33 anduin kernel: uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jan 29 22:18:33 anduin kernel: uhub1: 2 ports with 2 removable, self powered Jan 29 22:18:33 anduin kernel: uhci2: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 Jan 29 22:18:33 anduin kernel: uhci2: [GIANT-LOCKED] Jan 29 22:18:33 anduin kernel: usb2: on uhci2 Jan 29 22:18:33 anduin kernel: usb2: USB revision 1.0 Jan 29 22:18:33 anduin kernel: uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jan 29 22:18:33 anduin kernel: uhub2: 2 ports with 2 removable, self powered Jan 29 22:18:33 anduin kernel: uhci3: port 0xff20-0xff3f irq 23 at device 29.3 on pci0 Jan 29 22:18:33 anduin kernel: uhci3: [GIANT-LOCKED] Jan 29 22:18:33 anduin kernel: usb3: on uhci3 Jan 29 22:18:33 anduin kernel: usb3: USB revision 1.0 Jan 29 22:18:33 anduin kernel: uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jan 29 22:18:33 anduin kernel: uhub3: 2 ports with 2 removable, self powered Jan 29 22:18:33 anduin kernel: ehci0: mem 0xffa80800-0xffa80bff irq 21 at device 29.7 on pci0 Jan 29 22:18:33 anduin kernel: ehci0: [GIANT-LOCKED] Jan 29 22:18:33 anduin kernel: usb4: EHCI version 1.0 Jan 29 22:18:33 anduin kernel: usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 Jan 29 22:18:33 anduin kernel: usb4: on ehci0 Jan 29 22:18:33 anduin kernel: usb4: USB revision 2.0 Jan 29 22:18:33 anduin kernel: uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 Jan 29 22:18:33 anduin kernel: uhub4: 8 ports with 8 removable, self powered Jan 29 22:18:33 anduin kernel: ural0: ASUS 802.11g WLAN Drive, rev 2.00/0.01, addr 2 Jan 29 22:18:33 anduin kernel: ural0: MAC/BBP RT2570 (rev 0x03), RF RT2526 Jan 29 22:18:33 anduin kernel: ural0: Ethernet address: 00:11:d8:b7:dd:17 Jan 29 22:18:33 anduin kernel: ural0: if_start running deferred for Giant Jan 29 22:18:33 anduin kernel: pcib3: at device 30.0 on pci0 Jan 29 22:18:33 anduin kernel: pci3: on pcib3 Jan 29 22:18:33 anduin kernel: pcm0: port 0xec00-0xecff,0xe8c0-0xe8ff mem 0xdfebfe00-0xdfebffff,0xdfebfd00-0xdfebfdff irq 23 at device 30.2 on pci0 Jan 29 22:18:33 anduin kernel: pcm0: Jan 29 22:18:33 anduin kernel: isab0: at device 31.0 on pci0 Jan 29 22:18:33 anduin kernel: isa0: on isab0 Jan 29 22:18:33 anduin kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf irq 16 at device 31.1 on pci0 Jan 29 22:18:33 anduin kernel: ata0: on atapci0 Jan 29 22:18:33 anduin kernel: ata1: on atapci0 Jan 29 22:18:33 anduin kernel: atapci1: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 20 at device 31.2 on pci0 Jan 29 22:18:33 anduin kernel: atapci1: failed to enable memory mapping! Jan 29 22:18:33 anduin kernel: ata2: on atapci1 Jan 29 22:18:33 anduin kernel: ata3: on atapci1 Jan 29 22:18:33 anduin kernel: pci0: at device 31.3 (no driver attached) Jan 29 22:18:33 anduin kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 29 22:18:33 anduin kernel: acpi_hpet0: Vendor: 0x8086 Jan 29 22:18:33 anduin kernel: acpi_hpet0: Leg_Route_Cap: 1 Jan 29 22:18:33 anduin kernel: acpi_hpet0: Count_Size_Cap: 1 Jan 29 22:18:33 anduin kernel: acpi_hpet0: Num_Tim_Cap: 1 Jan 29 22:18:33 anduin kernel: acpi_hpet0: Rev_id: 0x1 Jan 29 22:18:33 anduin kernel: acpi_hpet0: Period: 69841279 fs (14318180 Hz) Jan 29 22:18:33 anduin kernel: acpi_hpet0: HPET attach Jan 29 22:18:33 anduin kernel: pmtimer0 on isa0 Jan 29 22:18:33 anduin kernel: orm0: at iomem 0xc0000-0xca7ff,0xca800-0xcbfff,0xcc000-0xcd7ff,0xcd800-0xcffff pnpid ORM0000 on isa0 Jan 29 22:18:33 anduin kernel: sc0: at flags 0x100 on isa0 Jan 29 22:18:33 anduin kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 29 22:18:33 anduin kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 29 22:18:33 anduin kernel: ums0: Logitech Optical USB Mouse, rev 2.00/3.40, addr 2, iclass 3/1 Jan 29 22:18:33 anduin kernel: ums0: 3 buttons and Z dir. Jan 29 22:18:33 anduin kernel: ukbd0: DELL DELL USB Keyboard, rev 1.10/1.00, addr 2, iclass 3/1 Jan 29 22:18:33 anduin kernel: kbd0 at ukbd0 Jan 29 22:18:33 anduin kernel: uhid0: DELL DELL USB Keyboard, rev 1.10/1.00, addr 2, iclass 3/1 Jan 29 22:18:33 anduin kernel: Timecounter "TSC" frequency 2793015141 Hz quality 800 Jan 29 22:18:33 anduin kernel: Timecounters tick every 1.000 msec Jan 29 22:18:33 anduin kernel: acd0: DVDROM at ata0-master UDMA33 Jan 29 22:18:33 anduin kernel: ad4: 76293MB at ata2-master SATA150 Jan 29 22:18:33 anduin kernel: Trying to mount root from ufs:/dev/ad4s2a Jan 29 22:18:33 anduin kernel: WARNING: / was not properly dismounted Jan 29 22:18:33 anduin kernel: lock order reversal: (Giant after non-sleepable) Jan 29 22:18:33 anduin kernel: 1st 0xc06bf548 in_multi_mtx (in_multi_mtx) @ /usr/src/sys/netinet/in.c:971 Jan 29 22:18:33 anduin kernel: 2nd 0xc0673e48 Giant (Giant) @ /usr/src/sys/dev/usb/if_ural.c:1459 Jan 29 22:18:33 anduin kernel: KDB: stack backtrace: Jan 29 22:18:33 anduin kernel: witness_checkorder(c0673e48,9,c061a219,5b3,7cd) at witness_checkorder+0x67a Jan 29 22:18:33 anduin kernel: _mtx_lock_flags(c0673e48,0,c061a219,5b3,0) at _mtx_lock_flags+0x64 Jan 29 22:18:33 anduin kernel: ural_ioctl(c2f30000,80206931,0,7cd,c) at ural_ioctl+0x48 Jan 29 22:18:33 anduin kernel: if_addmulti(c2f30000,d5089aa4,d5089aa0,3cb,c30e23a0) at if_addmulti+0x177 Jan 29 22:18:33 anduin kernel: in_addmulti(d5089af8,c2f30000,1,8040691a,c30ef5bc) at in_addmulti+0x70 Jan 29 22:18:33 anduin kernel: in_ifinit(c3070090,0,0,0,d5089b48) at in_ifinit+0x635 Jan 29 22:18:33 anduin kernel: in_control(c30e914c,8040691a,c3070080,c2f30000,c2f511a0) at in_control+0xf25 Jan 29 22:18:33 anduin kernel: ifioctl(c30e914c,8040691a,c3070080,c2f511a0,2) at ifioctl+0x12d Jan 29 22:18:33 anduin kernel: soo_ioctl(c3084948,8040691a,c3070080,c2e40d00,c2f511a0) at soo_ioctl+0x2cb Jan 29 22:18:33 anduin kernel: ioctl(c2f511a0,d5089d04,c,444,3) at ioctl+0x118 Jan 29 22:18:33 anduin kernel: syscall(3b,3b,3b,8058500,0) at syscall+0x164 Jan 29 22:18:33 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:33 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28157123, esp = 0xbfbfe5bc, ebp = 0xbfbfee28 --- Jan 29 22:18:33 anduin savecore: no dumps found Jan 29 22:18:34 anduin anacron[454]: Anacron 2.3 started on 2006-01-29 Jan 29 22:18:34 anduin anacron[454]: Normal exit (0 jobs run) Jan 29 22:18:41 anduin login: 1 LOGIN FAILURE ON ttyv0 Jan 29 22:18:51 anduin kernel: t alloc_bounce_zone+0x27e Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,c0c4d780) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c3397ecc) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(c,c0654820,2,c2ef44b0,10) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_ctx_entry_add(c3397ecc,c33d11c0,2,f,c3397ecc) at sysctl_ctx_entry_add+0x3c Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639bb7,2) at sysctl_add_oid+0x168 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x27e Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "64", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0628083,26e) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d800,0,102,c0c4e880,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(2c,c0654820,102,f,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639bdb,80000002) at sysctl_add_oid+0x8f Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x2d3 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,2) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(e,c0654820,2,d,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639bdb,80000002) at sysctl_add_oid+0xd2 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x2d3 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "32", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c063a569,0) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d780,0,2,c0c4e800,c2ef4590) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(14,c0654820,2,d,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639bdb,2) at sysctl_add_oid+0x14b Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x2d3 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,c0c4d780) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c3397ecc) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(c,c0654820,2,c2ef4590,e) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_ctx_entry_add(c3397ecc,c33d1180,2,d,c3397ecc) at sysctl_ctx_entry_add+0x3c Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639bdb,2) at sysctl_add_oid+0x168 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x2d3 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "64", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0628083,26e) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d800,0,102,c0c4e880,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(2c,c0654820,102,d,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639bff,80000002) at sysctl_add_oid+0x8f Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x328 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,2) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(e,c0654820,2,d,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639bff,80000002) at sysctl_add_oid+0xd2 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x328 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "32", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c063a569,0) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d780,0,2,c0c4e800,c2eec790) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(16,c0654820,2,d,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639bff,2) at sysctl_add_oid+0x14b Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x328 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,c0c4d780) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c3397ecc) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(c,c0654820,2,c2eec790,e) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_ctx_entry_add(c3397ecc,c33d1140,2,d,c3397ecc) at sysctl_ctx_entry_add+0x3c Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639bff,2) at sysctl_add_oid+0x168 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x328 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "64", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0628083,26e) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d800,0,102,c0c4e880,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(2c,c0654820,102,d,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c36,80000002) at sysctl_add_oid+0x8f Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x37d Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,2) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(f,c0654820,2,e,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c36,80000002) at sysctl_add_oid+0xd2 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x37d Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "64", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0628083,0) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d800,0,2,c0c4e880,c2f97730) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(29,c0654820,2,e,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c36,2) at sysctl_add_oid+0x14b Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x37d Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,c0c4d800) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c3397ecc) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(c,c0654820,2,c2f97730,f) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_ctx_entry_add(c3397ecc,c33d1100,2,e,c3397ecc) at sysctl_ctx_entry_add+0x3c Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c36,2) at sysctl_add_oid+0x168 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x37d Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "64", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0628083,26e) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d800,0,102,c0c4e880,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(2c,c0654820,102,e,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c45,80000003) at sysctl_add_oid+0x8f Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x3d2 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,2) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(8,c0654820,2,7,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c45,80000003) at sysctl_add_oid+0xd2 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x3d2 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,0) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c2eecba0) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(1,c0654820,2,7,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c45,3) at sysctl_add_oid+0x14b Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x3d2 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,c0c4d700) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c3397ecc) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(c,c0654820,2,c2eecba0,8) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_ctx_entry_add(c3397ecc,c33d1080,2,7,c3397ecc) at sysctl_ctx_entry_add+0x3c Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c45,3) at sysctl_add_oid+0x168 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x3d2 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "64", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0628083,26e) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d800,0,102,c0c4e880,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(2c,c0654820,102,7,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c4d,80000002) at sysctl_add_oid+0x8f Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x427 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,2) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(a,c0654820,2,9,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c4d,80000002) at sysctl_add_oid+0xd2 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x427 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,0) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c2f976d0) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(1,c0654820,2,9,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c4d,2) at sysctl_add_oid+0x14b Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x427 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,c0c4d700) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c3397ecc) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(c,c0654820,2,c2f976d0,a) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_ctx_entry_add(c3397ecc,c33d1040,2,9,c3397ecc) at sysctl_ctx_entry_add+0x3c Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c0639c4d,2) at sysctl_add_oid+0x168 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x427 Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "64", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0628083,26e) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d800,0,102,c0c4e880,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(2c,c0654820,102,9,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c063c509,80000002) at sysctl_add_oid+0x8f Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x47c Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,2) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c2f09540) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(9,c0654820,2,8,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c063c509,80000002) at sysctl_add_oid+0xd2 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x47c Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,0) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c2ea3680) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(1,c0654820,2,8,c3397ecc) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c063c509,2) at sysctl_add_oid+0x14b Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x47c Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- Jan 29 22:18:51 anduin kernel: malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: Jan 29 22:18:51 anduin kernel: exclusive sleep mutex drm device r = 0 (0xc2edfcd4) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:904 Jan 29 22:18:51 anduin kernel: KDB: stack backtrace: Jan 29 22:18:51 anduin kernel: witness_warn(2,0,c06363ed,c0616e51,c0c4d700) at witness_warn+0x16d Jan 29 22:18:51 anduin kernel: uma_zalloc_arg(c0c4d700,0,2,c0c4e780,c3397ecc) at uma_zalloc_arg+0x203 Jan 29 22:18:51 anduin kernel: malloc(c,c0654820,2,c2ea3680,9) at malloc+0x8a Jan 29 22:18:51 anduin kernel: sysctl_ctx_entry_add(c3397ecc,c33d1000,2,8,c3397ecc) at sysctl_ctx_entry_add+0x3c Jan 29 22:18:51 anduin kernel: sysctl_add_oid(c3397ecc,c2f09540,ffffffff,c063c509,2) at sysctl_add_oid+0x168 Jan 29 22:18:51 anduin kernel: alloc_bounce_zone(44,c0651860,101,0,0) at alloc_bounce_zone+0x47c Jan 29 22:18:51 anduin kernel: bus_dma_tag_create(0,1000,0,ffffffff,ffffffff) at bus_dma_tag_create+0x176 Jan 29 22:18:51 anduin kernel: drm_pci_alloc(c2edfc00,1000,1000,ffffffff,c2edfcd4) at drm_pci_alloc+0xa8 Jan 29 22:18:51 anduin kernel: i915_dma_init(c339c100,80446440,c3397d80,3,c2f514e0) at i915_dma_init+0x35a Jan 29 22:18:51 anduin kernel: drm_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at drm_ioctl+0x1af Jan 29 22:18:51 anduin kernel: giant_ioctl(c339c100,80446440,c3397d80,3,c2f514e0) at giant_ioctl+0x56 Jan 29 22:18:51 anduin kernel: devfs_ioctl_f(c30851f8,80446440,c3397d80,c334d880,c2f514e0) at devfs_ioctl_f+0x66 Jan 29 22:18:51 anduin kernel: ioctl(c2f514e0,d508fd04,c,444,3) at ioctl+0x118 Jan 29 22:18:51 anduin kernel: syscall(3b,bfbf003b,bfbf003b,aeda9a0,aeda430) at syscall+0x164 Jan 29 22:18:51 anduin kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jan 29 22:18:51 anduin kernel: --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282e0123, esp = 0xbfbfea5c, ebp = 0xbfbfea78 --- ------=_Part_5213_25040169.1138571526420-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 22:52:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3342E16A420 for ; Sun, 29 Jan 2006 22:52:19 +0000 (GMT) (envelope-from Cy.Schubert@komquats.com) Received: from komquats.com (S0106002078125c0c.gv.shawcable.net [24.108.150.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id B394243D45 for ; Sun, 29 Jan 2006 22:52:14 +0000 (GMT) (envelope-from Cy.Schubert@komquats.com) Received: from cwsys.cwsent.com (cwsys [10.1.1.1]) by komquats.com (Postfix) with ESMTP id 0C2BB4C5C6 for ; Sun, 29 Jan 2006 14:52:12 -0800 (PST) Received: from cwsys (localhost [127.0.0.1]) by cwsys.cwsent.com (8.13.4/8.13.4) with ESMTP id k0TMqAGJ031333 for ; Sun, 29 Jan 2006 14:52:10 -0800 (PST) (envelope-from Cy.Schubert@komquats.com) Message-Id: <200601292252.k0TMqAGJ031333@cwsys.cwsent.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Jan 2006 14:52:10 -0800 Sender: Cy.Schubert@komquats.com Subject: 7.0-CURRENT Hang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 22:52:19 -0000 I'm experiencing the following hang on my -CURRENT testbed (which also serves as a 4.11, 5.4, and 6.0 testbed). Only under 7.0-CURRENT does it hang during boot using a stock out of the box GENERIC kernel. The machine is an old P120. Any ideas? OK include /boot/cwtest/foobar | cwtest.foobar loader file selected unload complete currdev set to disk2s1a: /boot/kernel/kernel text=0x4e15c4 data=0x84900+0xa026c syms=[0x4+0x67ea0+0x4+0x7f4ff] new kernel has been loaded OK boot -s GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2006 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 7.0-CURRENT #0: Fri Jan 27 13:49:18 PST 2006 root@cwsys:/export/obj/opt/src/cvs-current/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. At this point I need to reset the machine. Cheers, Cy Schubert Web: http://www.komquats.com and http://www.bcbodybuilder.com FreeBSD UNIX: Web: http://www.FreeBSD.org BC Government: "Lift long enough and I believe arrogance is replaced by humility and fear by courage and selfishness by generosity and rudeness by compassion and caring." -- Dave Draper From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 11:03:23 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 261D616A420; Mon, 30 Jan 2006 11:03:23 +0000 (GMT) (envelope-from smckay@internode.on.net) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id B96D543D62; Mon, 30 Jan 2006 11:03:15 +0000 (GMT) (envelope-from smckay@internode.on.net) Received: from dungeon.home (ppp117-204.lns1.bne3.internode.on.net [59.167.117.204]) by smtp3.adl2.internode.on.net (8.13.5/8.13.5) with ESMTP id k0UB36j1001441; Mon, 30 Jan 2006 21:33:07 +1030 (CST) (envelope-from smckay@internode.on.net) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.13.4/8.13.4) with ESMTP id k0UB2L0q006713; Mon, 30 Jan 2006 21:02:21 +1000 (EST) (envelope-from mckay) Message-Id: <200601301102.k0UB2L0q006713@dungeon.home> To: Robert Watson References: <20060126022854.GA16323@ci0.org> <20060126020818.K97024@fledge.watson.org> <200601281231.k0SCVhtc011525@dungeon.home> <20060128215112.W95776@fledge.watson.org> In-Reply-To: <20060128215112.W95776@fledge.watson.org> from Robert Watson at "Sat, 28 Jan 2006 21:52:34 +0000" Date: Mon, 30 Jan 2006 21:02:21 +1000 From: Stephen McKay Cc: current@freebsd.org, Stephen McKay Subject: Re: HEADS UP: pts code committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 11:03:23 -0000 On Saturday, 28th January 2006, Robert Watson wrote: >You are right, that is what it does. This is actually an intentional design >choice to match the behavior in Solaris, which also names them /dev/ptyp*. >Well, strictly speaking, those are just symlinks into /devices, but it comes >to much the same thing. You are probably right, though -- naming them >/dev/pty/* would make more sense, and won't affect the libc API. I had a quick look on a Solaris 8 machine and found only legacy pty devices in /dev. In /devices, they lump pts and pty nodes into /devices/pseudo with a lot of other stuff. Very messy. So I don't think the new FreeBSD /dev/ptynnn behaviour is the same as Solaris after all. I checked a Fedora Core 4 box too, and it doesn't put the pty's in /dev at all. At least in all implementations the important part (/dev/pts/nnn) is the same. Anyway, I can't find anything that depends on the naming for the master and it would make /dev tidier to bury pty's in a subdirectory. Shall we add that one missing '/'? The code would then match the comments. :-) Alternatively, the other implementations seem to get by without putting them in the tree at all. Do we need them? Stephen. From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 11:03:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFF3116A420 for ; Mon, 30 Jan 2006 11:03:23 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7518543D5F for ; Mon, 30 Jan 2006 11:03:18 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3WoX-00054m-L3 for freebsd-current@freebsd.org; Mon, 30 Jan 2006 11:03:17 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3Tu6-000Fiq-Lz for freebsd-current@freebsd.org; Sun, 29 Jan 2006 23:56:50 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17373.50882.270841.554876@roam.psg.com> Date: Sun, 29 Jan 2006 23:56:50 -0800 To: FreeBSD Current Subject: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 11:03:23 -0000 thinkpad with i386 very current, i am getting increasing swap consumption and xorg is the eater. eventually, it crashes. gnome is the desktop. all 557 ports current. anyone else seeing this? randy From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 11:50:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9593B16A420 for ; Mon, 30 Jan 2006 11:50:21 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4329F43D45 for ; Mon, 30 Jan 2006 11:50:21 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 52F4446BA8; Mon, 30 Jan 2006 06:50:13 -0500 (EST) Date: Mon, 30 Jan 2006 11:52:05 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Stephen McKay In-Reply-To: <200601301102.k0UB2L0q006713@dungeon.home> Message-ID: <20060130115009.B95776@fledge.watson.org> References: <20060126022854.GA16323@ci0.org> <20060126020818.K97024@fledge.watson.org> <200601281231.k0SCVhtc011525@dungeon.home> <20060128215112.W95776@fledge.watson.org> <200601301102.k0UB2L0q006713@dungeon.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: HEADS UP: pts code committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 11:50:21 -0000 On Mon, 30 Jan 2006, Stephen McKay wrote: > On Saturday, 28th January 2006, Robert Watson wrote: > >> You are right, that is what it does. This is actually an intentional design >> choice to match the behavior in Solaris, which also names them /dev/ptyp*. >> Well, strictly speaking, those are just symlinks into /devices, but it comes >> to much the same thing. You are probably right, though -- naming them >> /dev/pty/* would make more sense, and won't affect the libc API. > > I had a quick look on a Solaris 8 machine and found only legacy pty devices > in /dev. In /devices, they lump pts and pty nodes into /devices/pseudo with > a lot of other stuff. Very messy. So I don't think the new FreeBSD > /dev/ptynnn behaviour is the same as Solaris after all. I checked a Fedora > Core 4 box too, and it doesn't put the pty's in /dev at all. At least in > all implementations the important part (/dev/pts/nnn) is the same. > > Anyway, I can't find anything that depends on the naming for the master and > it would make /dev tidier to bury pty's in a subdirectory. Shall we add > that one missing '/'? The code would then match the comments. :-) Yes, we shuold -- I'll commit that today. > Alternatively, the other implementations seem to get by without putting them > in the tree at all. Do we need them? It has to do with a difference in how our devfs does device cloning -- whereas on some systems, your file descriptor reference to a device is silently replaced with the cloned device, so no name for it is needed, our implementation actually hooks the lookup to instantiate the device. It probably would be possible to allow a name never to be instantiated with this model, but it's not currently that way. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 12:12:59 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A287116A420 for ; Mon, 30 Jan 2006 12:12:59 +0000 (GMT) (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 D939A43D46 for ; Mon, 30 Jan 2006 12:12:56 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (fwnetw@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k0UCCnlq054150 for ; Mon, 30 Jan 2006 13:12:55 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k0UCCnu6054149; Mon, 30 Jan 2006 13:12:49 +0100 (CET) (envelope-from olli) Date: Mon, 30 Jan 2006 13:12:49 +0100 (CET) Message-Id: <200601301212.k0UCCnu6054149@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <20060129050435.A5945@xorpc.icir.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 30 Jan 2006 13:12:55 +0100 (CET) X-Mailman-Approved-At: Mon, 30 Jan 2006 12:23:45 +0000 Cc: Subject: Re: for review: sys/dev/md/md.c patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@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: Mon, 30 Jan 2006 12:12:59 -0000 Luigi Rizzo wrote: > just discovered, trying to resurrect picobsd on -current, > that the compiler in 6.x/7.x has become smart and, at least > with the default compilation flags, will optimize out > the "end_mfs_root" string from the object. Shouldn't it be sufficient to declare the string as volatile? That should prevent it from being optimized by the compiler. (I'm not questioning your solution, mind you. I just wonder if "volatile" would do the job. So far I've used volatile for things like sig_atomic_t only.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "When your hammer is C++, everything begins to look like a thumb." -- Steve Haflich, in comp.lang.c++ From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 12:54:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F05416A420 for ; Mon, 30 Jan 2006 12:54:48 +0000 (GMT) (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 4BA1C43D45 for ; Mon, 30 Jan 2006 12:54:48 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k0UCslPF021325 for ; Mon, 30 Jan 2006 04:54:47 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k0UCslI0021324 for freebsd-current@freebsd.org; Mon, 30 Jan 2006 04:54:47 -0800 (PST) (envelope-from rizzo) Date: Mon, 30 Jan 2006 04:54:47 -0800 From: Luigi Rizzo To: freebsd-current@freebsd.org Message-ID: <20060130045447.A20935@xorpc.icir.org> References: <20060129050435.A5945@xorpc.icir.org> <200601301212.k0UCCnu6054149@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200601301212.k0UCCnu6054149@lurza.secnetix.de>; from olli@lurza.secnetix.de on Mon, Jan 30, 2006 at 01:12:49PM +0100 Subject: Re: for review: sys/dev/md/md.c 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: Mon, 30 Jan 2006 12:54:48 -0000 On Mon, Jan 30, 2006 at 01:12:49PM +0100, Oliver Fromme wrote: > Luigi Rizzo wrote: > > just discovered, trying to resurrect picobsd on -current, > > that the compiler in 6.x/7.x has become smart and, at least > > with the default compilation flags, will optimize out > > the "end_mfs_root" string from the object. > > Shouldn't it be sufficient to declare the string as volatile? > That should prevent it from being optimized by the compiler. maybe. but packing both into the same struct also solves the issue of compiler potentially rearranging the variables in memory, and since we want them contiguous, the approach i suggested is probably more appropriate (with compilers becoming smarter and smarter, that is...) cheers luigi > (I'm not questioning your solution, mind you. I just wonder > if "volatile" would do the job. So far I've used volatile > for things like sig_atomic_t only.) > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing > Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd > Any opinions expressed in this message may be personal to the author > and may not necessarily reflect the opinions of secnetix in any way. > > "When your hammer is C++, everything begins to look like a thumb." > -- Steve Haflich, in comp.lang.c++ > _______________________________________________ > 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 Jan 30 13:30:05 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A862C16A420; Mon, 30 Jan 2006 13:30:05 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A98D43D55; Mon, 30 Jan 2006 13:30:01 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5F917.dip.t-dialin.net [84.165.249.23]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id k0UDKnD2070881; Mon, 30 Jan 2006 14:20:49 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id k0UDTtUE004478; Mon, 30 Jan 2006 14:29:55 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 30 Jan 2006 14:29:55 +0100 Message-ID: <20060130142955.fewnc3omossgoo0w@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 30 Jan 2006 14:29:55 +0100 From: Alexander Leidinger To: Stephen McKay References: <20060126022854.GA16323@ci0.org> <20060126020818.K97024@fledge.watson.org> <200601281231.k0SCVhtc011525@dungeon.home> <20060128215112.W95776@fledge.watson.org> <200601301102.k0UB2L0q006713@dungeon.home> In-Reply-To: <200601301102.k0UB2L0q006713@dungeon.home> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: Robert Watson , current@freebsd.org Subject: Re: HEADS UP: pts code committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 13:30:05 -0000 Stephen McKay wrote: > On Saturday, 28th January 2006, Robert Watson wrote: > >> You are right, that is what it does. This is actually an intentional design >> choice to match the behavior in Solaris, which also names them /dev/ptyp*. >> Well, strictly speaking, those are just symlinks into /devices, but it comes >> to much the same thing. You are probably right, though -- naming them >> /dev/pty/* would make more sense, and won't affect the libc API. > > I had a quick look on a Solaris 8 machine and found only legacy pty devices > in /dev. In /devices, they lump pts and pty nodes into /devices/pseudo > with a lot of other stuff. Very messy. So I don't think the new FreeBSD > /dev/ptynnn behaviour is the same as Solaris after all. % uname -a SunOS xantia 5.10 Generic_118844-27 i86pc i386 i86pc % ll /dev/pt* lrwxrwxrwx 1 root root 31 Sep 27 17:26 /dev/ptmajor -> ../devices/pseudo/ptm@0:ptmajor lrwxrwxrwx 1 root root 29 Sep 27 17:26 /dev/ptmx -> ../devices/pseudo/clone@0:ptm lrwxrwxrwx 1 root root 29 Sep 27 17:26 /dev/ptyp0 -> ../devices/pseudo/ptc@0:ptyp0 lrwxrwxrwx 1 root root 29 Sep 27 17:26 /dev/ptyp1 -> ../devices/pseudo/ptc@0:ptyp1 [...] lrwxrwxrwx 1 root root 29 Sep 27 17:28 /dev/ptyrd -> ../devices/pseudo/ptc@0:ptyrd lrwxrwxrwx 1 root root 29 Sep 27 17:28 /dev/ptyre -> ../devices/pseudo/ptc@0:ptyre lrwxrwxrwx 1 root root 29 Sep 27 17:28 /dev/ptyrf -> ../devices/pseudo/ptc@0:ptyrf /dev/pts/: total 270 drwxr-xr-x 2 root sys 2.0K Dec 7 09:51 ./ drwxr-xr-x 18 root sys 3.5K Jan 27 09:45 ../ lrwxrwxrwx 1 root root 28 Sep 27 17:26 0 -> ../../devices/pseudo/pts@0:0 lrwxrwxrwx 1 root root 28 Sep 27 17:26 1 -> ../../devices/pseudo/pts@0:1 lrwxrwxrwx 1 root root 29 Sep 27 17:28 10 -> ../../devices/pseudo/pts@0:10 lrwxrwxrwx 1 root root 30 Dec 7 09:51 100 -> ../../devices/pseudo/pts@0:100 [...] lrwxrwxrwx 1 root root 29 Dec 7 09:51 97 -> ../../devices/pseudo/pts@0:97 lrwxrwxrwx 1 root root 29 Dec 7 09:51 98 -> ../../devices/pseudo/pts@0:98 lrwxrwxrwx 1 root root 29 Dec 7 09:51 99 -> ../../devices/pseudo/pts@0:99 Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 "Kirk to Enterprise -- beam down yeoman Rand and a six-pack." From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 14:23:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CD3816A420 for ; Mon, 30 Jan 2006 14:23:20 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: from maritaca.epm.br (disrouter.epm.br [200.17.25.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DA2143D53 for ; Mon, 30 Jan 2006 14:23:19 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: from localhost (localhost.localdomain [127.0.0.1]) by maritaca.epm.br (Postfix) with ESMTP id BCED63A7B; Mon, 30 Jan 2006 12:23:16 -0200 (BRDT) Received: from [172.22.1.166] (ricardo.epm.br [172.22.1.166]) by maritaca.epm.br (Postfix) with ESMTP id 4AC303A76; Mon, 30 Jan 2006 12:23:10 -0200 (BRDT) Message-ID: <43DE2130.70203@yahoo.com.br> Date: Mon, 30 Jan 2006 12:22:40 -0200 From: "Ricardo A. Reis" User-Agent: Thunderbird 1.5 (X11/20060126) MIME-Version: 1.0 To: Randy Bush , current@freebsd.org References: <17373.50882.270841.554876@roam.psg.com> In-Reply-To: <17373.50882.270841.554876@roam.psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit UNIFESP-Virus-Scanned: by amavisd-new at dis.epm.br Cc: Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 14:23:20 -0000 Randy, The new malloc implementation still it is going to be perfected, in my station: Xorg increase +/- 40% Firefox increase +/- 60% Amule increase +/- 30% I not recompile this ports after world. Ricardo A. Reis UNIFESP Unix and Network Admin > thinkpad with i386 very current, i am getting increasing swap > consumption and xorg is the eater. eventually, it crashes. > > gnome is the desktop. all 557 ports current. > > anyone else seeing this? > > randy > > _______________________________________________ > 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 Jan 30 14:28:54 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFD9B16A426 for ; Mon, 30 Jan 2006 14:28:54 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8712243D4C for ; Mon, 30 Jan 2006 14:28:54 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3a1W-000A90-1C; Mon, 30 Jan 2006 14:28:54 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3a1V-0008co-BF; Mon, 30 Jan 2006 06:28:53 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17374.8868.815312.597508@roam.psg.com> Date: Mon, 30 Jan 2006 06:28:52 -0800 To: "Ricardo A. Reis" References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> Cc: current@freebsd.org Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 14:28:55 -0000 > The new malloc implementation still it is going to be perfected, > in my station: > > Xorg increase +/- 40% > Firefox increase +/- 60% > Amule increase +/- 30% > > I not recompile this ports after world. > > Ricardo A. Reis > UNIFESP > Unix and Network Admin let me be more clear. this is a leak, not an increase. if i leave the system untouched (and it's a laptop which runs no net services), memory use by xorg (shown by top) slowly goes from under 100m to 500m in four hours. and it keeps going until it starts to swap. and it keeps going until it crashes the system. and this is new with build and portupgrade of 2006.01.23, a week ago. randy From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 15:21:37 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D675016A420 for ; Mon, 30 Jan 2006 15:21:37 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: from maritaca.epm.br (disrouter.epm.br [200.17.25.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AFA543D49 for ; Mon, 30 Jan 2006 15:21:37 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: from localhost (localhost.localdomain [127.0.0.1]) by maritaca.epm.br (Postfix) with ESMTP id E13203A8D; Mon, 30 Jan 2006 13:21:35 -0200 (BRDT) Received: from [172.22.1.166] (ricardo.epm.br [172.22.1.166]) by maritaca.epm.br (Postfix) with ESMTP id E33AE3A77; Mon, 30 Jan 2006 13:21:30 -0200 (BRDT) Message-ID: <43DE2EDD.4010800@yahoo.com.br> Date: Mon, 30 Jan 2006 13:21:01 -0200 From: "Ricardo A. Reis" User-Agent: Thunderbird 1.5 (X11/20060126) MIME-Version: 1.0 To: Randy Bush References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> In-Reply-To: <17374.8868.815312.597508@roam.psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit UNIFESP-Virus-Scanned: by amavisd-new at dis.epm.br Cc: current@freebsd.org Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 15:21:38 -0000 Ok !! it is leak, In my house the station not crashes, but the increase of memory usage is visible for me, because my Station is a very old system (k6-2 500 with 192MB) i not update the packages. I use this machine for severals year, actually after the 4.5,5x.,6.x and now 7- CURRENT really consume more memory. For Firefox is more clear, before a update in last two week i use +/- 12 [tabs] now it is impossible. Ricardo A. Reis UNIFESP Unix and Network Admin >> The new malloc implementation still it is going to be perfected, >> in my station: >> >> Xorg increase +/- 40% >> Firefox increase +/- 60% >> Amule increase +/- 30% >> >> I not recompile this ports after world. >> >> Ricardo A. Reis >> UNIFESP >> Unix and Network Admin >> > > let me be more clear. this is a leak, not an increase. > > if i leave the system untouched (and it's a laptop which runs no > net services), memory use by xorg (shown by top) slowly goes from > under 100m to 500m in four hours. and it keeps going until it > starts to swap. and it keeps going until it crashes the system. > > and this is new with build and portupgrade of 2006.01.23, a week > ago. > > randy > > > From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 18:51:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DC0C16A420 for ; Mon, 30 Jan 2006 18:51:09 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0EF643D48 for ; Mon, 30 Jan 2006 18:50:58 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id k0UIoiHA010656; Mon, 30 Jan 2006 21:50:45 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id k0UIog2e010653; Mon, 30 Jan 2006 21:50:42 +0300 (MSK) (envelope-from yar) Date: Mon, 30 Jan 2006 21:50:41 +0300 From: Yar Tikhiy To: Gregory Nou Message-ID: <20060130185041.GF72743@comp.chem.msu.su> References: <43DA1672.1080609@altern.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43DA1672.1080609@altern.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: Question on IFF_PPROMISC (and IFF_PROMISC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 18:51:09 -0000 On Fri, Jan 27, 2006 at 01:47:46PM +0100, Gregory Nou wrote: > > I found a (somewhat old) post from gnn@ on this topic there : > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2004-09/0289.html > > I also think that it would be a good idea to do it (at least, it would > be easier to understand, because IFF_PPROMISC is not that explicit). If > nobody has already done it, I'll work on this. > > There is another point on which I would appreciate to know your opinion: > referring to if.c[1269], I understand that if IFF_PPROMISC is set in > ifp->if_flags, IFF_PROMISC should be set to (or we are in a transient > situation). > It appears that if_ethersubr.c[652] is working in this case. Isn't it a > mistake ? IMHO there's little point in changing the identifier's name. That will do more harm than good. The existing code looks correct to me. if_ethersubr.c:652 drops a frame not addressed to us only if IFF_PROMISC is set, but IFF_PPROMISC is not set. The point is that if IFF_PPROMISC is set, the frame will be passed up to IP or whatever anyway. -- Yar From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 19:54:18 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36FA216A420 for ; Mon, 30 Jan 2006 19:54:18 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAC0043D48 for ; Mon, 30 Jan 2006 19:54:17 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id C17F05E48EE; Mon, 30 Jan 2006 11:54:17 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 419155E48EC; Mon, 30 Jan 2006 11:54:17 -0800 (PST) In-Reply-To: <17374.8868.815312.597508@roam.psg.com> References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <984FE491-6C27-410D-A156-8B790699EBB7@freebsd.org> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Mon, 30 Jan 2006 11:54:15 -0800 To: Randy Bush X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: current@freebsd.org, "Ricardo A. Reis" Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 19:54:18 -0000 [Apologies for the duplicate email; mailman didn't let the mail through the first time, due to using the wrong From address.] On Jan 30, 2006, at 6:28 AM, Randy Bush wrote: >> The new malloc implementation still it is going to be perfected, >> in my station: >> >> Xorg increase +/- 40% >> Firefox increase +/- 60% >> Amule increase +/- 30% >> >> I not recompile this ports after world. >> >> Ricardo A. Reis >> UNIFESP >> Unix and Network Admin > > let me be more clear. this is a leak, not an increase. > > if i leave the system untouched (and it's a laptop which runs no > net services), memory use by xorg (shown by top) slowly goes from > under 100m to 500m in four hours. and it keeps going until it > starts to swap. and it keeps going until it crashes the system. > > and this is new with build and portupgrade of 2006.01.23, a week > ago. On 25 January, I checked in some malloc changes that fix some severe fragmentation problems. Can you please try with a newer libc, and see if the problem persists? Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 20:38:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23CB316A420 for ; Mon, 30 Jan 2006 20:38:14 +0000 (GMT) (envelope-from air.lightz@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AB3343D4C for ; Mon, 30 Jan 2006 20:38:13 +0000 (GMT) (envelope-from air.lightz@gmail.com) Received: by uproxy.gmail.com with SMTP id c2so21ugf for ; Mon, 30 Jan 2006 12:38:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=HpT0V/lPxcTMGmXmxlW0HVe3dP3LZr2MIpNGmwd/Q2LFo4LnguYuo0Ur+SGw2eFZAKnFEjlfSmJv64FiMHCqhYF5AI34PPIm1M/yyugJbRb7QyuUZS37rfv3ZK70Bh79p+LkVhQOkNuom8Ghl+gwh9o7JTcaz5Pg9W+cWuC6U7c= Received: by 10.49.34.11 with SMTP id m11mr861466nfj; Mon, 30 Jan 2006 11:32:36 -0800 (PST) Received: by 10.49.26.14 with HTTP; Mon, 30 Jan 2006 11:32:36 -0800 (PST) Message-ID: <1b62a7390601301132n48ccee95vdcb09a92e281b875@mail.gmail.com> Date: Mon, 30 Jan 2006 11:32:36 -0800 From: resonant evil To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: KDE 3.5 doesn't want to compile. karamba_python.cpp errors galore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 20:38:14 -0000 Hi everyone.. I just installed a minimal 7.0-CURRENT install and was recently compiling everything.. I successfully compiled xorg and what not, but now when I am trying to do a 'make install' in /usr/ports/x11/kde3, like 3 hours into the compilation process I'm getting a boatload of errors that are stopping me from continuing.. I sadly do not have a bloody clue how to fix it; I don't know Python or C.. So hopefully you pros can help me out :-) Here is the output that is stopping the show: gmake[3]: Entering directory `/usr/ports/misc/kdeutils3/work/kdeutils-3.5.0= /supe rkaramba/src' if c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/X11R6/in= clude -I/usr/local/include -I/usr/local/include/python2.4 -D_THREAD_SAFE -pth= read -DQT_THREAD_SUPPORT -I/usr/local/include -I/usr/local/include -I/usr/X11= R6/in clude -D_GETOPT_H -D_THREAD_SAFE -Wno-long-long -Wundef -Wall -W -Wpointe= r-ari th -DNDEBUG -DNO_DEBUG -O2 -O2 -fno-strict-aliasing -pipe -Wno-non-virtual-= dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASC= II_CA ST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT karamba_python.o -MD= -MP -MF ".deps/karamba_python.Tpo" -c -o karamba_python.o karamba_python.cpp; \ then mv -f ".deps/karamba_python.Tpo" ".deps/karamba_python.Po"; else rm -f= ".de ps/karamba_python.Tpo"; exit 1; fi karamba_python.cpp: In static member function `static void KarambaPython::i= nitPy thon()': karamba_python.cpp:370: error: `PyEval_InitThreads' undeclared (first use t= his f unction) karamba_python.cpp:370: error: (Each undeclared identifier is reported only= once for each function it appears in.) karamba_python.cpp:376: error: `PyEval_ReleaseLock' undeclared (first use t= his f unction) karamba_python.cpp: In static member function `static void KarambaPython::s= hutdo wnPython()': karamba_python.cpp:386: error: `PyEval_AcquireLock' undeclared (first use t= his f unction) karamba_python.cpp: In member function `void KarambaPython::getLock(PyThrea= dStat e**)': karamba_python.cpp:393: error: `PyEval_AcquireLock' undeclared (first use this function) karamba_python.cpp: In member function `void KarambaPython::releaseLock(PyT= hread State*)': karamba_python.cpp:409: error: `PyEval_ReleaseLock' undeclared (first use t= his f unction) gmake[3]: *** [karamba_python.o] Error 1 gmake[3]: Leaving directory `/usr/ports/misc/kdeutils3/work/kdeutils-3.5.0/= super karamba/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/misc/kdeutils3/work/kdeutils-3.5.0/superkaramba' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/misc/kdeutils3/work/kdeutils-3.5.0' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/misc/kdeutils3. *** Error code 1 Stop in /usr/ports/x11/kde3. bash-2.05b# *** SORRY if this looks or pasted like crap, I'm trying to manage through gmail here in bloody lynx from a console and do all my cutting and pasting as well. I always ask on #FreeBSD on irc.freenode.net before I visit the mailing lists for help, but all they can tell me in there is that the problem looks like "sloppy code" or "unrefined code" (Don't hold me to this! I know squat about coding!) They did all tell me though that this looks like a pretty serious problem and should be reported to the lists, so hopefully somebody here can give me some insight! I know compiling from scratch isn't always reccomended, and the easiest way is to install everything right at installtime, but I was on a very short schedule and have been having to do things in small sections each day, which is why I did the 'minimal' install and am just trying to choose what I want.. I also know that 7.0-CURRENT is considered unstable and isn't reccomended for usage, but I need to make use of multiple experimental Atheros patches for my 6th generation ath card that has NO native support yet. (I've already done an entire rebuild world process without problems) Hopefully somebody can help me with resolving this problem, I look forward to a response Thank you in advance everyone :) -Ryan From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 21:34:39 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6BAE16A420 for ; Mon, 30 Jan 2006 21:34:39 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 689F643D48 for ; Mon, 30 Jan 2006 21:34:39 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3gfW-000FiY-EN; Mon, 30 Jan 2006 21:34:38 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3gI6-0000gI-Ce; Mon, 30 Jan 2006 13:10:26 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17374.32961.768874.463443@roam.psg.com> Date: Mon, 30 Jan 2006 13:10:25 -0800 To: Jason Evans References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> Cc: current@freebsd.org, "Ricardo A. Reis" Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 21:34:40 -0000 >>> The new malloc implementation still it is going to be perfected, >>> in my station: >>> >>> Xorg increase +/- 40% >>> Firefox increase +/- 60% >>> Amule increase +/- 30% >>> >>> I not recompile this ports after world. >>> >>> Ricardo A. Reis >>> UNIFESP >>> Unix and Network Admin >> >> let me be more clear. this is a leak, not an increase. >> >> if i leave the system untouched (and it's a laptop which runs no >> net services), memory use by xorg (shown by top) slowly goes from >> under 100m to 500m in four hours. and it keeps going until it >> starts to swap. and it keeps going until it crashes the system. >> >> and this is new with build and portupgrade of 2006.01.23, a week >> ago. > > On 25 January, I checked in some malloc changes that fix some severe > fragmentation problems. Can you please try with a newer libc, and > see if the problem persists? sorry not to be sufficiently clear. i am updatin every two or three days, last was today. problem persists. randy From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 21:40:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 468CC16A420 for ; Mon, 30 Jan 2006 21:40:31 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7C1043D45 for ; Mon, 30 Jan 2006 21:40:29 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1054854wra for ; Mon, 30 Jan 2006 13:40:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=L40/QLUgrrmY5hNTm9snjfbVfQh+Po4tr4XGc53i2wP19OHPm6p0Dk2z6ntx37VcOC6sWNle/bz1hz0MfLJRLKgpr8gYR1qUoE4HLo8nSi49DDmQUhKwqSr7UrpoG+VFEd8Oy+K2IBowi91QP6wKtJGJ9m2nnTXEKHEgJx/i4SE= Received: by 10.65.119.5 with SMTP id w5mr1378647qbm; Mon, 30 Jan 2006 13:40:28 -0800 (PST) Received: by 10.65.112.6 with HTTP; Mon, 30 Jan 2006 13:40:28 -0800 (PST) Message-ID: Date: Tue, 31 Jan 2006 05:40:28 +0800 From: Jiawei Ye To: Randy Bush In-Reply-To: <17374.32961.768874.463443@roam.psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> Cc: "Ricardo A. Reis" , Jason Evans , current@freebsd.org Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 21:40:31 -0000 On 1/31/06, Randy Bush wrote: > sorry not to be sufficiently clear. i am updatin every two or > three days, last was today. problem persists. > > randy Same here. top shows: last pid: 1774; load averages: 0.00, 0.00, 0.00 up 0+03:12:39 05:3= 9:48 163 processes: 1 running, 162 sleeping CPU states: 1.2% user, 0.0% nice, 0.3% system, 0.6% interrupt, 97.9% id= le Mem: 101M Active, 277M Inact, 78M Wired, 1024K Cache, 60M Buf, 39M Free Swap: 512M Total, 512M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 1766 leafy 1 8 0 51580K 2460K wait 0:00 1.75% bash 229 root 1 96 0 51480K 2104K select 0:55 0.05% ppp 515 mysql 10 98 0 99M 24080K ucond 0:07 0.00% mysqld 789 vscan 1 20 0 93900K 41876K lockf 0:07 0.00% perl5.8.7 1342 leafy 1 96 0 54608K 5608K select 0:05 0.00% irssi 655 vscan 1 96 0 90348K 38660K select 0:02 0.00% perl5.8.7 479 root 1 96 0 59508K 9976K select 0:02 0.00% httpd 593 vscan 1 4 0 51192K 10676K accept 0:02 0.00% clamd 790 vscan 1 4 0 90756K 39132K select 0:01 0.00% perl5.8.7 640 leafy 1 96 0 54772K 3332K select 0:01 0.00% sshd 580 root 1 8 0 54004K 4848K nanslp 0:01 0.00% perl 543 root 1 96 0 51244K 1908K select 0:01 0.00% ntpd 892 bind 1 96 0 51104K 3752K select 0:01 0.00% named 251 _pflogd 1 -58 0 50332K 1268K bpf 0:01 0.00% pflogd 1323 leafy 1 96 0 50532K 1956K select 0:01 0.00% screen 614 pgsql 1 96 0 63164K 4396K select 0:00 0.00% postgres 786 root 1 96 0 50292K 1352K select 0:00 0.00% master 7.0-CURRENT FreeBSD 7.0-CURRENT #14: Tue Jan 31 01:28:26 CST 2006 -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 21:40:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07CB616A422 for ; Mon, 30 Jan 2006 21:40:40 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 945A943D45 for ; Mon, 30 Jan 2006 21:40:39 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 70D815E48ED; Mon, 30 Jan 2006 13:40:39 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id C0BB45E48CB; Mon, 30 Jan 2006 13:40:29 -0800 (PST) In-Reply-To: <17374.32961.768874.463443@roam.psg.com> References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Mon, 30 Jan 2006 13:40:27 -0800 To: Randy Bush X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: current@freebsd.org, "Ricardo A. Reis" Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 21:40:40 -0000 On Jan 30, 2006, at 1:10 PM, Randy Bush wrote: >>> and this is new with build and portupgrade of 2006.01.23, a week >>> ago. >> >> On 25 January, I checked in some malloc changes that fix some severe >> fragmentation problems. Can you please try with a newer libc, and >> see if the problem persists? > > sorry not to be sufficiently clear. i am updatin every two or > three days, last was today. problem persists. Okay, I'll look into this. It may take a bit of time though, since my development hardware is in a state of chaos at the moment. Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 21:42:27 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9DA216A420 for ; Mon, 30 Jan 2006 21:42:27 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5416243D49 for ; Mon, 30 Jan 2006 21:42:27 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 363B41A3C20; Mon, 30 Jan 2006 13:42:27 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6EC71511FC; Mon, 30 Jan 2006 16:42:26 -0500 (EST) Date: Mon, 30 Jan 2006 16:42:26 -0500 From: Kris Kennaway To: Jiawei Ye Message-ID: <20060130214226.GA68308@xor.obsecurity.org> References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Randy Bush , current@freebsd.org, Jason Evans , "Ricardo A. Reis" Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 21:42:27 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2006 at 05:40:28AM +0800, Jiawei Ye wrote: > On 1/31/06, Randy Bush wrote: > > sorry not to be sufficiently clear. i am updatin every two or > > three days, last was today. problem persists. > > > > randy > Same here. top shows: Sorry, what are you saying the problem is here? Kris > last pid: 1774; load averages: 0.00, 0.00, 0.00 up 0+03:12:39 05= :39:48 > 163 processes: 1 running, 162 sleeping > CPU states: 1.2% user, 0.0% nice, 0.3% system, 0.6% interrupt, 97.9% = idle > Mem: 101M Active, 277M Inact, 78M Wired, 1024K Cache, 60M Buf, 39M Free > Swap: 512M Total, 512M Free >=20 > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 1766 leafy 1 8 0 51580K 2460K wait 0:00 1.75% bash > 229 root 1 96 0 51480K 2104K select 0:55 0.05% ppp > 515 mysql 10 98 0 99M 24080K ucond 0:07 0.00% mysqld > 789 vscan 1 20 0 93900K 41876K lockf 0:07 0.00% perl5.8.7 > 1342 leafy 1 96 0 54608K 5608K select 0:05 0.00% irssi > 655 vscan 1 96 0 90348K 38660K select 0:02 0.00% perl5.8.7 > 479 root 1 96 0 59508K 9976K select 0:02 0.00% httpd > 593 vscan 1 4 0 51192K 10676K accept 0:02 0.00% clamd > 790 vscan 1 4 0 90756K 39132K select 0:01 0.00% perl5.8.7 > 640 leafy 1 96 0 54772K 3332K select 0:01 0.00% sshd > 580 root 1 8 0 54004K 4848K nanslp 0:01 0.00% perl > 543 root 1 96 0 51244K 1908K select 0:01 0.00% ntpd > 892 bind 1 96 0 51104K 3752K select 0:01 0.00% named > 251 _pflogd 1 -58 0 50332K 1268K bpf 0:01 0.00% pflogd > 1323 leafy 1 96 0 50532K 1956K select 0:01 0.00% screen > 614 pgsql 1 96 0 63164K 4396K select 0:00 0.00% postgres > 786 root 1 96 0 50292K 1352K select 0:00 0.00% master >=20 > 7.0-CURRENT FreeBSD 7.0-CURRENT #14: Tue Jan 31 01:28:26 CST 2006 >=20 > -- > "Without the userland, the kernel is useless." > --inspired by The Tao of Programming > _______________________________________________ > 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 --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD3ohCWry0BWjoQKURAkpyAJoDNXPh2sGaGVvdIwiU19A3xEF+kQCdE9SF TvM7bgb49z6msITqnGTx67E= =vNWJ -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 21:47:15 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56B9A16A420 for ; Mon, 30 Jan 2006 21:47:15 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0026D43D45 for ; Mon, 30 Jan 2006 21:47:08 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id k0ULkwjD026482 for ; Tue, 31 Jan 2006 00:46:59 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id k0ULkwlT026481 for current@freebsd.org; Tue, 31 Jan 2006 00:46:58 +0300 (MSK) (envelope-from yar) Date: Tue, 31 Jan 2006 00:46:57 +0300 From: Yar Tikhiy To: current@freebsd.org Message-ID: <20060130214657.GA16211@comp.chem.msu.su> References: <20060123183604.GB99678@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060123183604.GB99678@comp.chem.msu.su> User-Agent: Mutt/1.5.9i Cc: Subject: Re: panic: vm_page_free_toq: freeing mapped page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 21:47:15 -0000 On Mon, Jan 23, 2006 at 09:36:04PM +0300, Yar Tikhiy wrote: > > I'm afraid something got broken in BIO/VFS since January, 19. I'm > getting the following panic at system shutdown, after flushing > buffers, and then at fsck run. I have to load a Jan 19 kernel to > be able to run fsck. The panicing kernel, as well as userland, > were built last night. > > This trace is from an fsck-time panic. > > panic: vm_page_free_toq: freeing mapped page 0xc0db3920 > ... Now the panic is gone. I wish I knew who had fixed it to say thanks to them. -- Yar From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 21:49:45 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE47F16A420 for ; Mon, 30 Jan 2006 21:49:45 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4275543D48 for ; Mon, 30 Jan 2006 21:49:45 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3gu8-000G6T-8l; Mon, 30 Jan 2006 21:49:44 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3gu7-0000ln-PV; Mon, 30 Jan 2006 13:49:43 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17374.35319.265698.476631@roam.psg.com> Date: Mon, 30 Jan 2006 13:49:43 -0800 To: Kris Kennaway References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> Cc: current@freebsd.org Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 21:49:45 -0000 > Sorry, what are you saying the problem is here? maybe this will appeal more PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 2166 randy 4 20 0 166M 108M kserel 3:51 0.00% firefox-bin 1343 randy 1 96 0 126M 83500K select 2:44 2.00% Xorg 1394 randy 4 20 0 102M 51456K kserel 0:08 0.00% nautilus and the Xorg one just keeps growing and growing and growing. i am also suspicious of firefox, which grows as well. nautilus is a pig, bit stays the same size. it's the xorg which will eventually cause swap and then, as it fills swap, death. randy From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 21:54:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 035DD16A420 for ; Mon, 30 Jan 2006 21:54:10 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABB0C43D46 for ; Mon, 30 Jan 2006 21:54:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 950CC1A3C23; Mon, 30 Jan 2006 13:54:09 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CF36D51242; Mon, 30 Jan 2006 16:54:08 -0500 (EST) Date: Mon, 30 Jan 2006 16:54:08 -0500 From: Kris Kennaway To: Randy Bush Message-ID: <20060130215408.GA68492@xor.obsecurity.org> References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> 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: <17374.35319.265698.476631@roam.psg.com> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, Kris Kennaway Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 21:54:10 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 30, 2006 at 01:49:43PM -0800, Randy Bush wrote: > > Sorry, what are you saying the problem is here? >=20 > maybe this will appeal more >=20 > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 2166 randy 4 20 0 166M 108M kserel 3:51 0.00% firefox= -bin > 1343 randy 1 96 0 126M 83500K select 2:44 2.00% Xorg > 1394 randy 4 20 0 102M 51456K kserel 0:08 0.00% nautilus Those numbers don't really mean much unless you can show a comparison to something that you consider "good" (i.e. running under the old malloc). e.g. it's not hard to make firefox-bin use 108M of resident memory on *any* system. > and the Xorg one just keeps growing and growing and growing. That's a different matter though. Kris --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD3osAWry0BWjoQKURAs2JAKC7hAs7iJlJgmDZUJ9OIu6hs2xpggCgwOGr FjmeVgbLOj6VxjN/pf3NM58= =Z0J8 -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 22:05:11 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CA0916A44B for ; Mon, 30 Jan 2006 22:05:11 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B373543D45 for ; Mon, 30 Jan 2006 22:05:10 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3h94-000GUy-F8; Mon, 30 Jan 2006 22:05:10 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3h94-0000nP-2y; Mon, 30 Jan 2006 14:05:10 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17374.36245.570152.464206@roam.psg.com> Date: Mon, 30 Jan 2006 14:05:09 -0800 To: Kris Kennaway References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> Cc: current@freebsd.org Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 22:05:11 -0000 >> and the Xorg one just keeps growing and growing and growing. > That's a different matter though. and that's my point > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 2166 randy 4 20 0 166M 108M kserel 3:51 0.00% firefox-bin > 1343 randy 1 96 0 126M 83500K select 2:44 2.00% Xorg > 1394 randy 4 20 0 102M 51456K kserel 0:08 0.00% nautilus and now PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 2166 randy 4 20 0 166M 110M kserel 4:26 0.00% firefox-bin 1343 randy 1 96 0 142M 86032K select 3:14 2.39% Xorg 1394 randy 4 20 0 102M 51456K kserel 0:08 0.00% nautilus notice the growth in xorg and only xorg. and, from x's pov, all i have been doing is typing in an emacs window, thought there are 42 other windows open. and it will just keep growing if i walk away for a few hours. randy From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 22:47:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7659916A422 for ; Mon, 30 Jan 2006 22:47:51 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3698443D48 for ; Mon, 30 Jan 2006 22:47:49 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 24C361A3C2A; Mon, 30 Jan 2006 14:47:49 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6B1A952135; Mon, 30 Jan 2006 17:47:48 -0500 (EST) Date: Mon, 30 Jan 2006 17:47:48 -0500 From: Kris Kennaway To: Randy Bush Message-ID: <20060130224748.GA69789@xor.obsecurity.org> References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <17374.36245.570152.464206@roam.psg.com> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, Kris Kennaway Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 22:47:51 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 30, 2006 at 02:05:09PM -0800, Randy Bush wrote: > >> and the Xorg one just keeps growing and growing and growing. > > That's a different matter though. >=20 > and that's my point Yes, but then you and the other respondent also seemed to be claiming something else about the other processes. Let's focus on the concrete, which for now is the growth in Xorg memory use. > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMA= ND > > 2166 randy 4 20 0 166M 108M kserel 3:51 0.00% firef= ox-bin > > 1343 randy 1 96 0 126M 83500K select 2:44 2.00% Xorg > > 1394 randy 4 20 0 102M 51456K kserel 0:08 0.00% nauti= lus >=20 > and now >=20 > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 2166 randy 4 20 0 166M 110M kserel 4:26 0.00% firefox= -bin > 1343 randy 1 96 0 142M 86032K select 3:14 2.39% Xorg > 1394 randy 4 20 0 102M 51456K kserel 0:08 0.00% nautilus >=20 > notice the growth in xorg and only xorg. Kris --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD3peUWry0BWjoQKURAhWiAJ99oLAAF762Zw2PzrQd1B7g8/1eyACcCFcB cOmsobw6ILXD4fMDI/rv81k= =jPwo -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 22:55:37 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2E5C16A420 for ; Mon, 30 Jan 2006 22:55:37 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 584CB43D45 for ; Mon, 30 Jan 2006 22:55:36 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 6A980DE; Mon, 30 Jan 2006 16:55:36 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 9F13461C38; Mon, 30 Jan 2006 16:55:35 -0600 (CST) Date: Mon, 30 Jan 2006 16:55:35 -0600 From: "Matthew D. Fuller" To: Randy Bush Message-ID: <20060130225535.GO1388@over-yonder.net> References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17374.35319.265698.476631@roam.psg.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: current@freebsd.org, Kris Kennaway Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2006 22:55:37 -0000 On Mon, Jan 30, 2006 at 01:49:43PM -0800 I heard the voice of Randy Bush, and lo! it spake thus: > > and the Xorg one just keeps growing and growing and growing. This may not actually be new-malloc() related. I currently see: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1042 fullermd 1 96 0 266M 200M select 0 338:22 0.54% Xorg 1320 fullermd 5 20 10 253M 197M kserel 0 166:04 0.00% firefox-bi which are certainly larger than I recall them generally being. And this is a Jan 7 -CURRENT, before the malloc changes, still on Xorg 6.8.2. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 05:46:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A9A816A420; Tue, 31 Jan 2006 05:46:34 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5768143D45; Tue, 31 Jan 2006 05:46:33 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au (ppp208-69.lns1.adl2.internode.on.net [203.122.208.69]) by smtp3.adl2.internode.on.net (8.13.5/8.13.5) with ESMTP id k0V5kK93084707; Tue, 31 Jan 2006 16:16:28 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.dons.net.au (inchoate.dons.net.au [10.0.2.99]) (authenticated bits=0) by midget.dons.net.au (8.13.4/8.13.3) with ESMTP id k0V5kF0g093319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2006 16:16:17 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Kris Kennaway Date: Tue, 31 Jan 2006 16:16:09 +1030 User-Agent: KMail/1.9.1 References: <200601301652.16237.doconnor@gsoft.com.au> <20060130215554.GA68540@xor.obsecurity.org> <200601310914.39886.doconnor@gsoft.com.au> In-Reply-To: <200601310914.39886.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1168042.Loj1ExDysi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601311616.10870.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 10.0.2.7 Cc: freebsd-current@freebsd.org, Michael Nottebrock Subject: Re: KDE 3.5.0 seems much chubbier than 3.4.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 05:46:34 -0000 --nextPart1168042.Loj1ExDysi Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [ fixed CC ] On Tuesday 31 January 2006 09:14, Daniel O'Connor wrote: > On Tuesday 31 January 2006 08:25, Kris Kennaway wrote: > > > I did have a kernel from before the new malloc and it still seemed > > > quite sluggish. I remember being stuck because a commit to the AGP > > > driver on 20/12/05 prevented the nvidia driver building. > > > > new malloc =3D userland, not kernel. > > Yeah but I don't install world without first doing install kernel :) I think I was crack smoking here.. Recompiling the new libc with NO_MALLOC_EXTRAS reduced the memory usage=20 *significantly*. A make.conf knob would be highly appreciated here :) Here's a patch which seems to work here although my eyeballs almost explode= d=20 when reading the makefile so I don't know if it will have bad side-effects.. Index: lib/libc/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVS-Repository/src/lib/libc/Makefile,v retrieving revision 1.58 diff -u -r1.58 Makefile =2D-- lib/libc/Makefile 29 Dec 2005 04:10:52 -0000 1.58 +++ lib/libc/Makefile 31 Jan 2006 05:42:53 -0000 @@ -15,6 +15,9 @@ WARNS?=3D 2 CFLAGS+=3D-I${.CURDIR}/include -I${.CURDIR}/../../include CFLAGS+=3D-I${.CURDIR}/${MACHINE_ARCH} +.if defined(NO_MALLOC_EXTRAS) +CFLAGS+=3D-DNO_MALLOC_EXTRAS +.endif CLEANFILES+=3Dtags INSTALL_PIC_ARCHIVE=3D PRECIOUSLIB=3D =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1168042.Loj1ExDysi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD3vmi5ZPcIHs/zowRAqFvAKCC7Ji23ePN/Lc6WCpMF3Y/spOzBQCdHPK8 1pAWYXudHcTfbkJJvUBx8Jw= =pA7P -----END PGP SIGNATURE----- --nextPart1168042.Loj1ExDysi-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 06:00:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58BE016A420; Tue, 31 Jan 2006 06:00:43 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3B2D43D4C; Tue, 31 Jan 2006 06:00:42 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id C7A5F5E48ED; Mon, 30 Jan 2006 22:00:42 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id D4BC75E48DA; Mon, 30 Jan 2006 22:00:37 -0800 (PST) In-Reply-To: <200601311616.10870.doconnor@gsoft.com.au> References: <200601301652.16237.doconnor@gsoft.com.au> <20060130215554.GA68540@xor.obsecurity.org> <200601310914.39886.doconnor@gsoft.com.au> <200601311616.10870.doconnor@gsoft.com.au> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1713BECB-9E36-4D12-A063-46AB2EC0AB2F@freebsd.org> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Mon, 30 Jan 2006 22:00:35 -0800 To: Daniel O'Connor X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org, Michael Nottebrock , Kris Kennaway Subject: Re: KDE 3.5.0 seems much chubbier than 3.4.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 06:00:43 -0000 [Apologies for the duplicate emails.] On Jan 30, 2006, at 9:46 PM, Daniel O'Connor wrote: > [ fixed CC ] > On Tuesday 31 January 2006 09:14, Daniel O'Connor wrote: >> On Tuesday 31 January 2006 08:25, Kris Kennaway wrote: >>>> I did have a kernel from before the new malloc and it still seemed >>>> quite sluggish. I remember being stuck because a commit to the AGP >>>> driver on 20/12/05 prevented the nvidia driver building. >>> >>> new malloc = userland, not kernel. >> >> Yeah but I don't install world without first doing install kernel :) > > I think I was crack smoking here.. > Recompiling the new libc with NO_MALLOC_EXTRAS reduced the memory > usage > *significantly*. Yes, I'd expect the memory usage to decrease if you build with NO_MALLOC_EXTRAS, since redzone overhead is 32 bytes per object. Do you see any evidence of unbounded X memory usage though? > A make.conf knob would be highly appreciated here :) Why not just append to CFLAGS in make.conf? NO_MALLOC_EXTRAS is a development-only flag, since the malloc debug features will be disabled for releases, so a make.conf knob would have no relevance to releases. Unless there's serious worry about cpp namespace pollution, I don't understand the need for the patch you provided. Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 06:37:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 863E916A420 for ; Tue, 31 Jan 2006 06:37:36 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D8BD43D49 for ; Tue, 31 Jan 2006 06:37:36 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3p8x-000NEO-Hi; Tue, 31 Jan 2006 06:37:35 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3p8w-0003KD-Gf; Mon, 30 Jan 2006 22:37:34 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17375.1454.11511.502872@roam.psg.com> Date: Mon, 30 Jan 2006 22:37:34 -0800 To: Eric Anholt References: <17373.50882.270841.554876@roam.psg.com> <43DECB94.50307@lclark.edu> Cc: FreeBSD Current Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 06:37:36 -0000 > Note that any app leaking pixmaps or other X resources will > have those resources charged to X, not the app. xrestop can > find offenders usually if it's some app's fault. so it's firefox. thanks. randy From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 07:17:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D77C16A420 for ; Tue, 31 Jan 2006 07:17:17 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37E2843D49 for ; Tue, 31 Jan 2006 07:17:17 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k0V7H1ZC024387; Tue, 31 Jan 2006 00:17:01 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 31 Jan 2006 00:17:12 -0700 (MST) Message-Id: <20060131.001712.99374123.imp@bsdimp.com> To: freebsd-current@freebsd.org, olli@lurza.secnetix.de From: "M. Warner Losh" In-Reply-To: <200601301212.k0UCCnu6054149@lurza.secnetix.de> References: <20060129050435.A5945@xorpc.icir.org> <200601301212.k0UCCnu6054149@lurza.secnetix.de> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 31 Jan 2006 00:17:02 -0700 (MST) Cc: Subject: Re: for review: sys/dev/md/md.c 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: Tue, 31 Jan 2006 07:17:17 -0000 In message: <200601301212.k0UCCnu6054149@lurza.secnetix.de> Oliver Fromme writes: : Luigi Rizzo wrote: : > just discovered, trying to resurrect picobsd on -current, : > that the compiler in 6.x/7.x has become smart and, at least : > with the default compilation flags, will optimize out : > the "end_mfs_root" string from the object. : : Shouldn't it be sufficient to declare the string as volatile? : That should prevent it from being optimized by the compiler. I know that for the arm board I'm working on, MFS works great. The proposed patch looks interesting, but I'm not sure why it is necessary. I think removing the 'static' would be sufficient... Warner From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 07:35:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 648EB16A420; Tue, 31 Jan 2006 07:35:27 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id A74FE43D4C; Tue, 31 Jan 2006 07:35:24 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au (ppp208-69.lns1.adl2.internode.on.net [203.122.208.69]) by smtp1.adl2.internode.on.net (8.13.5/8.13.5) with ESMTP id k0V7ZBmm093138; Tue, 31 Jan 2006 18:05:19 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.dons.net.au (inchoate.dons.net.au [10.0.2.99]) (authenticated bits=0) by midget.dons.net.au (8.13.4/8.13.3) with ESMTP id k0V7ZAUr093986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2006 18:05:11 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Jason Evans Date: Tue, 31 Jan 2006 18:04:59 +1030 User-Agent: KMail/1.9.1 References: <200601301652.16237.doconnor@gsoft.com.au> <200601311616.10870.doconnor@gsoft.com.au> <1713BECB-9E36-4D12-A063-46AB2EC0AB2F@freebsd.org> In-Reply-To: <1713BECB-9E36-4D12-A063-46AB2EC0AB2F@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5058637.oaHvhcfK8N"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601311805.07556.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 10.0.2.7 Cc: freebsd-current@freebsd.org, Michael Nottebrock , Kris Kennaway Subject: Re: KDE 3.5.0 seems much chubbier than 3.4.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 07:35:27 -0000 --nextPart5058637.oaHvhcfK8N Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > Yes, I'd expect the memory usage to decrease if you build with > NO_MALLOC_EXTRAS, since redzone overhead is 32 bytes per object. Do > you see any evidence of unbounded X memory usage though? Hmm, not sure it was unbounded, but it was certainly consuming a lot of ext= ra=20 memory. Note that with the debugging off top shows it as.. PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 19876 root 1 100 0 315M 136M select 18:16 13.67% Xorg so it's hardly small. > Why not just append to CFLAGS in make.conf? NO_MALLOC_EXTRAS is a > development-only flag, since the malloc debug features will be > disabled for releases, so a make.conf knob would have no relevance to > releases. Unless there's serious worry about cpp namespace > pollution, I don't understand the need for the patch you provided. Hmm, I thought touching CFLAGS in make.conf was verboten.. If not then I will use it. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart5058637.oaHvhcfK8N Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD3xMr5ZPcIHs/zowRAmaOAKCTBgFiDqURbmAcIkuSEh+Js3UalwCfRNBt ODfPidnX8EycLkrRjBO/Alo= =gwtJ -----END PGP SIGNATURE----- --nextPart5058637.oaHvhcfK8N-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 08:14:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D560F16A420 for ; Tue, 31 Jan 2006 08:14:56 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5598A43D4C for ; Tue, 31 Jan 2006 08:14:53 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-06-z2.arcor-online.net (mail-in-06-z2.arcor-online.net [151.189.8.18]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id 1D0831979BC; Tue, 31 Jan 2006 09:14:52 +0100 (CET) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-06-z2.arcor-online.net (Postfix) with ESMTP id 0D67F194B8E; Tue, 31 Jan 2006 09:14:52 +0100 (CET) Received: from lofi.dyndns.org (dslb-084-061-156-194.pools.arcor-ip.net [84.61.156.194]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id BC8B110CD0E; Tue, 31 Jan 2006 09:14:51 +0100 (CET) Received: from [192.168.8.4] (kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.13.4/8.13.3) with ESMTP id k0V8EmVt078778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2006 09:14:49 +0100 (CET) (envelope-from lofi@freebsd.org) Message-ID: <43DF1C73.8080902@freebsd.org> Date: Tue, 31 Jan 2006 09:14:43 +0100 From: Michael Nottebrock User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: resonant evil References: <1b62a7390601301132n48ccee95vdcb09a92e281b875@mail.gmail.com> In-Reply-To: <1b62a7390601301132n48ccee95vdcb09a92e281b875@mail.gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF27E925E512591C62AA43A9D" X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org Subject: Re: KDE 3.5 doesn't want to compile. karamba_python.cpp errors galore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 08:14:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF27E925E512591C62AA43A9D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable resonant evil wrote: > karamba_python.cpp:370: error: `PyEval_InitThreads' undeclared (first u= se this f > unction) > karamba_python.cpp:370: error: (Each undeclared identifier is reported = only once > for each function it appears in.) > karamba_python.cpp:376: error: `PyEval_ReleaseLock' undeclared (first u= se this f > unction) > karamba_python.cpp: In static member function `static void KarambaPytho= n::shutdo > wnPython()': > karamba_python.cpp:386: error: `PyEval_AcquireLock' undeclared (first u= se this f > unction) > karamba_python.cpp: In member function `void KarambaPython::getLock(PyT= hreadStat > e**)': > karamba_python.cpp:393: error: `PyEval_AcquireLock' undeclared (first > use this function) > karamba_python.cpp: In member function `void KarambaPython::releaseLock= (PyThread > State*)': > karamba_python.cpp:409: error: `PyEval_ReleaseLock' undeclared (first u= se this f > unction) Make sure to turn threads support on in python (cd /usr/ports/lang/python; make config, select the THREADS option) and reinstall it. Cheers, --=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --------------enigF27E925E512591C62AA43A9D 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.3-nr1 (Windows 2000) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD3xx1Xhc68WspdLARAgU6AJ9XrRhANQaaOp8lyntNwVTtMXYWbwCgqamS zbTh1JW2zWXM1l+XetlvUvw= =MvM2 -----END PGP SIGNATURE----- --------------enigF27E925E512591C62AA43A9D-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 09:29:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4CF116A423 for ; Tue, 31 Jan 2006 09:29:23 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EA2643D4C for ; Tue, 31 Jan 2006 09:29:18 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5F158.dip.t-dialin.net [84.165.241.88]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id k0V9Jw8R079968; Tue, 31 Jan 2006 10:19:59 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id k0V9TEoA024604; Tue, 31 Jan 2006 10:29:14 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Tue, 31 Jan 2006 10:29:14 +0100 Message-ID: <20060131102914.660ukp2ko4wgogoc@netchild.homeip.net> X-Priority: 3 (Normal) Date: Tue, 31 Jan 2006 10:29:14 +0100 From: Alexander Leidinger To: Randy Bush References: <17373.50882.270841.554876@roam.psg.com> <43DECB94.50307@lclark.edu> <17375.1454.11511.502872@roam.psg.com> In-Reply-To: <17375.1454.11511.502872@roam.psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: Eric Anholt , FreeBSD Current Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 09:29:23 -0000 Randy Bush wrote: >> Note that any app leaking pixmaps or other X resources will >> have those resources charged to X, not the app. xrestop can >> find offenders usually if it's some app's fault. > > so it's firefox. thanks. I can confirm that I see something like this too. At work on Solaris 10 with Firefox 1.5 I notice a sudden death of firefox when I let BigBrother refresh itself for a while (X.org and firefox will grow both, and firefox will die before X has a size where the OS may want to kill it). So it's not the new X.org or FreeBSD. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 I believe in getting into hot water; it keeps you clean. -- G.K. Chesterton From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 11:11:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A4F416A420; Tue, 31 Jan 2006 11:11:22 +0000 (GMT) (envelope-from smckay@internode.on.net) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6F8643D53; Tue, 31 Jan 2006 11:11:21 +0000 (GMT) (envelope-from smckay@internode.on.net) Received: from dungeon.home (ppp117-204.lns1.bne3.internode.on.net [59.167.117.204]) by smtp1.adl2.internode.on.net (8.13.5/8.13.5) with ESMTP id k0VBBIeZ062570; Tue, 31 Jan 2006 21:41:19 +1030 (CST) (envelope-from smckay@internode.on.net) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.13.4/8.13.4) with ESMTP id k0VBAUYX008920; Tue, 31 Jan 2006 21:10:30 +1000 (EST) (envelope-from mckay) Message-Id: <200601311110.k0VBAUYX008920@dungeon.home> To: Alexander Leidinger References: <20060126022854.GA16323@ci0.org> <20060126020818.K97024@fledge.watson.org> <200601281231.k0SCVhtc011525@dungeon.home> <20060128215112.W95776@fledge.watson.org> <200601301102.k0UB2L0q006713@dungeon.home> <20060130142955.fewnc3omossgoo0w@netchild.homeip.net> In-Reply-To: <20060130142955.fewnc3omossgoo0w@netchild.homeip.net> from Alexander Leidinger at "Mon, 30 Jan 2006 14:29:55 +0100" Date: Tue, 31 Jan 2006 21:10:30 +1000 From: Stephen McKay Cc: Robert Watson , current@freebsd.org, Stephen McKay Subject: Re: HEADS UP: pts code committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 11:11:22 -0000 On Monday, 30th January 2006, Alexander Leidinger wrote: >Stephen McKay wrote: > >> I had a quick look on a Solaris 8 machine and found only legacy pty devices >> in /dev. In /devices, they lump pts and pty nodes into /devices/pseudo >> with a lot of other stuff. Very messy. So I don't think the new FreeBSD >> /dev/ptynnn behaviour is the same as Solaris after all. > >% uname -a >SunOS xantia 5.10 Generic_118844-27 i86pc i386 i86pc > >% ll /dev/pt* >lrwxrwxrwx 1 root root 31 Sep 27 17:26 /dev/ptmajor -> >../devices/pseudo/ptm@0:ptmajor >lrwxrwxrwx 1 root root 29 Sep 27 17:26 /dev/ptmx -> >../devices/pseudo/clone@0:ptm >lrwxrwxrwx 1 root root 29 Sep 27 17:26 /dev/ptyp0 -> >../devices/pseudo/ptc@0:ptyp0 >lrwxrwxrwx 1 root root 29 Sep 27 17:26 /dev/ptyp1 -> >../devices/pseudo/ptc@0:ptyp1 > >[...] > >lrwxrwxrwx 1 root root 29 Sep 27 17:28 /dev/ptyrd -> >../devices/pseudo/ptc@0:ptyrd >lrwxrwxrwx 1 root root 29 Sep 27 17:28 /dev/ptyre -> >../devices/pseudo/ptc@0:ptyre >lrwxrwxrwx 1 root root 29 Sep 27 17:28 /dev/ptyrf -> >../devices/pseudo/ptc@0:ptyrf These look like legacy names to me (ptyp0, ptyrd, etc). I only have access to a Solaris 8 machine, but from memory it looks the same as your Solaris 10 machine. Anyway, it's not terribly important whether or not Solaris is the same as FreeBSD for the master devices. The important part (/dev/pts/nnn) is the same everywhere. Stephen. PS I just checked and the commit is in already. I suppose the discussion is done now. :-) From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 14:18:15 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B5BA16A420 for ; Tue, 31 Jan 2006 14:18:15 +0000 (GMT) (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 10EED43D45 for ; Tue, 31 Jan 2006 14:18:14 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k0VEIDr2053393; Tue, 31 Jan 2006 06:18:13 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k0VEIDTS053392; Tue, 31 Jan 2006 06:18:13 -0800 (PST) (envelope-from rizzo) Date: Tue, 31 Jan 2006 06:18:12 -0800 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20060131061812.A53329@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: boot block differences between 4.x and 6.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, 31 Jan 2006 14:18:15 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline maybe some of you know the answer here... the revised picobsd script (attached here, it uses sysutils/makefs instead of vnconfig/mdconfig so it can run as a non privileged user) that i was using to create images with the 4.11 boot blocks (boot1 and boot2), does not seem to work anymore with the boot blocks taken from 6.0 (and so, -current as well). When i force it to use the 4.x boot blocks, all is fine, and the picobsd.bin produced (built on 6.0 using 7-current sources) boots fine on qemu. I am a bit puzzled on what could be the relevant change in boot1/boot2 could have caused the loss of functionality. If that matters, picobsd bypasses /boot/loader and goes straight to boot /kernel (the name is patched into the boot block, but it does not matter because the new blocks do not even get to the point of showing the 'missing /boot/loader' error message). does anyone know where should i look at ? thanks luigi --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=picobsd-20060131 Content-Transfer-Encoding: quoted-printable #!/bin/sh - # # $FreeBSD$ # This file requires sysutils/makefs to run # # The new PicoBSD build script. Invoked as # # picobsd [options] floppy_type site_name # # Where floppy_type is a directory where the picobsd config info # is held, and ${floppy_type}/floppy.tree.${site_name} contains # optional site-specific configuration. # # For Options, see the bottom of the file where the processing is # done. The picobsd(8) manpage might be of some help, but code and docs # tend to lose sync over time... # # This script depends on the following files: # # in ${PICO_TREE} : # Makefile.conf Makefile used to build the kernel # config shell variables, sourced here. # mfs.mtree mtree config file # # floppy.tree/ files which go on the floppy # mfs_tree/ files which go onto the mfs # # in ${MY_TREE} : # PICOBSD kernel config file # config shell variables, sourced here. # crunch.conf crunchgen configuration # floppy.tree.exclude files from floppy.tree/ which we do not need here. # floppy.tree/ local additions to the floppy.tree # floppy.tree.${site}/ same as above, site specific. # mfs_tree/ local additions to the mfs_free # #--- The main entry point is at the end. # # There are two set of initialization. The first one (set_defaults) # is done on entry to the script, and is used to set default values # for all variables which do not depend on floppy type and source tree. # # The second set is done after command line parsing, e.g. # to resolve dependencies on the source tree. # # Naming: # + variables that control operation (e.g. verbosity) and are generally # set from the command line have o_ ("option") as a name prefix # # + variables which contain pathnames and values that should not change # have c_ ("constant") as a name prefix # # + variables exported to Makefiles and subshells are CAPITAL # # + variables local to the script are lowercase, possibly with # an l_ ("local") prefix # SRC points to your FreeBSD source tree. # l_usrtree points to the /usr subdir for the source tree. # Normally /usr or ${SRC}/../usr # l_objtree points to the obj tree. Normally ${l_usrtree}/obj-pico # PICO_TREE is where standard picobsd stuff resides. # Normally ${SRC}/release/picobsd # You can set SRC with --src # It is not recommended to override the other variables. # MY_TREE (set later) is where this floppy type resides. # BUILDDIR is the build directory # set some default values for variables. # needs to be done as the first thing in the script. # log something on stdout if verbose. o_verbose=3D0 # this needs to be here! log() { if [ ${o_verbose} -gt 0 ] ; then printf "\n*** %s\n" "$*" if [ ${o_verbose} -gt 1 ] ; then read -p "=3D=3D=3D Press enter to continue" foo fi fi } logverbose() { local foo printf "\n*** %s\n" "$*" read -p "=3D=3D=3D Press enter to continue" foo } set_defaults() { # no way to use logging in this function, variable not set yet. # EDITOR is the editor you use # fd_size floppy size in KB (default to 1440). You can use 1480, # 1720, 2880, etc. but beware that only 1440 and 1480 will boot # from 1.44M floppy drives (1480 will not work on vmware). EDITOR=3D${EDITOR:-vi} fd_size=3D${fd_size:-1440} o_all_in_mfs=3D"yes" # put all files in mfs so you can boot and run # the image via diskless boot. o_clean=3D"" # do not clean o_interactive=3D"" # default is interactive o_verbose=3D0 # verbose level, 0 is silent o_tarv=3D"" # tar verbose flag, "" or "v" o_init_src=3D"" # non "" if we need to init libs and includes. o_makeopts=3D${MAKEOPTS:--s} # make options, be silent by default o_no_devfs=3Dyes # we do not want devfs o_do_modules=3D"" # do not build modules SRC=3D"/usr/src" # default location for sources c_startdir=3D`pwd` # directory where we start # used to lookup config and create BUILDDIR c_boot1=3D/boot/boot1 # boot blocks (in case you want custom ones) c_boot2=3D/boot/boot2 # c_boot1=3D/boot/boot1.4_11 # c_boot2=3D/boot/boot2.4_11 c_reply=3D${c_reply:-`mktemp "/tmp/reply.XXXXXXXXXX"`} # file where User replies will be put c_mnt=3D`mktemp -d "/tmp/picobsd.XXXXXXXXXX"` # mountpoint used to build memory filesystems c_fs=3Dfs.PICOBSD # filename used for the memory filesystem c_img=3Dpicobsd.bin # filename used for the picobsd image # select the right memory disk name case `uname -r` in 7.*|6.*|5.*) l_label=3D"bsdlabel" ;; *) l_label=3D"disklabel" ;; esac set -e trap fail 2 #trap fail 3 #trap fail 6 trap fail 15 } create_includes_and_libraries2() { local no log "create_includes_and_libraries2() for ${SRC}" if [ ${OSVERSION} -ge 600000 ] ; then no=3D"-DNO_CLEAN -DNO_PROFILE -DNO_GAMES -DNO_LIBC_R" else no=3D"-DNOCLEAN -DNOPROFILE -DNOGAMES -DNOLIBC_R" fi MAKEOBJDIRPREFIX=3D${l_objtree} export MAKEOBJDIRPREFIX ( cd ${SRC}; # make -DNOCLEAN -DNOPROFILE -DNOGAMES -DNOLIBC_R -DPICOBSD buildworld make _+_=3D $no toolchain ) } create_includes_and_libraries() { local e i log "create_includes_and_libraries() for ${SRC}" # Optionally creates include directory and libraries. mkdir -p ${l_usrtree}/include # the include directory... mkdir -p ${l_usrtree}/share/misc # a few things go here mkdir -p ${l_usrtree}/lib # libraries mkdir -p ${l_usrtree}/sbin # some binaries # override variables for ownershiip and destinations # BINOWN:BINGRP are also used for include files (cd ${SRC}; \ BINOWN=3D`id -un` BINGRP=3D`id -gn` \ DESTDIR=3D${l_usrtree}/.. \ make -m ${SRC}/share/mk includes ) || fail $? includes # Pick up the correct headers for libraries. CFLAGS=3D"-nostdinc -I${l_usrtree}/include" ; export CFLAGS (cd ${SRC} # $e is the invocation of make with correct environment e=3D"MAKEOBJDIRPREFIX=3D${l_objtree}/picobsd/libraries \ BINOWN=3D`id -un` BINGRP=3D`id -gn` \ DESTDIR=3D${l_usrtree}/.. \ make -m ${SRC}/share/mk \ -DNOHTML -DNOINFO -DNOMAN -DNOSHARE -DNOFSCHG " log "do a 'make obj' in a few places." # This is very version-specific... The following works for 5.0 for i in lib secure/lib gnu/lib usr.sbin/pcvt/keycap \ gnu/usr.bin/perl usr.bin/lex usr.sbin/config ; do (cd ${i}; eval $e obj) done log "now make the static libraries" eval $e -DNOPROFILE -DNOPIC libraries (cd ${SRC}/usr.sbin/config eval $e # build binary eval $e install # install it ) ) || fail $? "libraries" log "Libraries done" } # set_type looks in user or system directories for the floppy type # specified as first argument, and sets variables according to the config. # file. Also sets MY_TREE and BUILDDIR and SITE set_type() { local a i log "set_type()" THETYPE=3D$1 SITE=3D$2 a=3D$1 for i in ${c_startdir}/${a} ${PICO_TREE}/${a} ; do log "set_type: checking $i" if [ -d $i -a -f $i/PICOBSD -a -f $i/crunch.conf ] ; then set -- `cat $i/PICOBSD | \ awk '/^#PicoBSD/ {print $2, $3, $4, $5, $6}'` if [ "$1" !=3D "" ]; then MFS_SIZE=3D$1 ; init_name=3D$2 mfs_inodes=3D$3 ; fd_inodes=3D$4 name=3D`(cd $i ; pwd) ` name=3D`basename $name` MY_TREE=3D$i BUILDDIR=3D${c_startdir}/build_dir-${name} log "Matching file $name in $i" return ; fi fi done echo "Type $a NOT FOUND" } clean_tree() { log "clean_tree()" if [ "${name}" =3D "" ] ; then echo "---> Wrong floppy type" exit 3 fi rm -rf ${BUILDDIR} } # prepare a message to be printed in the dialog menus. set_msgs() { # OK log "set_msgs()" MSG1=3D"Type: ${THETYPE} name $name" MSG=3D"PicoBSD build -- Current parameters:\n\n\t1. ${MSG1}\n\ \t2. MFS size: ${MFS_SIZE} kB\n\ \t3. Site-info: ${SITE}\n\t4. Full-path: ${MY_TREE}\n" } # Main build procedure. build_image() { log "build_image() <${name}>" [ "${name}" !=3D "" ] || fail $? bad_type clear set_msgs printf "${MSG}---> We'll use the sources living in ${SRC}\n\n" # read config variables from a global and then a type-specific file # basically STAND_LINKS and MY_DEVS, but can also override other # variables. #=20 . ${PICO_TREE}/build/config if [ -f ${MY_TREE}/config ] ; then . ${MY_TREE}/config fi # location of the object directory PICO_OBJ=3D${l_objtree}/picobsd/${THETYPE} log "PICO_OBJ is ${PICO_OBJ}" if [ ${OSVERSION} -ge 500035 ] ; then MAKEOBJDIRPREFIX=3D${l_objtree} export MAKEOBJDIRPREFIX log `cd ${SRC}; make -f Makefile.inc1 -V WMAKEENV` eval export `cd ${SRC}; make -f Makefile.inc1 -V WMAKEENV` fi # create build directory and subtree mkdir -p ${BUILDDIR}/crunch # remove any old stuff rm -f ${BUILDDIR}/kernel.gz ${BUILDDIR}/${c_fs} # invoke commands to build a kernel do_kernel # fill a subdirectory with things that go into the floppy # (mostly /etc and similar stuff) populate_floppy_fs # populate it and produce a file with the MFS image populate_mfs_tree # things which go into mfs # create, mount and fill a filesystem with floppy image fill_floppy_image # copies everything into the floppy } build_package() { local z msg log "build_package()" touch build.status echo "##############################################" >>build.status echo "## `date` ">>build.status echo "##############################################" >>build.status for z in bridge dial router net isp ; do set_type ${z} echo "---------------------------------------------">>build.status echo "Building TYPE=3D${z}, SIZE=3D${MFS_SIZE}" >>build.status msg=3D"(ok)" # error message build_image || msg=3D"** FAILED! **" echo " ${msg}">>build.status # where do i put things ? # clean_tree done exit 0 } # Set build parameters interactively main_dialog() { local ans i l log "main_dialog()" while [ true ] ; do set_msgs rm ${c_reply} dialog --menu "PicoBSD build menu -- (29 sep 2001)" 19 70 12 \ N "--> READY, build it <---" \ T "${MSG1}" \ K "edit Kernel config file" \ E "Edit crunch.conf file" \ S "MFS Size: ${MFS_SIZE}kB" \ I "Init type: ${init_name}" \ F "Floppy size: ${fd_size}kB" \ M "MFS bytes per inode: ${mfs_inodes}" \ U "UFS bytes per inode: ${fd_inodes}" \ $ "Site-info: ${SITE}" \ Q "Quit" \ 2> ${c_reply} ans=3D`cat ${c_reply}` rm ${c_reply} case ${ans} in T) l=3D"" for i in ${c_startdir} ${c_startdir}/* ${PICO_TREE}/* ; do if [ -d $i -a -f $i/PICOBSD -a -f $i/crunch.conf ]; then l=3D"$l `basename $i` `basename $i`" fi done log $l { dialog --menu "Setup the type of configuration" 12 70 5 $l \ 2> ${c_reply} && set_type "`cat ${c_reply}`" ${SITE} ; } || true ;; I) { dialog --menu "Choose your init(8) program" \ 10 70 2 init "Standard init (requires getty)" \ oinit "small init from TinyWare" 2> ${c_reply} \ && init_name=3D`cat ${c_reply}` ; } || true ;; K) ${EDITOR} ${MY_TREE}/PICOBSD ;; E) ${EDITOR} ${MY_TREE}/crunch.conf ;; S) { dialog --title "MFS Size setup" --inputbox \ "MFS size depends on what you need to put on the MFS image. Typically \ ranges between 820kB (for very small bridge/router images) to \ as much as 2500kB kB for a densely packed image. \ Keep in mind that this memory is \ totally lost to other programs. Usually you want to keep \ this as small as possible. " 10 70 2> ${c_reply} \ && MFS_SIZE=3D`cat ${c_reply}` ; } || true ;; \$) { dialog --title "Site info setup" --inputbox \ "Please enter the full path to the directory \ containing site-specific setup. \ This directory tree must contain files that replace \ standard ones in floppy.tree/ and mfs.tree/ . " \ 10 70 2> ${c_reply} && SITE=3D`cat ${c_reply}` ; } || true ;; F) { dialog --menu "Set floppy size" 15 70 4 \ 1440 "1.44MB" 1720 "1.72MB" 2880 "2.88MB" 4096 "4MB" \ 2> ${c_reply} && fd_size=3D`cat ${c_reply}` ; } || true ;; M) { dialog --title "MFS bytes per inode:" --inputbox \ "Enter MFS bytes per inode (typically 4096..65536). \ A larger value means fewer inodes but more space on MFS" \ 10 70 2> ${c_reply} && mfs_inodes=3D`cat ${c_reply}` ; } || true ;; U) { dialog --title "Floppy bytes per inode:" --inputbox \ "Enter floppy bytes per inode (typically 3072..65536). \ A larger value means fewer inodes but more space on the floppy." \ 10 70 2> ${c_reply} && fd_inodes=3D`cat ${c_reply}` ; } || true ;; N) break 2 ;; Q) exit 0 ;; *) echo "=07Unknown option \"${ans}\". Try again." sleep 2 clear ;; esac done } # Call the build procedure # Install image do_install() { log "do_install()" if [ "${o_interactive}" =3D "NO" ] ; then echo "+++ Build completed +++" cat .build.reply || true return fi dialog --title "Build ${THETYPE} completed" --inputbox \ "\nThe build process was completed successfuly.\n\ `cat .build.reply` \n\n\ Now we are going to install the image on the floppy.\n\ Please insert a blank floppy in /dev/fd0.\\n WARNING: the contents of the floppy will be permanently erased!\n\ \n\ Your options:\n\ * ^C or [Cancel] to abort,\n\ * Enter to install ${c_img},\n\ " 20 80 2> ${c_reply} if [ "$?" =3D "0" ]; then echo "Writing ${c_img}..." dd if=3D${BUILDDIR}/${c_img} of=3D/dev/fd0.${fd_size} else echo "Ok, the image is in ${c_img}" fi echo "Done." } #------------------------------------------------------------------- # invoke the Makefile to compile the kernel. do_kernel() { # OK log "do_kernel() Preparing kernel \"$name\" in $MY_TREE" (cd $MY_TREE; export name SRC BUILDDIR # used in this makefile ; # export CONFIG if [ "${o_do_modules}" =3D "yes" ] ; then MODULES=3D"" export MODULES fi make -m ${SRC}/share/mk -v -f ${PICO_TREE}/build/Makefile.conf ) || \ fail $? missing_kernel } # Populate the variable part of the floppy filesystem. Must be done before # the MFS because its content might need to be copied there as well. # # This involves fetching files from three subtrees, in this order: # # 1. a standard one, from which type-specific files are excluded; # 2. a type-specific one; # 3. a site-specific one. # # Files are first copied to a local tree and then compressed. populate_floppy_fs() { # OK local dst excl srcdir log "populate_floppy_fs()" dst=3D${BUILDDIR}/floppy.tree log "pwd=3D`pwd` Populating floppy filesystem..." # clean relics from old compilations. rm -rf ${dst} || true mkdir ${dst} excl=3D${MY_TREE}/floppy.tree.exclude if [ -f ${excl} ] ; then excl=3D"--exclude-from ${excl}" log "Files excluded from generic tree: `echo;cat ${excl}`" else excl=3D"" fi (cd ${PICO_TREE}/floppy.tree ; tar -cf - --exclude CVS ${excl} . ) | \ (cd ${dst} ; tar x${o_tarv}f - ) log "Copied from generic floppy-tree `echo; ls -laR ${dst}`" srcdir=3D${MY_TREE}/floppy.tree if [ -d ${srcdir} ] ; then log "update with type-specific files:" (cd ${srcdir} ; tar -cf - --exclude CVS . ) | \ (cd ${dst} ; tar x${o_tarv}f - ) log "Copied from type floppy-tree `echo; ls -laR ${dst}`" else log "No type-specific floppy-tree" fi if [ -d ${srcdir}.${SITE} ] ; then log "Update with site-specific (${SITE}) files:" (cd ${srcdir}.${SITE} ; tar -cf - --exclude CVS . ) | \ (cd ${dst} ; tar x${o_tarv}f - ) log "Copied from site floppy-tree `echo; ls -laR ${dst}`" else log "No site-specific floppy-tree" fi # gzip returns an error if it fails to compress some file (cd $dst ; gzip -9 etc/* log "Compressed files in etc/ `echo; ls -l etc`" ) || true } # Populate the memory filesystem with binaries and non-variable # configuration files. # First do an mtree pass, then create directory links and device entries, # then run crunchgen etc. to build the binary and create links. # Then copy the specific/generic mfs_tree. # Finally, if required, make a copy of the floppy.tree onto /fd populate_mfs_tree() { local a dst log "populate_mfs_tree()" dst=3D${BUILDDIR}/mfs.tree # clean relics from old compilations. rm -rf ${dst} || true mkdir ${dst} log "pwd=3D`pwd`, Populating MFS tree..." # use type-specific mfs.mtree, default to generic one. a=3D${MY_TREE}/mfs.mtree [ -f ${a} ] || a=3D${PICO_TREE}/build/mfs.mtree log "Running mtree using $a..." mtree -deU -f $a -p ${dst} > /dev/null || fail $? mtree # XXX create links for i in ${STAND_LINKS}; do ln -s /stand ${dst}/$i done ln -s /dev/null ${dst}/var/run/log ln -s /etc/termcap ${dst}/usr/share/misc/termcap ( cd ${BUILDDIR}/crunch log "Making and installing crunch1 from `pwd` src ${SRC}..." a=3D${BUILDDIR}/crunch1.conf ( export BUILDDIR SRC MY_TREE PICO_OBJ ; make -m ${SRC}/share/mk \ -v -f ${PICO_TREE}/build/Makefile.conf ${BUILDDIR}/crunch.mk ) log "Libs are ${LIBS} " export SRC # used by crunch.mk # export LIBS CFLAGS log "Now make -f crunch.mk" make -m ${SRC}/share/mk ${o_makeopts} -f ${BUILDDIR}/crunch.mk strip --remove-section=3D.note --remove-section=3D.comment crunch1 mv crunch1 ${dst}/stand/crunch chmod 555 ${dst}/stand/crunch log "Making links for binaries..." for i in `crunchgen -l $a` ; do ln ${dst}/stand/crunch ${dst}/stand/${i}; done # rm $a # do not remove! ) || fail $? crunch if [ -f ${dst}/stand/sshd ] ; then log "Setting up host key for sshd:" if [ -f ${BUILDDIR}/floppy.tree/etc/ssh_host_key.gz ] ; then log "Using existing host key" else log "Generating new host key"=20 ssh-keygen -t rsa1 -f ${BUILDDIR}/floppy.tree/etc/ssh_host_key \ -N "" -C "root@picobsd" gzip -9 ${BUILDDIR}/floppy.tree/etc/ssh_host_key* || true fi fi log "Copy generic and site-specific MFS tree..." for MFS_TREE in ${PICO_TREE}/mfs_tree ${MY_TREE}/mfs_tree ; do if [ -d ${MFS_TREE} ] ; then log "Copy ${MFS_TREE} ..." (cd ${MFS_TREE} ; tar -cf - --exclude CVS . ) | \ (cd ${dst} ; tar x${o_tarv}f - ) fi done if [ "${o_all_in_mfs}" =3D "yes" ]; then log "Copy generic floppy_tree into MFS..." # this may fail in case the floppy is empty cp -Rp ${BUILDDIR}/floppy.tree/* ${dst}/fd || true fi if [ "${o_no_devfs}" !=3D "" ] ; then # create device entries using MAKEDEV (cd ${dst}/dev ln -s ${SRC}/etc/MAKEDEV ; chmod 555 MAKEDEV # log `pwd` sh ./MAKEDEV ${MY_DEVS} rm MAKEDEV ) fi if [ "`id -u`" =3D "0" ] ; then log "Fixing permissions" (cd ${dst}; chown -R root . ) fi if [ -n "${import_files}" ] ; then log "importing ${import_files} into mfs" # We do it in a chroot environment on the target so # symlinks are followed correctly. cp `which tar` ${dst}/my_copy_of_tar (cd ${l_usrtree}/.. ; tar cf - ${import_files} ) | \ (chroot ${dst} /my_copy_of_tar xf - ) rm ${dst}/my_copy_of_tar fi (cd ${BUILDDIR} # override the owner echo "/set uid=3D0 gid=3D0" > mtree.out mtree -c -p ${dst} -k "" >> mtree.out log "mtre.out at ${BUILDDIR}/mtree.out" makefs -t ffs -o bsize=3D4096 -o fsize=3D512 \ -s ${MFS_SIZE}k -f 100 -F mtree.out ${c_fs} ${dst} ls -l ${c_fs} ) log "done mfs image" } final_cleanup() { log "final_cleanup()" rm -rf ${c_mnt} ${c_reply} 2> /dev/null || true rm -f ${c_reply} } # fail errno errcode # This function is used to trap errors and print msgs # fail() { local errno errocode where errno=3D$1 errcode=3D$2 where=3D$3 echo "---> fail: Error <${errno}> error code <${errcode}> in <${where}>" case ${errcode} in mtree) echo "Error while making hierarchy in ${c_mnt}" ;; crunch) echo "Error while building ${name}." ;; missing_kernel) echo "Error: you must build PICOBSD${suffix} kernel first" ;; includes) echo "Error: failed while making includes" ;; libraries) echo "Error: failed while making libraries" ;; bad_type) echo "Error: unknown floppy type ${name}" ;; no_space) echo "Error: no space left on device (${where})" ;; no_mfs) echo "Error: while writing MFS into the kernel." ;; "") echo "User break" errcode=3D"userbreak" ;; *) echo "unknown error, maybe user break: $errno $errcode" ;; esac echo "---> Aborting $0" # try to cleanup the vnode. final_cleanup exit 2 } fill_floppy_image() { local blocks dst mfs_start mfs_end mfs_size img_size log "fill_floppy_image()" dst=3D${c_mnt} # where to create the image log "Preparing ${fd_size}kB floppy filesystem..." # correct blocks according to size. blocks=3D${fd_size}; if [ "${blocks}" =3D "1720" ]; then blocks=3D1722 elif [ "${blocks}" =3D "1480" ]; then blocks=3D1476 fi log "Labeling floppy image" log "patch ${c_boot2} to boot /kernel right away" b2=3D${BUILDDIR}/boot2 # modified boot2 cp -f ${c_boot2} ${b2} chmod 0644 ${b2} set `strings -at d ${b2} | grep "/boot/loader"` echo -e "/kernel\0\0\0\0\0" | \ dd of=3D${b2} obs=3D$1 oseek=3D1 conv=3Dnotrunc 2>/dev/null chmod 0444 ${b2} dst=3D${BUILDDIR}/image.tree rm -rf ${dst} mkdir -p ${dst} ( cd ${BUILDDIR} set 0 0 # reset variables # $1 takes the offset of the MFS filesystem set `strings -at d kernel | grep "MFS Filesystem goes here"` mfs_start=3D$1 set 0 0 # reset variables set `strings -at d kernel | grep "MFS Filesystem had better"` mfs_end=3D$1 mfs_size=3D"$((${mfs_end} - ${mfs_start}))" set -- `ls -l ${c_fs}`; imgsize=3D"$5" if [ ${mfs_start} -gt 0 -a ${mfs_size} -ge ${imgsize} ] ; then mfs_ofs=3D$((${mfs_start} + 8192)) log "Preload kernel with file ${c_fs} at ${mfs_ofs}" dd if=3D${c_fs} ibs=3D8192 iseek=3D1 of=3Dkernel obs=3D${mfs_ofs} \ oseek=3D1 conv=3Dnotrunc 2> /dev/null else log "not loading mfs, size ${mfs_size} img ${imgsize}" fi log "Compress with kgzip and copy to floppy image" kgzip -o kernel.gz kernel cp -p kernel.gz ${dst}/kernel || fail $? no_space "copying kernel" log "Now transfer floppy tree if not already in MFS image" # now transfer the floppy tree. If it is already in mfs, dont bother. if [ "${o_all_in_mfs}" !=3D "yes" ] ; then cp -Rp floppy.tree/* ${dst} || \ fail $? no_space "copying floppy tree" fi ) (cd ${BUILDDIR} makefs -t ffs -o bsize=3D4096 -o fsize=3D512 \ -s ${blocks}k -f 50 ${c_img} ${dst} # ${l_label} -f `pwd`/${c_img} ${l_label} -w -f `pwd`/${c_img} auto # write in a label # copy partition c: into a: with some sed magic ${l_label} -f `pwd`/${c_img} | sed -e '/ c:/{p;s/c:/a:/;}' | \ ${l_label} -R -f `pwd`/${c_img} /dev/stdin ${l_label} -f `pwd`/${c_img} ls -l ${c_img} logverbose "after disklabel" ) # dump the primary and secondary boot dd if=3D${c_boot1} of=3D${BUILDDIR}/${c_img} conv=3Dnotrunc 2>/dev/null dd if=3D${b2} iseek=3D1 2> /dev/null | \ dd of=3D${BUILDDIR}/${c_img} oseek=3D2 conv=3Dnotrunc 2>/dev/null logverbose "done floppy image" # XXX (log "Fixing permissions"; cd ${dst}; chown -R root *) rm -rf ${BUILDDIR}/floppy.tree || true # cleanup # df -ik ${dst} | colrm 70 > .build.reply rm -rf ${dst} rm ${BUILDDIR}/kernel.gz ${BUILDDIR}/${c_fs} } # This function creates variables which depend on the source tree in use: # SRC, l_usrtree, l_objtree # Optionally creates libraries, includes and the like (for cross compiles, # needs to be done once). set_build_parameters() { log "set_build_parameters() SRC is ${SRC}" if [ "${SRC}" =3D "/usr/src" ] ; then l_usrtree=3D${USR:-/usr} else l_usrtree=3D${USR:-${SRC}/../usr} fi l_objtree=3D${l_usrtree}/obj-pico PICO_TREE=3D${PICO_TREE:-${SRC}/release/picobsd} set `grep "#define[\t ]__FreeBSD_version" ${SRC}/sys/sys/param.h` OSVERSION=3D$3 log "OSVERSION is ${OSVERSION}" if [ "${o_init_src}" !=3D "" ] ; then if [ ${OSVERSION} -lt 500035 ] ; then create_includes_and_libraries else create_includes_and_libraries2 fi fi if [ ${OSVERSION} -lt 500035 ] ; then # Create the right LIBS and CFLAGS for further builds. # and build the config program LIBS=3D"-L${l_usrtree}/lib" CFLAGS=3D"-nostdinc -I${l_usrtree}/include" export LIBS CFLAGS CONFIG=3D${l_usrtree}/sbin/config export CONFIG fi } #------------------------------------------------------------------- # Main entry of the script. Initialize variables, parse command line # arguments. set_defaults while [ true ]; do case $1 in --src) # set the source path instead of /usr/src SRC=3D`(cd $2; pwd)` shift ;; --init) o_init_src=3D"YES" ;; --floppy_size) fd_size=3D$2 shift ;; --all_in_mfs) o_all_in_mfs=3D"yes" ;; --no_all_in_mfs) o_all_in_mfs=3D"" ;; --modules) # also build kernel modules o_do_modules=3D"yes" ;; -n) o_interactive=3D"NO" ;; -clear|-clean|-c) # clean o_clean=3D"YES" o_interactive=3D"NO" ;; -v) # need -v -v to wait for user input o_verbose=3D$((${o_verbose}+1)) # verbose level o_tarv=3D"v" # tar verbose flag o_makeopts=3D"-d l" # be verbose ;; *) break ; ;; esac shift done set_build_parameters # things that depend on ${SRC} set_type $1 $2 # type and site, respectively # If $1=3D"package", it creates a neat set of floppies if [ "$1" =3D "package" ] ; then build_package fi if [ "${o_interactive}" !=3D "NO" ] ; then main_dialog fi if [ "${o_clean}" =3D "YES" ] ; then clean_tree else build_image do_install fi final_cleanup exit 0 --bg08WKrSYDhXBjb5-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 14:44:03 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2989B16A420 for ; Tue, 31 Jan 2006 14:44:03 +0000 (GMT) (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 6A83443D73 for ; Tue, 31 Jan 2006 14:44:01 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k0VEi06D018313; Tue, 31 Jan 2006 07:44:00 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43DF77B7.4050800@samsco.org> Date: Tue, 31 Jan 2006 07:44:07 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20060131061812.A53329@xorpc.icir.org> In-Reply-To: <20060131061812.A53329@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: current@freebsd.org Subject: Re: boot block differences between 4.x and 6.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, 31 Jan 2006 14:44:03 -0000 Luigi Rizzo wrote: > maybe some of you know the answer here... > > the revised picobsd script (attached here, it uses > sysutils/makefs instead of vnconfig/mdconfig so it can > run as a non privileged user) that i was using to > create images with the 4.11 boot blocks (boot1 and boot2), > does not seem to work anymore with the boot blocks > taken from 6.0 (and so, -current as well). > > When i force it to use the 4.x boot blocks, all is fine, > and the picobsd.bin produced (built on 6.0 using 7-current > sources) boots fine on qemu. > > I am a bit puzzled on what could be the relevant change in boot1/boot2 > could have caused the loss of functionality. > > If that matters, picobsd bypasses /boot/loader and goes straight > to boot /kernel (the name is patched into the boot block, > but it does not matter because the new blocks do not > even get to the point of showing the 'missing /boot/loader' > error message). > > does anyone know where should i look at ? > > thanks > luigi > The big difference is that the boot blocks grew significantly to support UFS2. Scott From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 15:18:25 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CA1416A420; Tue, 31 Jan 2006 15:18:25 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FFF143D46; Tue, 31 Jan 2006 15:18:23 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5BFDF50A7F; Tue, 31 Jan 2006 16:18:22 +0100 (CET) Received: from localhost (ana50.internetdsl.tpnet.pl [83.17.82.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A41E350A3E; Tue, 31 Jan 2006 16:18:15 +0100 (CET) Date: Tue, 31 Jan 2006 16:18:09 +0100 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20060131151809.GE83051@garage.freebsd.pl> References: <200601311109.k0VB9MRq025366@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pql/uPZNXIm1JCle" Content-Disposition: inline In-Reply-To: <200601311109.k0VB9MRq025366@repoman.freebsd.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: kris@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_malloc.c src/share/man/man9 Makefile redzone.9 src/sys/vm redzone.c redzone.h src/sys/conf NOTES files options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 15:18:25 -0000 --Pql/uPZNXIm1JCle Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2006 at 11:09:22AM +0000, Pawel Jakub Dawidek wrote: +> pjd 2006-01-31 11:09:22 UTC +>=20 +> FreeBSD src repository +>=20 +> Modified files: +> sys/kern kern_malloc.c=20 +> share/man/man9 Makefile=20 +> sys/conf NOTES files options=20 +> Added files: +> share/man/man9 redzone.9=20 +> sys/vm redzone.c redzone.h=20 +> Log: +> Add buffer corruption protection (RedZone) for kernel's malloc(9). +> It detects both: buffer underflows and buffer overflows bugs at runtime +> (on free(9) and realloc(9)) and prints backtraces from where memory was +> allocated and from where it was freed. +> =20 +> Tested by: kris As I noted above, Kris did some tests with redzone(9) enabled and haven't found any issues. We may want to turn it on in HEAD by default for some time, so more code can be tested. What do you think? Kris, is there visible overhead with redzone(9)? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Pql/uPZNXIm1JCle Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD33+xForvXbEpPzQRAuRdAJ9pSR23+em6qMnj8oYU2vLAUi69qwCfYmX5 18jwSuhBBycyRDTh7buzXw0= =udjd -----END PGP SIGNATURE----- --Pql/uPZNXIm1JCle-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 15:21:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D785D16A422 for ; Tue, 31 Jan 2006 15:21:19 +0000 (GMT) (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 AADD443D5C for ; Tue, 31 Jan 2006 15:21:17 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k0VFLHQw054192; Tue, 31 Jan 2006 07:21:17 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k0VFLHxx054191; Tue, 31 Jan 2006 07:21:17 -0800 (PST) (envelope-from rizzo) Date: Tue, 31 Jan 2006 07:21:17 -0800 From: Luigi Rizzo To: Scott Long Message-ID: <20060131072117.B53681@xorpc.icir.org> References: <20060131061812.A53329@xorpc.icir.org> <43DF77B7.4050800@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <43DF77B7.4050800@samsco.org>; from scottl@samsco.org on Tue, Jan 31, 2006 at 07:44:07AM -0700 Cc: current@freebsd.org Subject: Re: boot block differences between 4.x and 6.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, 31 Jan 2006 15:21:20 -0000 On Tue, Jan 31, 2006 at 07:44:07AM -0700, Scott Long wrote: > Luigi Rizzo wrote: > > maybe some of you know the answer here... > > > > the revised picobsd script (attached here, it uses > > sysutils/makefs instead of vnconfig/mdconfig so it can > > run as a non privileged user) that i was using to > > create images with the 4.11 boot blocks (boot1 and boot2), > > does not seem to work anymore with the boot blocks > > taken from 6.0 (and so, -current as well). > > > > When i force it to use the 4.x boot blocks, all is fine, > > and the picobsd.bin produced (built on 6.0 using 7-current > > sources) boots fine on qemu. > > > > I am a bit puzzled on what could be the relevant change in boot1/boot2 > > could have caused the loss of functionality. ... > The big difference is that the boot blocks grew significantly to > support UFS2. > > Scott ok good pointer.. so could it be that the boot blocks as installed by 6.0-RELEASE are UFS2_ONLY, and the file system produced by makefs is UFS1, hence the problem ? How do i tell, and would it make sense to build, in the release, also a version of /boot/boot that can deal with ufs1 ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 15:59:39 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC0D616A422 for ; Tue, 31 Jan 2006 15:59:39 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48DE043D45 for ; Tue, 31 Jan 2006 15:59:39 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k0VFvrfW033277; Tue, 31 Jan 2006 08:57:56 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 31 Jan 2006 08:58:04 -0700 (MST) Message-Id: <20060131.085804.96587431.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <43DF77B7.4050800@samsco.org> References: <20060131061812.A53329@xorpc.icir.org> <43DF77B7.4050800@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 31 Jan 2006 08:57:56 -0700 (MST) Cc: rizzo@icir.org, current@freebsd.org Subject: Re: boot block differences between 4.x and 6.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, 31 Jan 2006 15:59:40 -0000 In message: <43DF77B7.4050800@samsco.org> Scott Long writes: : Luigi Rizzo wrote: : > maybe some of you know the answer here... : > : > the revised picobsd script (attached here, it uses : > sysutils/makefs instead of vnconfig/mdconfig so it can : > run as a non privileged user) that i was using to : > create images with the 4.11 boot blocks (boot1 and boot2), : > does not seem to work anymore with the boot blocks : > taken from 6.0 (and so, -current as well). : > : > When i force it to use the 4.x boot blocks, all is fine, : > and the picobsd.bin produced (built on 6.0 using 7-current : > sources) boots fine on qemu. : > : > I am a bit puzzled on what could be the relevant change in boot1/boot2 : > could have caused the loss of functionality. : > : > If that matters, picobsd bypasses /boot/loader and goes straight : > to boot /kernel (the name is patched into the boot block, : > but it does not matter because the new blocks do not : > even get to the point of showing the 'missing /boot/loader' : > error message). : > : > does anyone know where should i look at ? : > : > thanks : > luigi : > : : The big difference is that the boot blocks grew significantly to : support UFS2. And boot1/boot2 were merged into boot... Warner From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 15:03:04 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B00216A420 for ; Tue, 31 Jan 2006 15:03:04 +0000 (GMT) (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 C83D043D49 for ; Tue, 31 Jan 2006 15:03:03 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unefez@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k0VF2ulY054808 for ; Tue, 31 Jan 2006 16:03:01 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k0VF2uGP054807; Tue, 31 Jan 2006 16:02:56 +0100 (CET) (envelope-from olli) Date: Tue, 31 Jan 2006 16:02:56 +0100 (CET) Message-Id: <200601311502.k0VF2uGP054807@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <20060131061812.A53329@xorpc.icir.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 31 Jan 2006 16:03:01 +0100 (CET) X-Mailman-Approved-At: Tue, 31 Jan 2006 17:59:02 +0000 Cc: Subject: Re: boot block differences between 4.x and 6.x ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@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: Tue, 31 Jan 2006 15:03:04 -0000 Luigi Rizzo wrote: > the revised picobsd script (attached here, it uses > sysutils/makefs instead of vnconfig/mdconfig so it can > run as a non privileged user) that i was using to > create images with the 4.11 boot blocks (boot1 and boot2), > does not seem to work anymore with the boot blocks > taken from 6.0 (and so, -current as well). > > When i force it to use the 4.x boot blocks, all is fine, > and the picobsd.bin produced (built on 6.0 using 7-current > sources) boots fine on qemu. FWIW, a standard 4-stable system boots fine with the boot blocks (and loader) from RELENG_6. I'm running such a mixed system: /boot/* and boot blocks from RELENG_6, and everything else from RELENG_4. I think the most visible changes in the boot blocks was UFS2 support and the removal of nextboot(8) support. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing." -- Dick Brandon From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 18:21:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13CEC16A420 for ; Tue, 31 Jan 2006 18:21:12 +0000 (GMT) (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 85AAB43D5E for ; Tue, 31 Jan 2006 18:21:10 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k0VIL2ju057605; Tue, 31 Jan 2006 10:21:02 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k0VIL2IL057604; Tue, 31 Jan 2006 10:21:02 -0800 (PST) (envelope-from rizzo) Date: Tue, 31 Jan 2006 10:21:02 -0800 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20060131102102.B57192@xorpc.icir.org> References: <20060131061812.A53329@xorpc.icir.org> <43DF77B7.4050800@samsco.org> <20060131.085804.96587431.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060131.085804.96587431.imp@bsdimp.com>; from imp@bsdimp.com on Tue, Jan 31, 2006 at 08:58:04AM -0700 Cc: current@freebsd.org Subject: Re: boot block differences between 4.x and 6.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, 31 Jan 2006 18:21:12 -0000 On Tue, Jan 31, 2006 at 08:58:04AM -0700, M. Warner Losh wrote: ... > : The big difference is that the boot blocks grew significantly to > : support UFS2. > > And boot1/boot2 were merged into boot... ok problem solved, thanks for the pointers. For the records (and the list archives): the old-style picobsd script would do image[0..511] = boot1[0..511] image[1024..8191] = boot2[512..7679] counting on a 512-bytes hole which is taken, for the first 0x114 = 276 (dec) bytes by the label. The new boot blocks, however have code immediately after the label so the offset for copying boot2 (or the equivalent part of /boot/boot) must be set to 276 on the source and 276+512 = 788 on the destination: image[0..511] = boot1[0..511] image[788..8191] = boot2[276..7679] don't know how much of a hack it is to hardwire the disklabel size into the script, but given that this approach of explicit constants is used in all the related pieces of code, i guess there is no better way around... cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 18:42:24 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9883C16A420; Tue, 31 Jan 2006 18:42:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5018343D46; Tue, 31 Jan 2006 18:42:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 394501A3C22; Tue, 31 Jan 2006 10:42:24 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8A7825125B; Tue, 31 Jan 2006 13:42:23 -0500 (EST) Date: Tue, 31 Jan 2006 13:42:23 -0500 From: Kris Kennaway To: Pawel Jakub Dawidek Message-ID: <20060131184223.GC10257@xor.obsecurity.org> References: <200601311109.k0VB9MRq025366@repoman.freebsd.org> <20060131151809.GE83051@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline In-Reply-To: <20060131151809.GE83051@garage.freebsd.pl> User-Agent: Mutt/1.4.2.1i Cc: kris@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_malloc.c src/share/man/man9 Makefile redzone.9 src/sys/vm redzone.c redzone.h src/sys/conf NOTES files options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 18:42:24 -0000 --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2006 at 04:18:09PM +0100, Pawel Jakub Dawidek wrote: > On Tue, Jan 31, 2006 at 11:09:22AM +0000, Pawel Jakub Dawidek wrote: > +> pjd 2006-01-31 11:09:22 UTC > +>=20 > +> FreeBSD src repository > +>=20 > +> Modified files: > +> sys/kern kern_malloc.c=20 > +> share/man/man9 Makefile=20 > +> sys/conf NOTES files options=20 > +> Added files: > +> share/man/man9 redzone.9=20 > +> sys/vm redzone.c redzone.h=20 > +> Log: > +> Add buffer corruption protection (RedZone) for kernel's malloc(9). > +> It detects both: buffer underflows and buffer overflows bugs at runt= ime > +> (on free(9) and realloc(9)) and prints backtraces from where memory = was > +> allocated and from where it was freed. > +> =20 > +> Tested by: kris >=20 > As I noted above, Kris did some tests with redzone(9) enabled and haven't > found any issues. >=20 > We may want to turn it on in HEAD by default for some time, so more code > can be tested. >=20 > What do you think? Kris, is there visible overhead with redzone(9)? I haven't really tested that, but it doesn't seem too bad. I think it would be well worth leaving it on for a while to see what turns up though. Kris --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD36+OWry0BWjoQKURAlmUAJ9bNDspx3O9fZutQ4Gp61jJ/0powgCfUe42 f8jPHS3YWKU3ysQ5GSRmldA= =iv0m -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 18:52:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06B7116A422 for ; Tue, 31 Jan 2006 18:52:19 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D9E443D53 for ; Tue, 31 Jan 2006 18:52:12 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 31 Jan 2006 10:52:13 -0800 Message-ID: <43DFB1DC.2020001@elischer.org> Date: Tue, 31 Jan 2006 10:52:12 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <200601311502.k0VF2uGP054807@lurza.secnetix.de> In-Reply-To: <200601311502.k0VF2uGP054807@lurza.secnetix.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: boot block differences between 4.x and 6.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, 31 Jan 2006 18:52:19 -0000 Oliver Fromme wrote: >Luigi Rizzo wrote: > > the revised picobsd script (attached here, it uses > > sysutils/makefs instead of vnconfig/mdconfig so it can > > run as a non privileged user) that i was using to > > create images with the 4.11 boot blocks (boot1 and boot2), > > does not seem to work anymore with the boot blocks > > taken from 6.0 (and so, -current as well). > > > > When i force it to use the 4.x boot blocks, all is fine, > > and the picobsd.bin produced (built on 6.0 using 7-current > > sources) boots fine on qemu. > >FWIW, a standard 4-stable system boots fine with the boot >blocks (and loader) from RELENG_6. I'm running such a >mixed system: /boot/* and boot blocks from RELENG_6, and >everything else from RELENG_4. > >I think the most visible changes in the boot blocks was >UFS2 support and the removal of nextboot(8) support. > > which I hope to put back because we continue to need it. (The new nextboot being dependent on the root filesystem still being ok which is unacceptable to most embedded devices I've worked on, and why we still use the old bootblocks on all systems shipped.). >Best regards > Oliver > > > From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 18:52:30 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAEA716A420; Tue, 31 Jan 2006 18:52:30 +0000 (GMT) (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 DC29D43D78; Tue, 31 Jan 2006 18:52:24 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k0VIqOwr057984; Tue, 31 Jan 2006 10:52:24 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k0VIqODC057983; Tue, 31 Jan 2006 10:52:24 -0800 (PST) (envelope-from rizzo) Date: Tue, 31 Jan 2006 10:52:24 -0800 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20060131105224.A57698@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: small@freebsd.org Subject: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 18:52:31 -0000 [i am cc-ing -small because they are interested, but please keep the discussion on -current] as the subject says... The picobsd script in the tree at the moment is broken in several ways. It may work on 4.x, but not on newer releases. I have a fixed version (mostly the one i attached yesterday, with a minor fix to handle the newer boot blocks) that works also up to -current. Besides, it relies on ports/sysutils/makefs to build the filesystem image so it can run without superuser privs. I know it is not ideal to have a piece of code in the main tree that depends on an external port. Yet, better than have it broken. Now the options are: 1. do nothing and leave things broken; 2. commit the updated script, fix one or two sample targets, and remove the others (all of this is in src/release/picobsd) 3. remove the entire src/release/picobsd tree and move it to a port (question - do we want the old content of src/release/picobsd in ports/foo/picobsd/files ? In any case, we need a place in some repository to store these things) Option #3 is probably the best one, except that the exact 'config' files are strongly tied to the target source tree you are using, at least for major releases (libraries differ, application name change, etc) and so I'd need to modify the script to reach the templates for RELENG_7, RELENG_6... if they are not already in the target source tree. Also, this requires a repocopy. However given that i don't have a lot of time at the moment, i would compromise on option #2 for the time being, and move to option #3 at a later (but unspecified) time. comments ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 19:18:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4380E16A420; Tue, 31 Jan 2006 19:18:22 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66BE343D6E; Tue, 31 Jan 2006 19:18:21 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k0VJFlLq035762; Tue, 31 Jan 2006 12:15:48 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 31 Jan 2006 12:15:59 -0700 (MST) Message-Id: <20060131.121559.127178102.imp@bsdimp.com> To: rizzo@icir.org From: "M. Warner Losh" In-Reply-To: <20060131105224.A57698@xorpc.icir.org> References: <20060131105224.A57698@xorpc.icir.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 31 Jan 2006 12:15:49 -0700 (MST) Cc: current@freebsd.org, small@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 19:18:22 -0000 In message: <20060131105224.A57698@xorpc.icir.org> Luigi Rizzo writes: : [i am cc-ing -small because they are interested, but please : keep the discussion on -current] : : as the subject says... : : The picobsd script in the tree at the moment is broken in : several ways. It may work on 4.x, but not on newer releases. : : I have a fixed version (mostly the one i attached yesterday, with : a minor fix to handle the newer boot blocks) that works also : up to -current. Besides, it relies on ports/sysutils/makefs to build : the filesystem image so it can run without superuser privs. : : I know it is not ideal to have a piece of code in the main tree : that depends on an external port. Yet, better than have it broken. : : Now the options are: : : 1. do nothing and leave things broken; : : 2. commit the updated script, fix one or two sample targets, : and remove the others (all of this is in src/release/picobsd) : : 3. remove the entire src/release/picobsd tree and move it to : a port (question - do we want the old content of src/release/picobsd : in ports/foo/picobsd/files ? In any case, we need a place in : some repository to store these things) : : Option #3 is probably the best one, except that the exact 'config' : files are strongly tied to the target source tree you are using, : at least for major releases (libraries differ, application name : change, etc) and so I'd need to modify the script to reach the : templates for RELENG_7, RELENG_6... if they are not already in the : target source tree. Also, this requires a repocopy. : : However given that i don't have a lot of time at the moment, : i would compromise on option #2 for the time being, and move : to option #3 at a later (but unspecified) time. : : comments ? Given how intertwingled picobsd is to the underly OS, I think you are going to have a hard time getting to #3. #2 is fine with me. Warner From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 19:40:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5D1416A49C for ; Tue, 31 Jan 2006 19:40:25 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 395B343D46 for ; Tue, 31 Jan 2006 19:40:25 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by zproxy.gmail.com with SMTP id f1so1374923nzc for ; Tue, 31 Jan 2006 11:40:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=UMVWr0FRmsC9z5wbos5H/sGp6knYmNatQgqf6ldK1VNx7pTJgmcx1a3P3GASXcEgxfPcnihyiJLPlkWWwdSmxrteYZnmuw7e8n0Zhh5fC8o/E6L6dD8xEv7q3w5UauU2KdMPOjriYfrHirzNnMtYBLKlzRgp/wqibYN0FxNXKHI= Received: by 10.65.119.5 with SMTP id w5mr1842900qbm; Tue, 31 Jan 2006 11:40:24 -0800 (PST) Received: by 10.65.252.17 with HTTP; Tue, 31 Jan 2006 11:40:24 -0800 (PST) Message-ID: <47d0403c0601311140q4d65c48eq1eecec873ce38be9@mail.gmail.com> Date: Tue, 31 Jan 2006 19:40:24 +0000 From: Ben Kaduk To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6850_2627400.1138736424401" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: bfe watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 19:40:27 -0000 ------=_Part_6850_2627400.1138736424401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, I know that this is not a very helpful report, but I am hoping that someone might be able to give me help tracking down the root cause. In the past couple of weeks, I have started getting these messages on the console: bfe0: watchdog timeout -- resetting I dismissed the first one as a fluke, but after upgrading my world again, t= o one from January 29th, I have now gotten three more appearances of this message. Does anyone have any thoughts about this? I have tried looking into the code, but it quickly got to a point that was out of the scope of what I have time for at the moment. some system details: bash-2.05b$ uname -a FreeBSD prolepsis.urh.uiuc.edu 7.0-CURRENT FreeBSD 7.0-CURRENT #20: Sun Jan 29 15:09:06 UTC 2006 =20 kaduk@prolepsis.urh.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS i386 dmesg is (hopefully) attached (assuming the list doesn't eat it). Thanks, Ben Kaduk ------=_Part_6850_2627400.1138736424401 Content-Type: application/octet-stream; name="dmesg.boot" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.boot" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDYgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDcuMC1DVVJSRU5UICMyMDogU3VuIEphbiAyOSAxNTowOTow NiBVVEMgMjAwNgogICAga2FkdWtAcHJvbGVwc2lzLnVyaC51aXVjLmVkdTovdXNyL29iai91c3Iv c3JjL3N5cy9QUk9MRVBTSVMKV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0 IHJlZHVjZWQgcGVyZm9ybWFuY2UuClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMx ODIgSHogcXVhbGl0eSAwCkNQVTogTW9iaWxlIEludGVsKFIpIFBlbnRpdW0oUikgNCAtIE0gQ1BV IDIuNTBHSHogKDI0OTIuNjgtTUh6IDY4Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJ bnRlbCIgIElkID0gMHhmMjkgIFN0ZXBwaW5nID0gOQogIEZlYXR1cmVzPTB4YmZlYmY5ZmY8RlBV LFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFU LFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4K ICBGZWF0dXJlczI9MHg0NDAwPENOVFgtSUQsPGIxND4+CnJlYWwgbWVtb3J5ICA9IDEwNzM0MDU5 NTIgKDEwMjMgTUIpCmF2YWlsIG1lbW9yeSA9IDEwNDEzNzUyMzIgKDk5MyBNQikKbnB4MDogW0ZB U1RdCm5weDA6IDxtYXRoIHByb2Nlc3Nvcj4gb24gbW90aGVyYm9hcmQKbnB4MDogSU5UIDE2IGlu dGVyZmFjZQphY3BpMDogPERFTEwgQ1BpIFIgID4gb24gbW90aGVyYm9hcmQKVGltZWNvdW50ZXIg IkFDUEktc2FmZSIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIw OiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ODA4LTB4ODBiIG9uIGFjcGkw CmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNwaV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJv dHRsaW5nPiBvbiBjcHUwCmFjcGlfYWNhZDA6IDxBQyBBZGFwdGVyPiBvbiBhY3BpMApiYXR0ZXJ5 MDogPEFDUEkgQ29udHJvbCBNZXRob2QgQmF0dGVyeT4gb24gYWNwaTAKYmF0dGVyeTE6IDxBQ1BJ IENvbnRyb2wgTWV0aG9kIEJhdHRlcnk+IG9uIGFjcGkwCmFjcGlfbGlkMDogPENvbnRyb2wgTWV0 aG9kIExpZCBTd2l0Y2g+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24g YWNwaTAKYWNwaV9idXR0b24xOiA8U2xlZXAgQnV0dG9uPiBvbiBhY3BpMApwY2liMDogPEFDUEkg SG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaV9saW5rMTogQklP UyBJUlEgMTEgZm9yIDAuMzEuSU5UQiBpcyBpbnZhbGlkCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIwCmFncDA6IDxJbnRlbCA4Mjg0NSBob3N0IHRvIEFHUCBicmlkZ2U+IG9uIGhvc3RiMApw Y2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4g bWVtIDB4ZmMwMDAwMDAtMHhmY2ZmZmZmZiwweGYwMDAwMDAwLTB4ZjNmZmZmZmYgaXJxIDExIGF0 IGRldmljZSAwLjAgb24gcGNpMQp1aGNpMDogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250 cm9sbGVyIFVTQi1BPiBwb3J0IDB4YmY4MC0weGJmOWYgaXJxIDExIGF0IGRldmljZSAyOS4wIG9u IHBjaTAKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBV U0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTAKdXNiMDogVVNCIHJldmlzaW9uIDEuMAp1aHVi MDogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEK dWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kxOiA8SW50 ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBvcnQgMHhiZjQwLTB4YmY1 ZiBpcnEgMTEgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1aGNpMTogW0dJQU5ULUxPQ0tFRF0KdXNi MTogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBvbiB1aGNpMQp1 c2IxOiBVU0IgcmV2aXNpb24gMS4wCnVodWIxOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5 LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKdWhjaTI6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0IgY29udHJvbGxl ciBVU0ItQz4gcG9ydCAweGJmMjAtMHhiZjNmIGlycSAxMSBhdCBkZXZpY2UgMjkuMiBvbiBwY2kw CnVoY2kyOiBbR0lBTlQtTE9DS0VEXQp1c2IyOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNv bnRyb2xsZXIgVVNCLUM+IG9uIHVoY2kyCnVzYjI6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjI6IElu dGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIy OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMDogPEludGVsIDgy ODAxREIvTC9NIChJQ0g0KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGY0ZmZmYzAwLTB4ZjRm ZmZmZmYgaXJxIDExIGF0IGRldmljZSAyOS43IG9uIHBjaTAKZWhjaTA6IFtHSUFOVC1MT0NLRURd CnVzYjM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNiMzogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAyIHBv cnRzIGVhY2g6IHVzYjAgdXNiMSB1c2IyCnVzYjM6IDxJbnRlbCA4MjgwMURCL0wvTSAoSUNINCkg VVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMAp1c2IzOiBVU0IgcmV2aXNpb24gMi4wCnVodWIz OiBJbnRlbCBFSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMQp1 aHViMzogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKcGNpYjI6IDxBQ1BJ IFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaV9saW5rMTogQklPUyBJ UlEgMTEgZm9yIDIuMy5JTlRBIGlzIGludmFsaWQKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNp YjIKYmZlMDogPEJyb2FkY29tIEJDTTQ0MDEgRmFzdCBFdGhlcm5ldD4gbWVtIDB4ZmFmZmUwMDAt MHhmYWZmZmZmZiBpcnEgMTEgYXQgZGV2aWNlIDAuMCBvbiBwY2kyCm1paWJ1czA6IDxNSUkgYnVz PiBvbiBiZmUwCmJtdHBoeTA6IDxCQ000NDAxIDEwLzEwMGJhc2VUWCBQSFk+IG9uIG1paWJ1czAK Ym10cGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgs IGF1dG8KYmZlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MGI6ZGI6OTk6ZTg6YzcKY2JiMDogPFRJ NDUxMCBQQ0ktQ2FyZEJ1cyBCcmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMgpjYXJkYnVzMDog PENhcmRCdXMgYnVzPiBvbiBjYmIwCnBjY2FyZDA6IDwxNi1iaXQgUENDYXJkIGJ1cz4gb24gY2Ji MApmd29oY2kwOiA8MTM5NCBPcGVuIEhvc3QgQ29udHJvbGxlciBJbnRlcmZhY2U+IG1lbSAweGZh ZmZkODAwLTB4ZmFmZmRmZmYsMHhmYWZmODAwMC0weGZhZmZiZmZmIGlycSAxMSBhdCBkZXZpY2Ug MS4xIG9uIHBjaTIKZndvaGNpMDogT0hDSSB2ZXJzaW9uIDEuMTAgKFJPTT0wKQpmd29oY2kwOiBO by4gb2YgSXNvY2hyb25vdXMgY2hhbm5lbHMgaXMgNC4KZndvaGNpMDogRVVJNjQgNDY6NGY6YzA6 MDA6MWQ6MmY6MWM6NjEKZndvaGNpMDogUGh5IDEzOTRhIGF2YWlsYWJsZSBTNDAwLCAyIHBvcnRz Lgpmd29oY2kwOiBMaW5rIFM0MDAsIG1heF9yZWMgMjA0OCBieXRlcy4KZmlyZXdpcmUwOiA8SUVF RTEzOTQoRmlyZVdpcmUpIGJ1cz4gb24gZndvaGNpMApzYnAwOiA8U0JQLTIvU0NTSSBvdmVyIEZp cmVXaXJlPiBvbiBmaXJld2lyZTAKZndvaGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0CmZ3b2hjaTA6 IG5vZGVfaWQ9MHhjODAwZmZjMCwgZ2VuPTEsIENZQ0xFTUFTVEVSIG1vZGUKZmlyZXdpcmUwOiAx IG5vZGVzLCBtYXhob3AgPD0gMCwgY2FibGUgSVJNID0gMCAobWUpCmZpcmV3aXJlMDogYnVzIG1h bmFnZXIgMCAobWUpCnBjaTI6IDxuZXR3b3JrPiBhdCBkZXZpY2UgMy4wIChubyBkcml2ZXIgYXR0 YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNh MDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBJQ0g0IFVETUExMDAgY29udHJv bGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGJmYTAtMHhi ZmFmIGF0IGRldmljZSAzMS4xIG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBj aTAKYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKcGNpMDogPG11bHRpbWVkaWEsIGF1 ZGlvPiBhdCBkZXZpY2UgMzEuNSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8c2ltcGxlIGNv bW1zLCBnZW5lcmljIG1vZGVtPiBhdCBkZXZpY2UgMzEuNiAobm8gZHJpdmVyIGF0dGFjaGVkKQph Y3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRy b2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQg S2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQt TE9DS0VEXQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5U LUxPQ0tFRF0KcHNtMDogbW9kZWwgR2xpZGVQb2ludCwgZGV2aWNlIElEIDAKc2lvMDogPDE2NTUw QS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIGZsYWdzIDB4MTAg b24gYWNwaTAKc2lvMDogdHlwZSAxNjU1MEEKcHBjMDogPEVDUCBwYXJhbGxlbCBwcmludGVyIHBv cnQ+IHBvcnQgMHgzNzgtMHgzN2YsMHg3NzgtMHg3N2IgaXJxIDcgZHJxIDEgb24gYWNwaTAKcHBj MDogU01DLWxpa2UgY2hpcHNldCAoRUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1v ZGUKcHBjMDogRklGTyB3aXRoIDE2LzE2LzggYnl0ZXMgdGhyZXNob2xkCnBwYnVzMDogPFBhcmFs bGVsIHBvcnQgYnVzPiBvbiBwcGMwCnBsaXAwOiA8UExJUCBuZXR3b3JrIGludGVyZmFjZT4gb24g cHBidXMwCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRyaXZlbiBw b3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMApwbXRpbWVyMCBvbiBpc2EwCm9ybTA6 IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjZjdmZiwweGNmODAwLTB4Y2Zm ZmYgcG5waWQgT1JNMDAwMCBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAw eDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4K dmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAw LTB4YmZmZmYgb24gaXNhMAp1bXMwOiBMb2dpdGVjaCBPcHRpY2FsIFVTQiBNb3VzZSwgcmV2IDIu MDAvMy40MCwgYWRkciAyLCBpY2xhc3MgMy8xCnVtczA6IDMgYnV0dG9ucyBhbmQgWiBkaXIuClRp bWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAyNDkyNjc2MTY2IEh6IHF1YWxpdHkgODAwClRpbWVj b3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKc2lvNDogPElCTSA1NksgRGF0YS1GYXggTW9k ZW0+IGF0IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDExIGZ1bmN0aW9uIDAgY29uZmlnIDMyIG9uIHBj Y2FyZDAKc2lvNDogdHlwZSAxNjU1MEEKc2lvNDogdW5hYmxlIHRvIGFjdGl2YXRlIGludGVycnVw dCBpbiBmYXN0IG1vZGUgLSB1c2luZyBub3JtYWwgbW9kZQphZDA6IDc2MzE5TUIgPElDMjVOMDgw QVRNUjA0IDAgTU80T0FEMEE+IGF0IGF0YTAtbWFzdGVyIFVETUExMDAKYWNkMDogQ0RSVyA8TUFU U0hJVEEgQ0QtUlcvRFZELVJPTSBVSkRBNzQwLzEuMDM+IGF0IGF0YTEtbWFzdGVyIFVETUEzMwpU cnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMzYQpiZmUwOiB3YXRjaGRvZyB0 aW1lb3V0IC0tIHJlc2V0dGluZwpiZmUwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgpiZmUw OiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKYmZlMDogd2F0Y2hkb2cgdGltZW91dCAtLSByZXNl dHRpbmcKYmZlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KYmZlMDogbGluayBzdGF0ZSBj aGFuZ2VkIHRvIFVQCmJmZTA6IHdhdGNoZG9nIHRpbWVvdXQgLS0gcmVzZXR0aW5nCmJmZTA6IGxp bmsgc3RhdGUgY2hhbmdlZCB0byBET1dOCmJmZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAo= ------=_Part_6850_2627400.1138736424401-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 19:56:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3656D16A420; Tue, 31 Jan 2006 19:56:08 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A9E543D45; Tue, 31 Jan 2006 19:56:06 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4D46246BE7; Tue, 31 Jan 2006 14:55:57 -0500 (EST) Date: Tue, 31 Jan 2006 19:57:57 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20060131.121559.127178102.imp@bsdimp.com> Message-ID: <20060131195637.U95776@fledge.watson.org> References: <20060131105224.A57698@xorpc.icir.org> <20060131.121559.127178102.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rizzo@icir.org, current@freebsd.org, small@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 19:56:08 -0000 On Tue, 31 Jan 2006, M. Warner Losh wrote: > Given how intertwingled picobsd is to the underly OS, I think you are going > to have a hard time getting to #3. #2 is fine with me. My feelings here are pretty much the same -- I'm skeptical about the continued ability to maintain PicoBSD outside CVS in a long-term way, given tight integration with the source tree. People can and do maintain there own versions of FreeBSD releases and wrappers (FreeSBIE is presumably the most successful example), but it's a lot of work, and if there's trouble finding enough hands for the current PicoBSD, it doesn't seem likely it will get more hands somewhere else. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 20:03:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F61116A422; Tue, 31 Jan 2006 20:03:13 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C3BC43D5C; Tue, 31 Jan 2006 20:03:08 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id k0VK2to7006930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2006 12:02:56 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <43DFC2D5.7040706@errno.com> Date: Tue, 31 Jan 2006 12:04:37 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051227) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20060131105224.A57698@xorpc.icir.org> <20060131.121559.127178102.imp@bsdimp.com> <20060131195637.U95776@fledge.watson.org> In-Reply-To: <20060131195637.U95776@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rizzo@icir.org, current@freebsd.org, "M. Warner Losh" , small@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 20:03:13 -0000 Robert Watson wrote: > > On Tue, 31 Jan 2006, M. Warner Losh wrote: > >> Given how intertwingled picobsd is to the underly OS, I think you are >> going to have a hard time getting to #3. #2 is fine with me. > > > My feelings here are pretty much the same -- I'm skeptical about the > continued ability to maintain PicoBSD outside CVS in a long-term way, > given tight integration with the source tree. People can and do > maintain there own versions of FreeBSD releases and wrappers (FreeSBIE > is presumably the most successful example), but it's a lot of work, and > if there's trouble finding enough hands for the current PicoBSD, it > doesn't seem likely it will get more hands somewhere else. My derivative of thewall project is similar to picobsd in it's approach and it might be worth combining the two. I've kept mine reasonably up to date and believe it works for 4.x, 5.x, and 6.x systems. Sam From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 20:05:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F2EE16A420; Tue, 31 Jan 2006 20:05:33 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E29643D6B; Tue, 31 Jan 2006 20:05:28 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k0VK5CNe036373; Tue, 31 Jan 2006 13:05:12 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 31 Jan 2006 13:05:24 -0700 (MST) Message-Id: <20060131.130524.66709261.imp@bsdimp.com> To: rwatson@freebsd.org From: "M. Warner Losh" In-Reply-To: <20060131195637.U95776@fledge.watson.org> References: <20060131105224.A57698@xorpc.icir.org> <20060131.121559.127178102.imp@bsdimp.com> <20060131195637.U95776@fledge.watson.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 31 Jan 2006 13:05:13 -0700 (MST) Cc: rizzo@icir.org, current@freebsd.org, small@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 20:05:33 -0000 In message: <20060131195637.U95776@fledge.watson.org> Robert Watson writes: : : On Tue, 31 Jan 2006, M. Warner Losh wrote: : : > Given how intertwingled picobsd is to the underly OS, I think you are going : > to have a hard time getting to #3. #2 is fine with me. : : My feelings here are pretty much the same -- I'm skeptical about the continued : ability to maintain PicoBSD outside CVS in a long-term way, given tight : integration with the source tree. People can and do maintain there own : versions of FreeBSD releases and wrappers (FreeSBIE is presumably the most : successful example), but it's a lot of work, and if there's trouble finding : enough hands for the current PicoBSD, it doesn't seem likely it will get more : hands somewhere else. Our company maintains its own release tools that would fall somewhere between PicoBSD and NanoBSD. We've tried very hard to make them version independent, but it is a constant struggle. Warner From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 20:17:41 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E336A16A420; Tue, 31 Jan 2006 20:17:41 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 716CC43D53; Tue, 31 Jan 2006 20:17:41 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k0VKGgqL036518; Tue, 31 Jan 2006 13:16:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 31 Jan 2006 13:16:54 -0700 (MST) Message-Id: <20060131.131654.134137067.imp@bsdimp.com> To: sam@errno.com From: "M. Warner Losh" In-Reply-To: <43DFC2D5.7040706@errno.com> References: <20060131.121559.127178102.imp@bsdimp.com> <20060131195637.U95776@fledge.watson.org> <43DFC2D5.7040706@errno.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 31 Jan 2006 13:16:43 -0700 (MST) Cc: rizzo@icir.org, rwatson@freebsd.org, current@freebsd.org, small@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 20:17:42 -0000 In message: <43DFC2D5.7040706@errno.com> Sam Leffler writes: : Robert Watson wrote: : > : > On Tue, 31 Jan 2006, M. Warner Losh wrote: : > : >> Given how intertwingled picobsd is to the underly OS, I think you are : >> going to have a hard time getting to #3. #2 is fine with me. : > : > : > My feelings here are pretty much the same -- I'm skeptical about the : > continued ability to maintain PicoBSD outside CVS in a long-term way, : > given tight integration with the source tree. People can and do : > maintain there own versions of FreeBSD releases and wrappers (FreeSBIE : > is presumably the most successful example), but it's a lot of work, and : > if there's trouble finding enough hands for the current PicoBSD, it : > doesn't seem likely it will get more hands somewhere else. : : My derivative of thewall project is similar to picobsd in it's approach : and it might be worth combining the two. I've kept mine reasonably up : to date and believe it works for 4.x, 5.x, and 6.x systems. Since I've started working on the bring up on an ARM based board, I've been wanting something that is easy to work with and that worked. I think it would help us a lot in the embedded space if we had something integrated into the base OS to do this stuff. Warner From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 20:29:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCE3E16A422; Tue, 31 Jan 2006 20:29:34 +0000 (GMT) (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 DADE043D69; Tue, 31 Jan 2006 20:29:28 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k0VKTFgt059028; Tue, 31 Jan 2006 12:29:15 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k0VKTF1F059027; Tue, 31 Jan 2006 12:29:15 -0800 (PST) (envelope-from rizzo) Date: Tue, 31 Jan 2006 12:29:15 -0800 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20060131122915.A58955@xorpc.icir.org> References: <20060131.121559.127178102.imp@bsdimp.com> <20060131195637.U95776@fledge.watson.org> <43DFC2D5.7040706@errno.com> <20060131.131654.134137067.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060131.131654.134137067.imp@bsdimp.com>; from imp@bsdimp.com on Tue, Jan 31, 2006 at 01:16:54PM -0700 Cc: rwatson@freebsd.org, current@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 20:29:34 -0000 ok give the response i have committed the script so people can give a try. I have only used it to build i386 images, if others can give a try to other platforms that would be great. Sam if you want to point me at what you have, i can try to look at it and see what to do. cheers luigi On Tue, Jan 31, 2006 at 01:16:54PM -0700, M. Warner Losh wrote: > In message: <43DFC2D5.7040706@errno.com> > sAM Leffler writes: > : Robert Watson wrote: > : > > : > On Tue, 31 Jan 2006, M. Warner Losh wrote: ... > : >> gIVEN HOW Intertwingled picobsd is to the underly OS, I think you are > : >> going to have a hard time getting to #3. #2 is fine with me. ... > : > My feelings here are pretty much the same -- I'm skeptical about the ... > : My derivative of thewall project is similar to picobsd in it's approach > : and it might be worth combining the two. I've kept mine reasonably up > : to date and believe it works for 4.x, 5.x, and 6.x systems. > > Since I've started working on the bring up on an ARM based board, I've > been wanting something that is easy to work with and that worked. I > think it would help us a lot in the embedded space if we had something > integrated into the base OS to do this stuff. > > Warner > _______________________________________________ > freebsd-small@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-small > To unsubscribe, send any mail to "freebsd-small-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 21:15:47 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8576A16A420 for ; Tue, 31 Jan 2006 21:15:47 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFE5743D81 for ; Tue, 31 Jan 2006 21:15:40 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 31 Jan 2006 13:15:41 -0800 Message-ID: <43DFD37C.70306@elischer.org> Date: Tue, 31 Jan 2006 13:15:40 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Peter talks tomorrow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 21:15:47 -0000 The Bay area FreeBSD User's Group has coerc^H^H^H^H^Hasked Peter Wemm to tell us about FreeBSD and the AMD64.. I will attempt to broadcast it.. I just tested it from Australia, so some others may be able to join us and make fun^H^H^H^H^H^H^H ask questions. TIMES are in PST (currently UTC-8) I'll put the recording up on www.freebsd.org as per usual for thise who can't make it. check www.bafug.org.. julian --BAFUG announcement follows-- Peter Wemm will be there to answer all your questions on running FreeBSD on the AMD-64/EMT-64 64-bit architecture machines. I will be broadcasting the talk and questions at: rtsp://kumr2.lns.com/bafug-live.sdp (about 20 seconds delay I think from last time.) I suggest Quicktime or VLC to watch it. Others may work too, I don't know. We will try have the IRC channel on efnet #bafug. So join us virtually even if you can't get there. You can have someone ask your questions using the IRC channel. From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 21:22:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E197F16A420 for ; Tue, 31 Jan 2006 21:22:11 +0000 (GMT) (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 5FF6B43D70 for ; Tue, 31 Jan 2006 21:22:10 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k0VLMAxk000955 for ; Tue, 31 Jan 2006 13:22:10 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k0VLMAi4000954 for freebsd-current@freebsd.org; Tue, 31 Jan 2006 13:22:10 -0800 (PST) (envelope-from sgk) Date: Tue, 31 Jan 2006 13:22:09 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20060131212209.GA870@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 21:22:12 -0000 The system is a dual proc Tyan K8S Pro with 12 GB of memory. The kernel is UP. This was recorded by hand. I have the crash dump. Memory modified after free 0xffffff02505e0c00(504) val=deadc0dd @ 0xffffff02505e0cd0 panic: Most recently used by DEVFS1 KDB: stack backtrace kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x164 mtrash_ctor() at mtrash_ctor+0x70 uma_zalloc_arg() at uma_zalloc_arg+0x170 malloc() at malloc+0xf5 fdinit() at fdinit+0x20 fdcopy() at fdcopy+0x21 fork1() at fork1+0x624 vfork() at vork+0x1f syscall() at syscall+0x350 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall(66, FreeBSD ELF64, vfork), rip = 0x2006aa6d, rsp=0x7ffffffdac0, rbp = 0 --- Hmmm.... troutmask:root[259] gdb /boot/kernel/kernel vmcore.0 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"... warning: "/usr/tmp/vmcore.0": no core file handler recognizes format, using defa ult Can't fetch registers from this type of core file Can't fetch registers from this type of core file #0 0x0000000000000000 in ?? () -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 21:23:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DF3016A420; Tue, 31 Jan 2006 21:23:33 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F04B43D7F; Tue, 31 Jan 2006 21:23:20 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x535c0e2a.sgnxx1.adsl-dhcp.tele.dk [83.92.14.42]) by pasmtp.tele.dk (Postfix) with ESMTP id 9B3B91EC30C; Tue, 31 Jan 2006 22:23:04 +0100 (CET) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.4/8.13.4) with ESMTP id k0VLMw8w003282; Tue, 31 Jan 2006 21:22:59 GMT (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 31 Jan 2006 13:16:54 MST." <20060131.131654.134137067.imp@bsdimp.com> Date: Tue, 31 Jan 2006 21:22:58 +0000 Message-ID: <3281.1138742578@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: small@freebsd.org, rwatson@freebsd.org, current@freebsd.org, rizzo@icir.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 21:23:33 -0000 In message <20060131.131654.134137067.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <43DFC2D5.7040706@errno.com> > Sam Leffler writes: >Since I've started working on the bring up on an ARM based board, I've >been wanting something that is easy to work with and that worked. I >think it would help us a lot in the embedded space if we had something >integrated into the base OS to do this stuff. I agree. I think we need to be much more inclusive in our concept of a 'release' than we are now. As I see it, PicoBSD with its "additive" approach would cover the low-capacity (<32 MB ?) range, NanoBSD with its "subtractive" approach takes over from there, FreeSBIE covers the "don't touch my disk" range and finally the full blown release as we know it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 21:29:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77EA816A43E; Tue, 31 Jan 2006 21:28:59 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15FC143D45; Tue, 31 Jan 2006 21:28:57 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 31 Jan 2006 13:28:57 -0800 Message-ID: <43DFD698.7040508@elischer.org> Date: Tue, 31 Jan 2006 13:28:56 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <3281.1138742578@critter.freebsd.dk> In-Reply-To: <3281.1138742578@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: rizzo@icir.org, rwatson@freebsd.org, small@freebsd.org, "M. Warner Losh" , current@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 21:29:00 -0000 Poul-Henning Kamp wrote: >In message <20060131.131654.134137067.imp@bsdimp.com>, "M. Warner Losh" writes: > > >>In message: <43DFC2D5.7040706@errno.com> >> Sam Leffler writes: >> >> > > > >>Since I've started working on the bring up on an ARM based board, I've >>been wanting something that is easy to work with and that worked. I >>think it would help us a lot in the embedded space if we had something >>integrated into the base OS to do this stuff. >> >> > >I agree. I think we need to be much more inclusive in our concept of >a 'release' than we are now. > >As I see it, PicoBSD with its "additive" approach would cover the >low-capacity (<32 MB ?) range, NanoBSD with its "subtractive" approach >takes over from there, FreeSBIE covers the "don't touch my disk" >range and finally the full blown release as we know it. > > I'd like to see us take the freesbie release into the tree somewhere (since it uses so many ports, maybe in ports, or maybe in tools) From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 21:33:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FACF16A422 for ; Tue, 31 Jan 2006 21:33:47 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AEC343D5F for ; Tue, 31 Jan 2006 21:33:36 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id BA5781A3C20; Tue, 31 Jan 2006 13:33:36 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6EC095361C; Tue, 31 Jan 2006 16:33:33 -0500 (EST) Date: Tue, 31 Jan 2006 16:33:32 -0500 From: Kris Kennaway To: Steve Kargl Message-ID: <20060131213332.GA15250@xor.obsecurity.org> References: <20060131212209.GA870@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <20060131212209.GA870@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 21:33:47 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote: > The system is a dual proc Tyan K8S Pro with 12 GB of memory. > The kernel is UP. This was recorded by hand. I have the crash dump. >=20 > Memory modified after free 0xffffff02505e0c00(504) val=3Ddeadc0dd @ > 0xffffff02505e0cd0 >=20 > panic: Most recently used by DEVFS1 Set up memguard to watch this malloc type in order to obtain useful debugging. Kris --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD39eqWry0BWjoQKURAuESAKDiErtTqHCHGRy/EgHFdCuWiJ+JOwCfZHaY EpRvQR8i9ruNXmPTwSobK4g= =/v3d -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 21:35:32 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F0C016A422; Tue, 31 Jan 2006 21:35:32 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A65C43D68; Tue, 31 Jan 2006 21:35:27 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k0VLYg1S039908; Tue, 31 Jan 2006 14:34:43 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 31 Jan 2006 14:34:54 -0700 (MST) Message-Id: <20060131.143454.76964518.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <3281.1138742578@critter.freebsd.dk> References: <20060131.131654.134137067.imp@bsdimp.com> <3281.1138742578@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 31 Jan 2006 14:34:43 -0700 (MST) Cc: small@freebsd.org, rwatson@freebsd.org, current@freebsd.org, rizzo@icir.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 21:35:32 -0000 In message: <3281.1138742578@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20060131.131654.134137067.imp@bsdimp.com>, "M. Warner Losh" writes: : >In message: <43DFC2D5.7040706@errno.com> : > Sam Leffler writes: : : >Since I've started working on the bring up on an ARM based board, I've : >been wanting something that is easy to work with and that worked. I : >think it would help us a lot in the embedded space if we had something : >integrated into the base OS to do this stuff. : : I agree. I think we need to be much more inclusive in our concept of : a 'release' than we are now. : : As I see it, PicoBSD with its "additive" approach would cover the : low-capacity (<32 MB ?) range, NanoBSD with its "subtractive" approach : takes over from there, FreeSBIE covers the "don't touch my disk" : range and finally the full blown release as we know it. I tend to agree. For our build system, we take the additive approach without the crunchgen step... Given the price points for various parts on new projects I'm working on, we may need to move more towards a crunchgen and/or pure RAM disk... Having different alternatives helps us a lot and makes it easy to continue to deploy FreeBSD systems. Warner From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 21:38:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 759E816A420 for ; Tue, 31 Jan 2006 21:38:40 +0000 (GMT) (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 A8B9743D66 for ; Tue, 31 Jan 2006 21:38:34 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k0VLcYeh001337; Tue, 31 Jan 2006 13:38:34 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k0VLcYVk001336; Tue, 31 Jan 2006 13:38:34 -0800 (PST) (envelope-from sgk) Date: Tue, 31 Jan 2006 13:38:34 -0800 From: Steve Kargl To: Kris Kennaway Message-ID: <20060131213834.GA1080@troutmask.apl.washington.edu> References: <20060131212209.GA870@troutmask.apl.washington.edu> <20060131213332.GA15250@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060131213332.GA15250@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 21:38:40 -0000 On Tue, Jan 31, 2006 at 04:33:32PM -0500, Kris Kennaway wrote: > On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote: > > The system is a dual proc Tyan K8S Pro with 12 GB of memory. > > The kernel is UP. This was recorded by hand. I have the crash dump. > > > > Memory modified after free 0xffffff02505e0c00(504) val=deadc0dd @ > > 0xffffff02505e0cd0 > > > > panic: Most recently used by DEVFS1 > > Set up memguard to watch this malloc type in order to obtain useful > debugging. > OK, I've read the memguard manpage and it says to add vm.memguard.desc= to /boot/loader.conf. Where to I get info for what actually means? -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 21:45:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D02C16A420; Tue, 31 Jan 2006 21:45:23 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 249B743D45; Tue, 31 Jan 2006 21:45:23 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 0A9671A3C20; Tue, 31 Jan 2006 13:45:23 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5C326513C7; Tue, 31 Jan 2006 16:45:22 -0500 (EST) Date: Tue, 31 Jan 2006 16:45:22 -0500 From: Kris Kennaway To: Steve Kargl Message-ID: <20060131214522.GA15709@xor.obsecurity.org> References: <20060131212209.GA870@troutmask.apl.washington.edu> <20060131213332.GA15250@xor.obsecurity.org> <20060131213834.GA1080@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <20060131213834.GA1080@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, pjd@FreeBSD.org, Kris Kennaway Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 21:45:23 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2006 at 01:38:34PM -0800, Steve Kargl wrote: > On Tue, Jan 31, 2006 at 04:33:32PM -0500, Kris Kennaway wrote: > > On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote: > > > The system is a dual proc Tyan K8S Pro with 12 GB of memory. > > > The kernel is UP. This was recorded by hand. I have the crash dump. > > >=20 > > > Memory modified after free 0xffffff02505e0c00(504) val=3Ddeadc0dd @ > > > 0xffffff02505e0cd0 > > >=20 > > > panic: Most recently used by DEVFS1 > >=20 > > Set up memguard to watch this malloc type in order to obtain useful > > debugging. > >=20 >=20 > OK, I've read the memguard manpage and it says to add >=20 > vm.memguard.desc=3D >=20 > to /boot/loader.conf. Where to I get info for what > actually means? Look at the relevant MALLOC_DEFINE() in the source, it's the second field (see malloc(9)). This should probably be clarified in the memguard manpage. Kris --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD39pyWry0BWjoQKURAqhSAJ4/G+wGt6Do8QGU2HPU8wWeQ+9E3gCgpMnP tmjWnzH/IM3/cHH6wp9AqTI= =TWvN -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 21:54:18 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39ECA16A420 for ; Tue, 31 Jan 2006 21:54:18 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9061F43D4C for ; Tue, 31 Jan 2006 21:54:17 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from circe (circe.rz.RWTH-Aachen.DE [134.130.3.36]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ITZ008DH8NYGK@ms-dienst.rz.rwth-aachen.de> for freebsd-current@freebsd.org; Tue, 31 Jan 2006 22:50:23 +0100 (MET) Received: from talos.rz.RWTH-Aachen.DE ([134.130.3.22]) by circe (MailMonitor for SMTP v1.2.2 ) ; Tue, 31 Jan 2006 22:50:22 +0100 (MET) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.1/8.13.1/1) with ESMTP id k0VLoL9Y016989; Tue, 31 Jan 2006 22:50:21 +0100 Received: from lorien.hitnet.rwth-aachen.de ([137.226.181.92] helo=haakonia.hitnet.rwth-aachen.de) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1F43OI-0004IK-3P; Tue, 31 Jan 2006 22:50:22 +0100 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id E79A13F42C; Tue, 31 Jan 2006 22:50:21 +0100 (CET) Date: Tue, 31 Jan 2006 22:50:21 +0100 From: Christian Brueffer In-reply-to: <20060131212209.GA870@troutmask.apl.washington.edu> To: Steve Kargl Message-id: <20060131215021.GG4395@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; boundary=Wtrm9ATX0sn6fFKv; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.11 X-Operating-System: FreeBSD 6.0-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: <20060131212209.GA870@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 21:54:18 -0000 --Wtrm9ATX0sn6fFKv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote: > The system is a dual proc Tyan K8S Pro with 12 GB of memory. > The kernel is UP. This was recorded by hand. I have the crash dump. >=20 > Memory modified after free 0xffffff02505e0c00(504) val=3Ddeadc0dd @ > 0xffffff02505e0cd0 >=20 For the record, I got this as well today. Here it was on my notebook at system shutdown. - 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 --Wtrm9ATX0sn6fFKv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD39udbHYXjKDtmC0RAgjUAJ4t/mJPmhIOYyVpcCBFgiY9SCYQOACeNIR0 ZB5cnR7HtDFpH9qDPUx0unY= =A2Kw -----END PGP SIGNATURE----- --Wtrm9ATX0sn6fFKv-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 22:02:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6097A16A420; Tue, 31 Jan 2006 22:02:13 +0000 (GMT) (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 107AD43D48; Tue, 31 Jan 2006 22:02:13 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k0VM2Cl7025167; Tue, 31 Jan 2006 14:02:12 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k0VM2CMZ025166; Tue, 31 Jan 2006 14:02:12 -0800 (PST) (envelope-from sgk) Date: Tue, 31 Jan 2006 14:02:12 -0800 From: Steve Kargl To: Kris Kennaway Message-ID: <20060131220212.GA23528@troutmask.apl.washington.edu> References: <20060131212209.GA870@troutmask.apl.washington.edu> <20060131213332.GA15250@xor.obsecurity.org> <20060131213834.GA1080@troutmask.apl.washington.edu> <20060131214522.GA15709@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060131214522.GA15709@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, pjd@freebsd.org Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 22:02:13 -0000 On Tue, Jan 31, 2006 at 04:45:22PM -0500, Kris Kennaway wrote: > On Tue, Jan 31, 2006 at 01:38:34PM -0800, Steve Kargl wrote: > > On Tue, Jan 31, 2006 at 04:33:32PM -0500, Kris Kennaway wrote: > > > On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote: > > > > The system is a dual proc Tyan K8S Pro with 12 GB of memory. > > > > The kernel is UP. This was recorded by hand. I have the crash dump. > > > > > > > > Memory modified after free 0xffffff02505e0c00(504) val=deadc0dd @ > > > > 0xffffff02505e0cd0 > > > > > > > > panic: Most recently used by DEVFS1 > > > > > > Set up memguard to watch this malloc type in order to obtain useful > > > debugging. > > > > > > > OK, I've read the memguard manpage and it says to add > > > > vm.memguard.desc= > > > > to /boot/loader.conf. Where to I get info for what > > actually means? > > Look at the relevant MALLOC_DEFINE() in the source, it's the second > field (see malloc(9)). This should probably be clarified in the > memguard manpage. > Thanks. I've found the memory_type, and I rebuilding a kernel now with DEBUG_MEMGUARD. I can get the system to panic with 5 minutes, so I should have more information shortly. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 22:11:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 334C116A420 for ; Tue, 31 Jan 2006 22:11:40 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id D674B43D58 for ; Tue, 31 Jan 2006 22:11:33 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 25F765175B; Tue, 31 Jan 2006 23:11:32 +0100 (CET) Received: from localhost (dlm194.neoplus.adsl.tpnet.pl [83.24.42.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A42B650A79; Tue, 31 Jan 2006 23:11:25 +0100 (CET) Date: Tue, 31 Jan 2006 23:11:20 +0100 From: Pawel Jakub Dawidek To: Christian Brueffer Message-ID: <20060131220828.GA2953@garage.freebsd.pl> References: <20060131212209.GA870@troutmask.apl.washington.edu> <20060131215021.GG4395@haakonia.hitnet.RWTH-Aachen.DE> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xgyAXRrhYN0wYx8y" Content-Disposition: inline In-Reply-To: <20060131215021.GG4395@haakonia.hitnet.RWTH-Aachen.DE> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 22:11:40 -0000 --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2006 at 10:50:21PM +0100, Christian Brueffer wrote: +> On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote: +> > The system is a dual proc Tyan K8S Pro with 12 GB of memory. +> > The kernel is UP. This was recorded by hand. I have the crash dump. +> >=20 +> > Memory modified after free 0xffffff02505e0c00(504) val=3Ddeadc0dd @ +> > 0xffffff02505e0cd0 +> >=20 +>=20 +> For the record, I got this as well today. Here it was on my notebook +> at system shutdown. Cool, so you have a chance to try memguard(9) and verify my patch to manual page:) --- memguard.9 30 Dec 2005 12:28:19 -0000 1.2 +++ memguard.9 31 Jan 2006 22:06:04 -0000 @@ -56,6 +56,9 @@ vm.memguard.desc=3D .Ed .Pp Where memory_type is a short description of memory type to monitor. +The short description of memory type is the second argument to +.Xr MALLOC_DECLARE 9 , +so one has to find it in the kernel source. .Pp To use memguard for memory type defined in a kernel module, one has to set .Va vm.memguard.desc --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --xgyAXRrhYN0wYx8y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD3+CHForvXbEpPzQRAmpnAKDSk0ALSIvFEbaJQCjtCTK78I6VMACg8wnY tOOF7vr97hhpFm1phuq6xHo= =LWO+ -----END PGP SIGNATURE----- --xgyAXRrhYN0wYx8y-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 22:38:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68DAC16A422 for ; Tue, 31 Jan 2006 22:38:23 +0000 (GMT) (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 5DE1C43D58 for ; Tue, 31 Jan 2006 22:38:17 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k0VMcHMr000688; Tue, 31 Jan 2006 14:38:17 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k0VMcHS9000687; Tue, 31 Jan 2006 14:38:17 -0800 (PST) (envelope-from sgk) Date: Tue, 31 Jan 2006 14:38:16 -0800 From: Steve Kargl To: Kris Kennaway Message-ID: <20060131223816.GA587@troutmask.apl.washington.edu> References: <20060131212209.GA870@troutmask.apl.washington.edu> <20060131213332.GA15250@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060131213332.GA15250@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 22:38:23 -0000 On Tue, Jan 31, 2006 at 04:33:32PM -0500, Kris Kennaway wrote: > On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote: > > The system is a dual proc Tyan K8S Pro with 12 GB of memory. > > The kernel is UP. This was recorded by hand. I have the crash dump. > > > > Memory modified after free 0xffffff02505e0c00(504) val=deadc0dd @ > > 0xffffff02505e0cd0 > > > > panic: Most recently used by DEVFS1 > > Set up memguard to watch this malloc type in order to obtain useful > debugging. > memguard has made the situation even worse. The kernel never makes to single user mode. I get MEMGUARD DEBUGGING ALLOCATOR INITIALIZED MEMGUARD map base: 0xffffffff8f1b2000 map limit: 0xffffffff919b3000 map size: 41947136 (Bytes) Memory modified after free 0xffffff000005bd00(248) val=5 @ 0xffffff000005bdd0 kernel trap 9 wiith interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xffffffff80306487 stack pointer = 0x10:0xffffffff807a1a20 frame pointer = 0x10:0xffffffff807a1a30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process: = 0 () [thread pid 0 tid 0] Stopped at strlen+0x7: cmpb $0,0(%rdi) db> bt Tracing pid 0 tid 0 td 0xffffffff8060ac40 strlen() at strlen+0x7 kvprintf() at kvprintf+0x987 vsnprintf() at vsnprintf+0x2e panic() at panic+0xfa mtrash_ctor() at mtrash_ctor+0x70 uma_zalloc_arg() at uma_zalloc_arg+0x170 malloc() at malloc+0x11e init_dynamic_kenv() at init_dynamic_kenv+0x68 mi_startup() at mi_startup+0xb6 btext() at btext+0x2c -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 22:38:29 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E725516A420; Tue, 31 Jan 2006 22:38:29 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDEA443D68; Tue, 31 Jan 2006 22:38:25 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 7433329 for multiple; Tue, 31 Jan 2006 17:38:30 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0VMcNHS087252; Tue, 31 Jan 2006 17:38:23 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: current@freebsd.org Date: Tue, 31 Jan 2006 17:39:26 -0500 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601311739.27980.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1263/Tue Jan 31 09:48:20 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: anholt@freebsd.org Subject: Patch to fix i915 drm with vgapci changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 22:38:30 -0000 This patch uses an identify routine in the agp driver to add the agp child to vgapci instead of having vgapci guess based on the PCIY_AGP capability. Patch is at http://www.FreeBSD.org/~jhb/patches/agp_vgapci.patch -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 22:40:01 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3524F16A420; Tue, 31 Jan 2006 22:40:01 +0000 (GMT) (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 BC26743D45; Tue, 31 Jan 2006 22:40:00 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k0VMe0lQ000704; Tue, 31 Jan 2006 14:40:00 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k0VMe0l1000703; Tue, 31 Jan 2006 14:40:00 -0800 (PST) (envelope-from sgk) Date: Tue, 31 Jan 2006 14:40:00 -0800 From: Steve Kargl To: Pawel Jakub Dawidek Message-ID: <20060131224000.GB587@troutmask.apl.washington.edu> References: <20060131212209.GA870@troutmask.apl.washington.edu> <20060131215021.GG4395@haakonia.hitnet.RWTH-Aachen.DE> <20060131220828.GA2953@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060131220828.GA2953@garage.freebsd.pl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 22:40:01 -0000 On Tue, Jan 31, 2006 at 11:11:20PM +0100, Pawel Jakub Dawidek wrote: > > Cool, so you have a chance to try memguard(9) and verify my patch to > manual page:) > memguard appears to be broken on amd64. See my followup to Kris. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 22:47:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B41316A420; Tue, 31 Jan 2006 22:47:36 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDCF343D6E; Tue, 31 Jan 2006 22:47:23 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id E3A501A3C20; Tue, 31 Jan 2006 14:47:22 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E75DC513A2; Tue, 31 Jan 2006 17:47:21 -0500 (EST) Date: Tue, 31 Jan 2006 17:47:21 -0500 From: Kris Kennaway To: Pawel Jakub Dawidek Message-ID: <20060131224721.GA16866@xor.obsecurity.org> References: <20060131212209.GA870@troutmask.apl.washington.edu> <20060131215021.GG4395@haakonia.hitnet.RWTH-Aachen.DE> <20060131220828.GA2953@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <20060131220828.GA2953@garage.freebsd.pl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 22:47:36 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2006 at 11:11:20PM +0100, Pawel Jakub Dawidek wrote: > On Tue, Jan 31, 2006 at 10:50:21PM +0100, Christian Brueffer wrote: > +> On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote: > +> > The system is a dual proc Tyan K8S Pro with 12 GB of memory. > +> > The kernel is UP. This was recorded by hand. I have the crash dump. > +> >=20 > +> > Memory modified after free 0xffffff02505e0c00(504) val=3Ddeadc0dd @ > +> > 0xffffff02505e0cd0 > +> >=20 > +>=20 > +> For the record, I got this as well today. Here it was on my notebook > +> at system shutdown. >=20 > Cool, so you have a chance to try memguard(9) and verify my patch to > manual page:) >=20 > --- memguard.9 30 Dec 2005 12:28:19 -0000 1.2 > +++ memguard.9 31 Jan 2006 22:06:04 -0000 > @@ -56,6 +56,9 @@ vm.memguard.desc=3D > .Ed > .Pp > Where memory_type is a short description of memory type to monitor. > +The short description of memory type is the second argument to > +.Xr MALLOC_DECLARE 9 , > +so one has to find it in the kernel source. ITYM MALLOC_DEFINE? Kris --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD3+j5Wry0BWjoQKURAvplAJsGfEqg4qq3pjgr+Vv7P70Ycu2yYACgiwhM hNYYQ5AjmGqqqUH/TYUvrSc= =vbeq -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 23:10:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F30C216A420 for ; Tue, 31 Jan 2006 23:10:30 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp100.rog.mail.re2.yahoo.com (smtp100.rog.mail.re2.yahoo.com [206.190.36.78]) by mx1.FreeBSD.org (Postfix) with SMTP id CCD1B43D6D for ; Tue, 31 Jan 2006 23:10:17 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 2742 invoked from network); 31 Jan 2006 23:10:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding; b=lkVO4DobosMsrAs+EIaZ3S0nE4c7n6rOiLIOKaK4AjBsLe3Dh3tQ4xulk0K95SbaQ2+OxQ4Z1eLVZEes4YLkgS7dE4+gzllqwCP6EHVq2YJoN3fC5s+zIUJsRFbph+1uOPDTBI4FhnwxhoBR0Sh3tT8ntQ9w2Z2PH5jGz7qwlRo= ; Received: from unknown (HELO ?70.30.133.184?) (mikej@rogers.com@70.30.133.184 with plain) by smtp100.rog.mail.re2.yahoo.com with SMTP; 31 Jan 2006 23:10:17 -0000 Message-ID: <43DFEE8A.70909@rogers.com> Date: Tue, 31 Jan 2006 18:11:06 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sos@freebsd.org Subject: ServerWorks HT1000 Chipset SATA support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 23:10:31 -0000 Does anyone know if the SATA chipset found on the Supermicro H8SSL-i motherboard, which is a HT1000/Broadcom is supported, if not are there plants to support it in the future? The motherboard specs can be found here: http://www.supermicro.com/Aplus/motherboard/Opteron/HT1000/H8SSL-i.cfm From owner-freebsd-current@FreeBSD.ORG Tue Jan 31 23:50:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48CEB16A420 for ; Tue, 31 Jan 2006 23:50:57 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E60843D6E for ; Tue, 31 Jan 2006 23:50:47 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7ACF346BD8; Tue, 31 Jan 2006 18:50:37 -0500 (EST) Date: Tue, 31 Jan 2006 23:52:38 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sean McNeil In-Reply-To: <1138476952.86610.1.camel@triton.mcneil.com> Message-ID: <20060131235035.B95776@fledge.watson.org> References: <1138476952.86610.1.camel@triton.mcneil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Jan 2006 23:50:57 -0000 On Sat, 28 Jan 2006, Sean McNeil wrote: > I was wondering if this was on purpose. Seems like there is no good reason > that it was done on -STABLE and it has really messed up everything here for > me. > > libcom_err.so.2 bumped to libcom_err.so.3. It was on purpose, but not necessarily for a good reason. Could you be more specific about "really messed up everything here for me", which sounds a lot to me like "and all hell broken loose"? I assume there's some sort of library and application versioning problem, but some details would be helpful. In principle, other than potentially requiring compat libs to run old binaries even though that may not strictly have been necessary, it seems likely that a binary depending on the old libcom_err depends also on an old libc. On the other hand, I consider library version number interactions to be mysterious, and likely have missed the point. :-) Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 00:22:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4492116A420; Wed, 1 Feb 2006 00:22:00 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E8B143D46; Wed, 1 Feb 2006 00:21:56 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id ADDE8574D; Wed, 1 Feb 2006 01:30:01 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on cvs.freesbie.org X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 Received: from [192.168.99.16] (host14-150.pool875.interbusiness.it [87.5.150.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP; Wed, 1 Feb 2006 01:30:01 +0100 (CET) Message-ID: <43DFFF1A.4050406@freesbie.org> Date: Wed, 01 Feb 2006 01:21:46 +0100 From: Dario Freni User-Agent: Mozilla Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 References: <3281.1138742578@critter.freebsd.dk> <43DFD698.7040508@elischer.org> In-Reply-To: <43DFD698.7040508@elischer.org> X-Enigmail-Version: 0.94.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig98EF1275CBBEC52DE5A857BE" X-Virus-Scanned: ClamAV using ClamSMTP Cc: small@freebsd.org, rizzo@icir.org, Poul-Henning Kamp , rwatson@freebsd.org, "M. Warner Losh" , current@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 00:22:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig98EF1275CBBEC52DE5A857BE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Julian Elischer wrote: > Poul-Henning Kamp wrote: >=20 >> In message <20060131.131654.134137067.imp@bsdimp.com>, "M. Warner >> Losh" writes: >> =20 >> >>> In message: <43DFC2D5.7040706@errno.com> >>> Sam Leffler writes: >>> =20 >> >> =20 >> >>> Since I've started working on the bring up on an ARM based board, I'v= e >>> been wanting something that is easy to work with and that worked. I >>> think it would help us a lot in the embedded space if we had somethin= g >>> integrated into the base OS to do this stuff. >>> =20 >> >> I agree. I think we need to be much more inclusive in our concept of >> a 'release' than we are now. >> >> As I see it, PicoBSD with its "additive" approach would cover the >> low-capacity (<32 MB ?) range, NanoBSD with its "subtractive" approach= >> takes over from there, FreeSBIE covers the "don't touch my disk" >> range and finally the full blown release as we know it. >> =20 >> >=20 > I'd like to see us take the freesbie release into the tree somewhere > (since it uses so many > ports, maybe in ports, or maybe in tools) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" Do you mean the livecd or the build toolkit? The toolkit only needs mkisofs as port (like release/ scripts do, afaik). Bye, Dario --=20 Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --------------enig98EF1275CBBEC52DE5A857BE 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.1 (Darwin) iD8DBQFD3/8aymi72IiShysRAnCYAKDuLhArEQ2taebuatmLm8/U2vrLggCg2Sjx r5zkVygNMShiZHezUqzgJqk= =6Vus -----END PGP SIGNATURE----- --------------enig98EF1275CBBEC52DE5A857BE-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 01:01:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EB5416A420 for ; Wed, 1 Feb 2006 01:01:58 +0000 (GMT) (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 D621C43D49 for ; Wed, 1 Feb 2006 01:01:57 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k1111vtD000677 for ; Tue, 31 Jan 2006 17:01:57 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k1111vCI000676 for freebsd-current@freebsd.org; Tue, 31 Jan 2006 17:01:57 -0800 (PST) (envelope-from sgk) Date: Tue, 31 Jan 2006 17:01:57 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20060201010157.GA604@troutmask.apl.washington.edu> References: <20060131212209.GA870@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060131212209.GA870@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.1i Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 01:01:58 -0000 On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote: > The system is a dual proc Tyan K8S Pro with 12 GB of memory. > The kernel is UP. This was recorded by hand. I have the crash dump. > > Memory modified after free 0xffffff02505e0c00(504) val=deadc0dd @ > 0xffffff02505e0cd0 > Thing are looking positively horrid. A kernel from a cvsup with a date=2006.01.25.00.00.00 appears to work fine. A kernel from with date=2006.01.27.00.00.00 dies with dev_relthread() at dev_relthread+0x2e devfs_close() at devfs_close+0x1b6 VOP_CLOSE_APV() at VOP_CLOSE_APV+0x74 vn_close() at vn_close+0x8d vn_closefile() at vn_closefile+0x5a fdrop_locked() at fdrop_locked+0xa1 closef() at closef+0x35f fdfree() at fdfree+0x513 exit1() at exit1+0x360 sys_exit() at sys_exit+0xe -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 01:51:14 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D469F16A422 for ; Wed, 1 Feb 2006 01:51:14 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 582AF43D48 for ; Wed, 1 Feb 2006 01:51:14 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D10FC46C88; Tue, 31 Jan 2006 20:51:04 -0500 (EST) Date: Wed, 1 Feb 2006 01:53:06 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sean McNeil In-Reply-To: <7B0411F5-FCBC-40BC-94CA-2B8AA13FA783@mcneil.com> Message-ID: <20060201014800.E95776@fledge.watson.org> References: <1138476952.86610.1.camel@triton.mcneil.com> <20060131235035.B95776@fledge.watson.org> <7B0411F5-FCBC-40BC-94CA-2B8AA13FA783@mcneil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 01:51:15 -0000 On Tue, 31 Jan 2006, Sean McNeil wrote: > On Jan 31, 2006, at 3:52 PM, Robert Watson wrote: > >> On Sat, 28 Jan 2006, Sean McNeil wrote: >> >>> I was wondering if this was on purpose. Seems like there is no good >>> reason that it was done on -STABLE and it has really messed up everything >>> here for me. >>> >>> libcom_err.so.2 bumped to libcom_err.so.3. >> >> It was on purpose, but not necessarily for a good reason. Could you be >> more specific about "really messed up everything here for me", which sounds >> a lot to me like "and all hell broken loose"? I assume there's some sort >> of library and application versioning problem, but some details would be >> helpful. > > I had several big packages that depended on kerberos and they all broke > because: > > 1) libcom_err.so.2.1 was moved to /usr/local/lib/compat/pkg/ > 2) The symlink libcom_err.so.2 was removed and nothing was placed in compat. > > I finally got smart and just added an entry to libmap.conf and so I'm not > "really messed up...". That was not accurate in the first place :) So the real problem was that libcom_err.so.2 was not placed in compat when the version number was bumped. >> In principle, other than potentially requiring compat libs to run old >> binaries even though that may not strictly have been necessary, it seems >> likely that a binary depending on the old libcom_err depends also on an old >> libc. On the other hand, I consider library version number interactions to >> be mysterious, and likely have missed the point. :-) > > The point I am making is that this is in the -STABLE tree, not the -CURRENT > tree. There is no bump of libc and I don't see any reason for the > libcom_err.so revision bump in -STABLE. IMHO, it didn't make sense. There was a bump in libc, it just happened much earlier. The remainder of the libraries were bumped shortly before 6.0-RELEASE, but not after the release once it became -STABLE. Libraries also have ABI dependencies on other library revisions -- i.e., if an API changes in libc, and libypclnt depends on the old version of the API, it needs to use the old libc. Could you grab a libcom_err.so.2 from RELENG_5 and stick it in your compat tree and see what happens? Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 00:03:24 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A55D16A420; Wed, 1 Feb 2006 00:03:24 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC38D43D46; Wed, 1 Feb 2006 00:03:23 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 2DCD4F230B; Tue, 31 Jan 2006 16:03:23 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24359-07; Tue, 31 Jan 2006 16:03:22 -0800 (PST) Received: from [10.1.0.10] (mobile.mcneil.com [10.1.0.10]) by mail.mcneil.com (Postfix) with ESMTP id A7ACDF2100; Tue, 31 Jan 2006 16:03:22 -0800 (PST) In-Reply-To: <20060131235035.B95776@fledge.watson.org> References: <1138476952.86610.1.camel@triton.mcneil.com> <20060131235035.B95776@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B0411F5-FCBC-40BC-94CA-2B8AA13FA783@mcneil.com> Content-Transfer-Encoding: 7bit From: Sean McNeil Date: Tue, 31 Jan 2006 16:03:21 -0800 To: Robert Watson X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Wed, 01 Feb 2006 02:16:39 +0000 Cc: current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 00:03:24 -0000 On Jan 31, 2006, at 3:52 PM, Robert Watson wrote: > > On Sat, 28 Jan 2006, Sean McNeil wrote: > >> I was wondering if this was on purpose. Seems like there is no >> good reason that it was done on -STABLE and it has really messed >> up everything here for me. >> >> libcom_err.so.2 bumped to libcom_err.so.3. > > It was on purpose, but not necessarily for a good reason. Could > you be more specific about "really messed up everything here for > me", which sounds a lot to me like "and all hell broken loose"? I > assume there's some sort of library and application versioning > problem, but some details would be helpful. I had several big packages that depended on kerberos and they all broke because: 1) libcom_err.so.2.1 was moved to /usr/local/lib/compat/pkg/ 2) The symlink libcom_err.so.2 was removed and nothing was placed in compat. I finally got smart and just added an entry to libmap.conf and so I'm not "really messed up...". That was not accurate in the first place :) > In principle, other than potentially requiring compat libs to run > old binaries even though that may not strictly have been necessary, > it seems likely that a binary depending on the old libcom_err > depends also on an old libc. On the other hand, I consider library > version number interactions to be mysterious, and likely have > missed the point. :-) The point I am making is that this is in the -STABLE tree, not the - CURRENT tree. There is no bump of libc and I don't see any reason for the libcom_err.so revision bump in -STABLE. IMHO, it didn't make sense. Cheers, Sean From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 02:25:05 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D35016A420; Wed, 1 Feb 2006 02:25:05 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 411E743D46; Wed, 1 Feb 2006 02:25:04 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id k112P204027899; Tue, 31 Jan 2006 21:25:02 -0500 (EST) Date: Tue, 31 Jan 2006 21:25:02 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Sean McNeil In-Reply-To: <7B0411F5-FCBC-40BC-94CA-2B8AA13FA783@mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Robert Watson , current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 02:25:05 -0000 On Tue, 31 Jan 2006, Sean McNeil wrote: > > The point I am making is that this is in the -STABLE tree, not the - > CURRENT tree. There is no bump of libc and I don't see any reason > for the libcom_err.so revision bump in -STABLE. IMHO, it didn't make > sense. I don't think it was -stable at the time. It was probably 6.0-current and the version bump occurred just before the release. As a -current user, you are expected to be able to deal with this and rebuild all your ports if necessary. -- DE From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 02:28:16 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0374016A420; Wed, 1 Feb 2006 02:28:16 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5D1043D45; Wed, 1 Feb 2006 02:28:15 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 5817EF25C1; Tue, 31 Jan 2006 18:28:15 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63045-03; Tue, 31 Jan 2006 18:28:14 -0800 (PST) Received: from [10.1.0.10] (mobile.mcneil.com [10.1.0.10]) by mail.mcneil.com (Postfix) with ESMTP id D61E6F255A; Tue, 31 Jan 2006 18:28:14 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sean McNeil Date: Tue, 31 Jan 2006 18:28:14 -0800 To: Daniel Eischen X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Wed, 01 Feb 2006 02:32:00 +0000 Cc: Robert Watson , current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 02:28:16 -0000 On Jan 31, 2006, at 6:25 PM, Daniel Eischen wrote: > On Tue, 31 Jan 2006, Sean McNeil wrote: >> >> The point I am making is that this is in the -STABLE tree, not the - >> CURRENT tree. There is no bump of libc and I don't see any reason >> for the libcom_err.so revision bump in -STABLE. IMHO, it didn't make >> sense. > > I don't think it was -stable at the time. It was probably > 6.0-current and the version bump occurred just before the > release. As a -current user, you are expected to be able > to deal with this and rebuild all your ports if necessary. This is EXACTLY what I am saying. I am not a -current user, I am a - stable user and this happened about a week ago or so. It was libcom_err.so.2.1 until just recently. From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 02:35:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37F6316A420; Wed, 1 Feb 2006 02:35:22 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id E134943D45; Wed, 1 Feb 2006 02:35:21 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id C3AC61A3C20; Tue, 31 Jan 2006 18:35:21 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 29EDD51BFD; Tue, 31 Jan 2006 21:35:21 -0500 (EST) Date: Tue, 31 Jan 2006 21:35:21 -0500 From: Kris Kennaway To: Sean McNeil Message-ID: <20060201023521.GA20497@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Daniel Eischen , Robert Watson , current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 02:35:22 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2006 at 06:28:14PM -0800, Sean McNeil wrote: >=20 > On Jan 31, 2006, at 6:25 PM, Daniel Eischen wrote: >=20 > >On Tue, 31 Jan 2006, Sean McNeil wrote: > >> > >>The point I am making is that this is in the -STABLE tree, not the - > >>CURRENT tree. There is no bump of libc and I don't see any reason > >>for the libcom_err.so revision bump in -STABLE. IMHO, it didn't make > >>sense. > > > >I don't think it was -stable at the time. It was probably > >6.0-current and the version bump occurred just before the > >release. As a -current user, you are expected to be able > >to deal with this and rebuild all your ports if necessary. >=20 >=20 > This is EXACTLY what I am saying. I am not a -current user, I am a -=20 > stable user and this happened about a week ago or so. It was =20 > libcom_err.so.2.1 until just recently. The confusion seems to be that you sent your email to the wrong mailing list. Kris --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD4B5oWry0BWjoQKURAgHwAJ9XR8U6N760ZSued+9ChJVXsn/UGQCbBUeX U18ET9j+kEicshcYzO1qH78= =K1PB -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 03:55:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D29916A420; Wed, 1 Feb 2006 03:55:21 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AE0443D4C; Wed, 1 Feb 2006 03:55:20 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp208-69.lns1.adl2.internode.on.net [203.122.208.69]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k113t3ua050833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2006 14:25:10 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Jason Evans Date: Wed, 1 Feb 2006 14:24:55 +1030 User-Agent: KMail/1.9.1 References: <200601301652.16237.doconnor@gsoft.com.au> <1713BECB-9E36-4D12-A063-46AB2EC0AB2F@freebsd.org> <200601311805.07556.doconnor@gsoft.com.au> In-Reply-To: <200601311805.07556.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5963183.3n7TCHxjY8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200602011424.57722.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: freebsd-current@freebsd.org, Michael Nottebrock , Kris Kennaway Subject: Re: KDE 3.5.0 seems much chubbier than 3.4.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 03:55:21 -0000 --nextPart5963183.3n7TCHxjY8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 31 January 2006 18:04, Daniel O'Connor wrote: > > Yes, I'd expect the memory usage to decrease if you build with > > NO_MALLOC_EXTRAS, since redzone overhead is 32 bytes per object. Do > > you see any evidence of unbounded X memory usage though? > > Hmm, not sure it was unbounded, but it was certainly consuming a lot of > extra memory. Note that with the debugging off top shows it as.. > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 19876 root 1 100 0 315M 136M select 18:16 13.67% Xorg > Things still seem to be using more memory than I would expect.. Certainly m= y=20 laptop is swapping more than I expect :( Is there a simple way to revert to the old malloc? Just back out malloc.c? I'd go back to KDE 3.4.2 but that is a lot more complex :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart5963183.3n7TCHxjY8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD4DER5ZPcIHs/zowRAtpPAJ9+WDbA5L/226FujhnXefSjnxYdJACeOR0Q eO7g4YpWnfTmFl58Cc2H1Ns= =gXIe -----END PGP SIGNATURE----- --nextPart5963183.3n7TCHxjY8-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 04:21:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB35D16A420 for ; Wed, 1 Feb 2006 04:21:22 +0000 (GMT) (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 6AD1943D45 for ; Wed, 1 Feb 2006 04:21:22 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k114LMo7027812 for ; Tue, 31 Jan 2006 20:21:22 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k114LM6U027811 for freebsd-current@freebsd.org; Tue, 31 Jan 2006 20:21:22 -0800 (PST) (envelope-from sgk) Date: Tue, 31 Jan 2006 20:21:22 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20060201042122.GA27796@troutmask.apl.washington.edu> References: <20060131212209.GA870@troutmask.apl.washington.edu> <20060201010157.GA604@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060201010157.GA604@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.1i Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 04:21:22 -0000 On Tue, Jan 31, 2006 at 05:01:57PM -0800, Steve Kargl wrote: > On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote: > > The system is a dual proc Tyan K8S Pro with 12 GB of memory. > > The kernel is UP. This was recorded by hand. I have the crash dump. > > > > Memory modified after free 0xffffff02505e0c00(504) val=deadc0dd @ > > 0xffffff02505e0cd0 > > > > Thing are looking positively horrid. A kernel from a cvsup with > a date=2006.01.25.00.00.00 appears to work fine. A kernel from with > date=2006.01.27.00.00.00 dies with > > dev_relthread() at dev_relthread+0x2e > devfs_close() at devfs_close+0x1b6 > VOP_CLOSE_APV() at VOP_CLOSE_APV+0x74 > vn_close() at vn_close+0x8d > vn_closefile() at vn_closefile+0x5a > fdrop_locked() at fdrop_locked+0xa1 > closef() at closef+0x35f > fdfree() at fdfree+0x513 > exit1() at exit1+0x360 > sys_exit() at sys_exit+0xe > a 2006.01.26.12.00.00.00 kernel dies a similar death. Unfortnately, this panic took out a portion of /usr/include and /usr/src. I can't prove it yet, but I think the pts code may be the trigger. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 05:17:11 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE17016A47F; Wed, 1 Feb 2006 05:17:11 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B369543DB8; Wed, 1 Feb 2006 05:16:37 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id k115Ga1d004182; Wed, 1 Feb 2006 00:16:36 -0500 (EST) Date: Wed, 1 Feb 2006 00:16:36 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Sean McNeil In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Robert Watson , current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 05:17:12 -0000 On Tue, 31 Jan 2006, Sean McNeil wrote: > > On Jan 31, 2006, at 6:25 PM, Daniel Eischen wrote: > > > On Tue, 31 Jan 2006, Sean McNeil wrote: > >> > >> The point I am making is that this is in the -STABLE tree, not the - > >> CURRENT tree. There is no bump of libc and I don't see any reason > >> for the libcom_err.so revision bump in -STABLE. IMHO, it didn't make > >> sense. > > > > I don't think it was -stable at the time. It was probably > > 6.0-current and the version bump occurred just before the > > release. As a -current user, you are expected to be able > > to deal with this and rebuild all your ports if necessary. > > > This is EXACTLY what I am saying. I am not a -current user, I am a - > stable user and this happened about a week ago or so. It was > libcom_err.so.2.1 until just recently. Where is the commit that did this? I only see revision 1.2.14.1 of src/lib/Makefile.inc which was committed July 22, 2005: revision 1.2.14.1 date: 2005/07/22 17:29:02; author: kensmith; state: Exp; lines: +1 -1 Insta-MFC of the shared library version bump. All shared libraries whose version has not already been bumped since RELENG_5 are being bumped. Revisions of files being MFC-ed: That was prior to 6.0 being -stable, not after. And freefall has been at 6.0-stable since Dec 10th: $ ls -l /usr/lib/libcom_err* -r--r--r-- 1 root wheel 3940 Dec 10 03:21 /usr/lib/libcom_err.a lrwxr-xr-x 1 root wheel 15 Dec 10 03:21 /usr/lib/libcom_err.so -> libcom_err.so.3 -r--r--r-- 1 root wheel 5544 Dec 9 21:38 /usr/lib/libcom_err.so.2 -r--r--r-- 1 root wheel 5544 Dec 10 03:21 /usr/lib/libcom_err.so.3 so it hasn't happened in the last week or so. You must have something wrong on your end. -- DE From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 05:26:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C4F216A429; Wed, 1 Feb 2006 05:26:40 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA28C43D7B; Wed, 1 Feb 2006 05:26:31 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id k115QUV9011813; Wed, 1 Feb 2006 00:26:30 -0500 (EST) Date: Wed, 1 Feb 2006 00:26:30 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Sean McNeil In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Robert Watson , current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 05:26:40 -0000 On Wed, 1 Feb 2006, Daniel Eischen wrote: > On Tue, 31 Jan 2006, Sean McNeil wrote: > > > > > This is EXACTLY what I am saying. I am not a -current user, I am a - > > stable user and this happened about a week ago or so. It was > > libcom_err.so.2.1 until just recently. And I don't see any libcom_err.so.2.1 libraries on any of the systems I have access to. -- DE From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 07:16:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D88D316A420; Wed, 1 Feb 2006 07:16:36 +0000 (GMT) (envelope-from k-choy@ics.es.osaka-u.ac.jp) Received: from mir.ics.es.osaka-u.ac.jp (mir.ics.es.osaka-u.ac.jp [133.1.12.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF2A243D6A; Wed, 1 Feb 2006 07:16:26 +0000 (GMT) (envelope-from k-choy@ics.es.osaka-u.ac.jp) Received: from [127.0.0.1] (serg32.ics.es.osaka-u.ac.jp [192.168.144.160]) by mir.ics.es.osaka-u.ac.jp (8.13.3/8.12.10) with ESMTP id k117GMTj089313; Wed, 1 Feb 2006 16:16:24 +0900 (JST) (envelope-from k-choy@ics.es.osaka-u.ac.jp) Message-ID: <43E06043.4010003@ics.es.osaka-u.ac.jp> Date: Wed, 01 Feb 2006 16:16:19 +0900 From: Choy Kho Yee User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Subject: Newly developed mailling list search engine needs more testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 07:16:37 -0000 Hi, everybody. Firstly, let me introduce myself. I am Choy Kho Yee, an comp. sci. undergraduate student in Osaka University. For my final year project, I have developed a mailing list archive management system called "MLwiki". I have sent mails to some of the mailing lists not so long ago, so that more people can help me test out this system. I have been getting supportive answers from the survey about the system. However, I would like to have more responses about the design and implementation of the system, so here I sent this mail again. I hope that you can spare some of your precious time to help me out with this. If it is proved useful to the community, I would perhaps continue to work on it. More information about MLwiki is available on the main page of this system, which is located at MLwiki http://noanoa.ics.es.osaka-u.ac.jp/~k-choy/mlwiki-test/mlwiki.php and the survey at The questionnaire http://noanoa.ics.es.osaka-u.ac.jp/~k-choy/mlwiki-test/mlwiki_questionaire.html Thanks a lot. --- The original mail that I sent not long ago is as follow --- The name MLwiki is made up from the words "Mailing List" and "Wiki". It was developed to overcome some weaknesses of the existing mailing list archiving and searching system and to combine the power of wiki and the huge amount of information in the mailing list archive. With MLwiki, it is hoped that users can get the information they want faster and easier. More information about MLwiki is available on the main page of this system, which is located at MLwiki http://noanoa.ics.es.osaka-u.ac.jp/~k-choy/mlwiki-test/mlwiki.php The questionnaire http://noanoa.ics.es.osaka-u.ac.jp/~k-choy/mlwiki-test/mlwiki_questionaire.html Please read the introduction on the main page before testing the system as it provides some vital information to fully utilize MLwiki. After testing out the system, I would be glad if you can help me out by filling in the questionnaire about this system, which can be accessed through the above address or from MLwiki's main page. Please understand that MLwiki is in its early stage of development and therefore there might be many bugs hidden in it. Bugs reports are welcome. And please remember that this system is still in an experimental stage, all changes you submit might be lost in the future release. But do feel free to test around. This website will be available until 10 February 2006. Accessibility after that will be re-considered depends on the response and the condition of the system. Thanks a lot. --- Choy Kho Yee E-mail: k-choy at ics dot es dot osaka-u dot ac dot jp From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 07:52:59 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D53716A422; Wed, 1 Feb 2006 07:52:59 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70DDF43D46; Wed, 1 Feb 2006 07:52:58 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from [194.192.25.142] (spider.deepcore.dk [194.192.25.142]) by spider.deepcore.dk (8.13.4/8.13.4) with ESMTP id k117quci074887; Wed, 1 Feb 2006 08:52:56 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <43E068D8.80901@deepcore.dk> Date: Wed, 01 Feb 2006 08:52:56 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 1.5 (X11/20060130) MIME-Version: 1.0 To: Mike Jakubik References: <43DFEE8A.70909@rogers.com> In-Reply-To: <43DFEE8A.70909@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.16 Cc: current@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: ServerWorks HT1000 Chipset SATA support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 07:52:59 -0000 Mike Jakubik wrote: > > Does anyone know if the SATA chipset found on the Supermicro H8SSL-i > motherboard, which is a HT1000/Broadcom is supported, if not are there > plants to support it in the future? I have support on my TODO list but doesn't have the HW to do it (yet). -Søren From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 07:58:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2129E16A420 for ; Wed, 1 Feb 2006 07:58:09 +0000 (GMT) (envelope-from dougb@freebsd.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCE8E43D45 for ; Wed, 1 Feb 2006 07:58:08 +0000 (GMT) (envelope-from dougb@freebsd.org) Received: from [192.168.1.101] (70-32-110-40.vnnyca.adelphia.net[70.32.110.40]) by comcast.net (rwcrmhc11) with ESMTP id <20060201075808m11002j6k6e>; Wed, 1 Feb 2006 07:58:08 +0000 Message-ID: <43E06A0F.9070202@FreeBSD.org> Date: Tue, 31 Jan 2006 23:58:07 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 07:58:09 -0000 Sean McNeil wrote: > This is EXACTLY what I am saying. I am not a -current user, I am a > -stable user and this happened about a week ago or so. It was > libcom_err.so.2.1 until just recently. I don't see how it could be libanything.so.2.1 on a FreeBSD system, given that we dropped minor revision numbers on shared libs back at the elf conversion. Also: ls /usr/lib/*.[0-9].[0-9] /lib/*.[0-9].[0-9] ls: /lib/*.[0-9].[0-9]: No such file or directory ls: /usr/lib/*.[0-9].[0-9]: No such file or directory I don't know where you got libcom_err.so.2.1, but I don't think it's from a FreeBSD system. Also, to make things clear, if you are using 7-current, this is the right list to continue asking for help on. If you're using 6.0, you should ask for help on freebsd-stable@freebsd.org. Before doing so however, if I were you I'd take the following steps: 1. cvsup the latest sources for RELENG_6 (6-stable). 2. cd /usr/src ; make cleanworld 3. make buildworld ; make kernel 4. Follow the upgrading instructions in src/UPDATING 5. Go into /lib and /usr/lib, and do 'ls -lr', then mv any old libraries out of those directories. 6. cd /etc/ ; mv libmap.conf libmap.conf.bak (it's ok if this file doesn't exist) 7. reboot 8. Rebuild any ports that don't work, even if that means all of them. Then I'd say you're in pretty good shape to start asking for help again, presumably on freebsd-stable@. Good luck, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 08:24:16 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DDFF16A420 for ; Wed, 1 Feb 2006 08:24:16 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.FreeBSD.org (Postfix) with SMTP id E978F43D4C for ; Wed, 1 Feb 2006 08:24:14 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 99525 invoked from network); 1 Feb 2006 08:24:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=je1iQU34LyhtlUd2ljm0gRxtkPP/AtZUw0gyuN+kgh54YjBvKio+RyuuJ1IgRZHNlaMuMDmOCPgWlhisPyYzLYZdn7oNFvtLMX9fvy05iKehO62tYZMHmPYsBPVFg1hKZpK1N2Gz8zoXRAzerlxO9U56s6RMGjdwJjDyNhk/E90= ; Received: from unknown (HELO ?70.30.133.184?) (mikej@rogers.com@70.30.133.184 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 1 Feb 2006 08:24:14 -0000 Message-ID: <43E07062.8040509@rogers.com> Date: Wed, 01 Feb 2006 03:25:06 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <43DFEE8A.70909@rogers.com> <43E068D8.80901@deepcore.dk> In-Reply-To: <43E068D8.80901@deepcore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: current@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: ServerWorks HT1000 Chipset SATA support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 08:24:16 -0000 Søren Schmidt wrote: > Mike Jakubik wrote: >> >> Does anyone know if the SATA chipset found on the Supermicro H8SSL-i >> motherboard, which is a HT1000/Broadcom is supported, if not are >> there plants to support it in the future? > > I have support on my TODO list but doesn't have the HW to do it (yet). I understand. If i have the means to provide you with the HW in the near future, i will be glad to do so. Thanks. From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 08:48:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 065B716A420 for ; Wed, 1 Feb 2006 08:48:20 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92D2C43D4C for ; Wed, 1 Feb 2006 08:48:10 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4C77751563; Wed, 1 Feb 2006 09:48:08 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id EF18F50A16; Wed, 1 Feb 2006 09:48:01 +0100 (CET) Date: Wed, 1 Feb 2006 09:47:56 +0100 From: Pawel Jakub Dawidek To: Kris Kennaway Message-ID: <20060201084756.GA764@garage.freebsd.pl> References: <20060131212209.GA870@troutmask.apl.washington.edu> <20060131215021.GG4395@haakonia.hitnet.RWTH-Aachen.DE> <20060131220828.GA2953@garage.freebsd.pl> <20060131224721.GA16866@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <20060131224721.GA16866@xor.obsecurity.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 08:48:20 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2006 at 05:47:21PM -0500, Kris Kennaway wrote: +> On Tue, Jan 31, 2006 at 11:11:20PM +0100, Pawel Jakub Dawidek wrote: +> > On Tue, Jan 31, 2006 at 10:50:21PM +0100, Christian Brueffer wrote: +> > +> On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote: +> > +> > The system is a dual proc Tyan K8S Pro with 12 GB of memory. +> > +> > The kernel is UP. This was recorded by hand. I have the crash du= mp. +> > +> >=20 +> > +> > Memory modified after free 0xffffff02505e0c00(504) val=3Ddeadc0dd= @ +> > +> > 0xffffff02505e0cd0 +> > +> >=20 +> > +>=20 +> > +> For the record, I got this as well today. Here it was on my notebo= ok +> > +> at system shutdown. +> >=20 +> > Cool, so you have a chance to try memguard(9) and verify my patch to +> > manual page:) +> >=20 +> > --- memguard.9 30 Dec 2005 12:28:19 -0000 1.2 +> > +++ memguard.9 31 Jan 2006 22:06:04 -0000 +> > @@ -56,6 +56,9 @@ vm.memguard.desc=3D +> > .Ed +> > .Pp +> > Where memory_type is a short description of memory type to monitor. +> > +The short description of memory type is the second argument to +> > +.Xr MALLOC_DECLARE 9 , +> > +so one has to find it in the kernel source. +>=20 +> ITYM MALLOC_DEFINE? Yes, DEFINE. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD4HW7ForvXbEpPzQRAgc3AKCUfTLQHdBwei5COrN6NKGncjhg2gCfWcJB 1cMEmDBnIgyOIh9HNFkDefE= =CUVH -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 08:53:41 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 872AD16A420 for ; Wed, 1 Feb 2006 08:53:41 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail27.syd.optusnet.com.au (mail27.syd.optusnet.com.au [211.29.133.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC64343D48 for ; Wed, 1 Feb 2006 08:53:40 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail27.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k118rb6H005120 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Feb 2006 19:53:38 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k118rbkE001039; Wed, 1 Feb 2006 19:53:37 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k118rasQ001038; Wed, 1 Feb 2006 19:53:36 +1100 (EST) (envelope-from peter) Date: Wed, 1 Feb 2006 19:53:36 +1100 From: Peter Jeremy To: Luigi Rizzo Message-ID: <20060201085336.GB824@turion.vk2pj.dyndns.org> References: <20060131105224.A57698@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060131105224.A57698@xorpc.icir.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: current@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 08:53:41 -0000 On Tue, 2006-Jan-31 10:52:24 -0800, Luigi Rizzo wrote: >I know it is not ideal to have a piece of code in the main tree >that depends on an external port. Yet, better than have it broken. >2. commit the updated script, fix one or two sample targets, > and remove the others (all of this is in src/release/picobsd) "make release" requires mkisofs and includes a perl and a python script (though I'm not certain they are needed). Given this, I think option 2 is acceptable, >3. remove the entire src/release/picobsd tree and move it to > a port (question - do we want the old content of src/release/picobsd > in ports/foo/picobsd/files ? In any case, we need a place in > some repository to store these things) The picobsd CVS tree is 5.8MB so a repocopy would not be out of the question. A checked out version of src/release/picobsd is currently 688KB and there are two ports with files directories larger than that (and a third that only slightly smaller). There is also a precedent for having the port "sources" in the files directory. I think the biggest killer for option 3 is that the ports tree is not branched so paralleling RELENG_x source trees would be "difficult". -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 10:00:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5F3216A425 for ; Wed, 1 Feb 2006 10:00:21 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 2253643D5A for ; Wed, 1 Feb 2006 10:00:10 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 01 Feb 2006 10:00:09 -0000 Received: from fwswe.rise-s.com (EHLO dhcp105.swe) [83.65.168.194] by mail.gmx.net (mp037) with SMTP; 01 Feb 2006 11:00:09 +0100 X-Authenticated: #16703784 From: Stefan Ehmann To: John Baldwin In-Reply-To: <200601311739.27980.jhb@freebsd.org> References: <200601311739.27980.jhb@freebsd.org> Content-Type: text/plain Date: Wed, 01 Feb 2006 11:00:02 +0100 Message-Id: <1138788002.701.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: anholt@freebsd.org, current@freebsd.org Subject: Re: Patch to fix i915 drm with vgapci changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 10:00:22 -0000 On Tue, 2006-01-31 at 17:39 -0500, John Baldwin wrote: > This patch uses an identify routine in the agp driver to add the agp child to > vgapci instead of having vgapci guess based on the PCIY_AGP capability. > Patch is at http://www.FreeBSD.org/~jhb/patches/agp_vgapci.patch Doesn't compile because of missing return statement. Otherwise it works fine for me. Thanks. From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 11:14:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CFAB16A429; Wed, 1 Feb 2006 11:14:33 +0000 (GMT) (envelope-from past@ebs.gr) Received: from fly.ebs.gr (dslcustomer-239-113.vivodi.gr [83.171.239.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 654E143D48; Wed, 1 Feb 2006 11:14:31 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id k11BETSg020810; Wed, 1 Feb 2006 13:14:29 +0200 (EET) (envelope-from past@ebs.gr) Received: from [10.1.1.158] (ajax.ebs.gr [10.1.1.158]) by ebs.gr (8.13.3/8.12.11) with ESMTP id k11BFNst062450; Wed, 1 Feb 2006 13:15:23 +0200 (EET) (envelope-from past@ebs.gr) Message-ID: <43E09814.8080707@ebs.gr> Date: Wed, 01 Feb 2006 13:14:28 +0200 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Thunderbird 1.5 (X11/20060116) MIME-Version: 1.0 To: Sean McNeil References: <1138476952.86610.1.camel@triton.mcneil.com> <20060131235035.B95776@fledge.watson.org> <7B0411F5-FCBC-40BC-94CA-2B8AA13FA783@mcneil.com> In-Reply-To: <7B0411F5-FCBC-40BC-94CA-2B8AA13FA783@mcneil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 11:14:33 -0000 Sean McNeil wrote: > > On Jan 31, 2006, at 3:52 PM, Robert Watson wrote: > >> >> On Sat, 28 Jan 2006, Sean McNeil wrote: >> >>> I was wondering if this was on purpose. Seems like there is no good >>> reason that it was done on -STABLE and it has really messed up >>> everything here for me. >>> >>> libcom_err.so.2 bumped to libcom_err.so.3. >> >> It was on purpose, but not necessarily for a good reason. Could you >> be more specific about "really messed up everything here for me", >> which sounds a lot to me like "and all hell broken loose"? I assume >> there's some sort of library and application versioning problem, but >> some details would be helpful. > > I had several big packages that depended on kerberos and they all broke > because: > > 1) libcom_err.so.2.1 was moved to /usr/local/lib/compat/pkg/ > 2) The symlink libcom_err.so.2 was removed and nothing was placed in > compat. > > I finally got smart and just added an entry to libmap.conf and so I'm > not "really messed up...". That was not accurate in the first place :) > >> In principle, other than potentially requiring compat libs to run old >> binaries even though that may not strictly have been necessary, it >> seems likely that a binary depending on the old libcom_err depends >> also on an old libc. On the other hand, I consider library version >> number interactions to be mysterious, and likely have missed the >> point. :-) > > The point I am making is that this is in the -STABLE tree, not the > -CURRENT tree. There is no bump of libc and I don't see any reason for > the libcom_err.so revision bump in -STABLE. IMHO, it didn't make sense. Do you, by any chance, have security/heimdal installed? If so, this seems like a portupgrade job. Cheers, Panagiotis From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 11:21:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95ABA16A420; Wed, 1 Feb 2006 11:21:46 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C66043D5A; Wed, 1 Feb 2006 11:21:46 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 83C8E46B10; Wed, 1 Feb 2006 06:21:36 -0500 (EST) Date: Wed, 1 Feb 2006 11:23:40 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sean McNeil In-Reply-To: Message-ID: <20060201112123.F57400@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 11:21:46 -0000 On Tue, 31 Jan 2006, Sean McNeil wrote: > On Jan 31, 2006, at 6:25 PM, Daniel Eischen wrote: > >> On Tue, 31 Jan 2006, Sean McNeil wrote: >>> >>> The point I am making is that this is in the -STABLE tree, not the - >>> CURRENT tree. There is no bump of libc and I don't see any reason >>> for the libcom_err.so revision bump in -STABLE. IMHO, it didn't make >>> sense. >> >> I don't think it was -stable at the time. It was probably >> 6.0-current and the version bump occurred just before the >> release. As a -current user, you are expected to be able >> to deal with this and rebuild all your ports if necessary. > > This is EXACTLY what I am saying. I am not a -current user, I am a -stable > user and this happened about a week ago or so. It was libcom_err.so.2.1 > until just recently. ---------------------------- revision 1.3 date: 2005/07/22 17:18:58; author: kensmith; state: Exp; lines: +1 -1 Bump the shared library version number of all libraries that have not been bumped since RELENG_5. Reviewed by: ru Approved by: re (not needed for commit check but in principle...) ---------------------------- The commit was made last year, but I'm guessing something changed last week in your local tree. The real question is what. Did you run any tools intended to sweep aside old or unused libraries? Did you upgrade across branches? Do you know about what date RELENG_6 you were running before/after your upgrade? Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 11:36:03 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4969B16A420; Wed, 1 Feb 2006 11:36:03 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFEAA43D45; Wed, 1 Feb 2006 11:36:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1A20646B10; Wed, 1 Feb 2006 06:35:54 -0500 (EST) Date: Wed, 1 Feb 2006 11:37:57 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sean McNeil In-Reply-To: <1138786880.99058.3.camel@triton.mcneil.com> Message-ID: <20060201113447.C57400@fledge.watson.org> References: <43E05ED9.9000900@FreeBSD.org> <1138786880.99058.3.camel@triton.mcneil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , Doug Barton , current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 11:36:03 -0000 On Wed, 1 Feb 2006, Sean McNeil wrote: >> I don't know where you got libcom_err.so.2.1, but I don't think it's from a >> FreeBSD system. > > This turned out to be an errant port that was installing > /usr/local/lib/libcom_err.so.2.1 and I guess was later fixed. Seems like it > might have been the fault of cracklib. Sorry for the confusion and noise. > > When I saw libcom_err was part of the base system I made a false assumption > that a revision bump caused the problem. I should have investigated it > further before opening my mouth (email program). Mmmm. Sounds like rather errant behavior for a port, but likely due to Kerberos, which requires rather devious methods to integrate with the base system. It would be interesting to know which binaries depend on the old library -- if you portupgrade'd something that previously provided the old libcom_err, and perhaps not something that depended on it, you may have ended up with a stale binary. If run recursively, portupgrade is generally pretty good about that, so the variant scenario is that you installed something that replaced base system binaries that existed in an old release of FreeBSD, but not a new one, so portupgrade didn't want to delete them. I.e., k5init, which is now just kinit. In the old world order, a port installing k5init would have been overwriting the base system k5init, but in the new world order, there is no base system k5init. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 11:51:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40BA716A420 for ; Wed, 1 Feb 2006 11:51:03 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: from melamine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id E963643D58 for ; Wed, 1 Feb 2006 11:51:01 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melamine.cuivre.fr.eu.org (Postfix, from userid 1000) id C867F5C41D; Wed, 1 Feb 2006 12:51:00 +0100 (CET) Date: Wed, 1 Feb 2006 12:51:00 +0100 From: Thomas Quinot To: Michiel Boland Message-ID: <20060201115100.GI12912@melamine.cuivre.fr.eu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: boot problem with atapicam X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 11:51:03 -0000 * Michiel Boland, 2006-01-21 : > acd0: setting PIO4 on 8237 chip > acd0: setting UDMA33 on 8237 chip > acd0: DVDR drive at ata1 as master What happens if you disable acd? Thomas. From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 12:08:24 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7147316A420 for ; Wed, 1 Feb 2006 12:08:24 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: from melamine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FB8E43D6E for ; Wed, 1 Feb 2006 12:08:23 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melamine.cuivre.fr.eu.org (Postfix, from userid 1000) id D28AA5C41A; Wed, 1 Feb 2006 13:08:22 +0100 (CET) Date: Wed, 1 Feb 2006 13:08:22 +0100 From: Thomas Quinot To: Michiel Boland Message-ID: <20060201120822.GA14034@melamine.cuivre.fr.eu.org> References: <20060201115100.GI12912@melamine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.11 Cc: freebsd-current@FreeBSD.ORG Subject: Re: boot problem with atapicam X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 12:08:24 -0000 * Michiel Boland, 2006-02-01 : > Does not matter. I cvsup-ed again over the weekend and now atapicam works > again. OK, thanks for reporting. Thomas. From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 12:04:19 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BBF916A420; Wed, 1 Feb 2006 12:04:19 +0000 (GMT) (envelope-from Michiel.Boland@internl.net) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id D348A43D48; Wed, 1 Feb 2006 12:04:18 +0000 (GMT) (envelope-from Michiel.Boland@internl.net) Received: from brakkenstein.nijmegen.internl.net by neerbosch.nijmegen.internl.net via brakkenstein.nijmegen.internl.net [217.149.193.41] with ESMTP id k11C4GpP023112 (8.13.2/1.4); Wed, 1 Feb 2006 13:04:16 +0100 (MET) Received: from localhost by brakkenstein.nijmegen.internl.net via mboland@localhost with ESMTP id k11C4Gnf000651 (8.13.2/2.02); Wed, 1 Feb 2006 13:04:16 +0100 (MET) X-Authentication-Warning: brakkenstein.nijmegen.internl.net: mboland owned process doing -bs Date: Wed, 1 Feb 2006 13:04:16 +0100 (MET) From: Michiel Boland To: Thomas Quinot In-Reply-To: <20060201115100.GI12912@melamine.cuivre.fr.eu.org> Message-ID: References: <20060201115100.GI12912@melamine.cuivre.fr.eu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 01 Feb 2006 12:29:57 +0000 Cc: freebsd-current@FreeBSD.ORG Subject: Re: boot problem with atapicam X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 12:04:19 -0000 On Wed, 1 Feb 2006, Thomas Quinot wrote: > * Michiel Boland, 2006-01-21 : > >> acd0: setting PIO4 on 8237 chip >> acd0: setting UDMA33 on 8237 chip >> acd0: DVDR drive at ata1 as master > > What happens if you disable acd? Does not matter. I cvsup-ed again over the weekend and now atapicam works again. From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 12:46:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9E5D16A420 for ; Wed, 1 Feb 2006 12:46:25 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6D1943D45 for ; Wed, 1 Feb 2006 12:46:24 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-8) with SMTP id k11CkMx6025223; Wed, 1 Feb 2006 14:46:22 +0200 Received: by flame.pc (Postfix, from userid 1001) id 1D3F81152D; Wed, 1 Feb 2006 14:45:52 +0200 (EET) Date: Wed, 1 Feb 2006 14:45:51 +0200 From: Giorgos Keramidas To: Steve Kargl Message-ID: <20060201124551.GE33948@flame.pc> References: <20060131212209.GA870@troutmask.apl.washington.edu> <20060201010157.GA604@troutmask.apl.washington.edu> <20060201042122.GA27796@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060201042122.GA27796@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: panic: Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 12:46:25 -0000 On 2006-01-31 20:21, Steve Kargl wrote: > > Thing are looking positively horrid. A kernel from a cvsup with > > a date=2006.01.25.00.00.00 appears to work fine. A kernel from with > > date=2006.01.27.00.00.00 dies with > > > > dev_relthread() at dev_relthread+0x2e > > devfs_close() at devfs_close+0x1b6 > > VOP_CLOSE_APV() at VOP_CLOSE_APV+0x74 > > vn_close() at vn_close+0x8d > > vn_closefile() at vn_closefile+0x5a > > fdrop_locked() at fdrop_locked+0xa1 > > closef() at closef+0x35f > > fdfree() at fdfree+0x513 > > exit1() at exit1+0x360 > > sys_exit() at sys_exit+0xe > > a 2006.01.26.12.00.00.00 kernel dies a similar death. > Unfortnately, this panic took out a portion of /usr/include > and /usr/src. I can't prove it yet, but I think the > pts code may be the trigger. With a kernel & userland built with DEBUG_FLAGS='-g' from last night, I manager to kill my amd64 laptop completely. The last kernel I had working fine is from 25/Jan/2006, so something after this is that broke. The bug here manifests as unusable vty's in multiuser mode, but things seem to work relatively ok in single-user mode (i.e. I see no panics, yet). I've reinstalled 5.4-RELEASE from a CD-ROM, so bringing this up to CURRENT of 25-Jan will take a while though :( From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 13:41:45 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4366316A422 for ; Wed, 1 Feb 2006 13:41:45 +0000 (GMT) (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 9577143D4C for ; Wed, 1 Feb 2006 13:41:44 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (xydilc@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k11DfbXP008942 for ; Wed, 1 Feb 2006 14:41:43 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k11Dfbq1008941; Wed, 1 Feb 2006 14:41:37 +0100 (CET) (envelope-from olli) Date: Wed, 1 Feb 2006 14:41:37 +0100 (CET) Message-Id: <200602011341.k11Dfbq1008941@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <43DFB1DC.2020001@elischer.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 01 Feb 2006 14:41:43 +0100 (CET) X-Mailman-Approved-At: Wed, 01 Feb 2006 13:48:37 +0000 Cc: Subject: nextboot (was Re: boot block differences between 4.x and 6.x ?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@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: Wed, 01 Feb 2006 13:41:45 -0000 Julian Elischer wrote: > Oliver Fromme wrote: > > [...] > > I think the most visible changes in the boot blocks was > > UFS2 support and the removal of nextboot(8) support. > > which I hope to put back because we continue to need it. I agree that it's needed. It's a very useful feature. > (The new nextboot being dependent on the root filesystem still being ok > which is unacceptable to most embedded devices I've worked on, and why > we still use the old bootblocks on all systems shipped.). >From my point of view, the biggest problem with the old nextboot was the fact that it ignored loader(8) and tried to load the kernel directly. While that might work under certain conditions, it's not good in general. Therefore I think that a new nextboot implementation should be implemented in loader itself. Since loader(8) doesn't (and shouldn't) support writing to UFS2, the state information should be written to an unused area in block 2 on the disk, or something similar. In fact, one byte is sufficient: It can be used as an index into a table (ASCII text file), e.g. /boot/nextboot.conf. Would that be feasible to implement? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "It combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript." -- Jamie Zawinski, when asked: "What's wrong with perl?" From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 16:12:28 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 702C716A420; Wed, 1 Feb 2006 16:12:28 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5974D43D60; Wed, 1 Feb 2006 16:12:27 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 7485828 for multiple; Wed, 01 Feb 2006 11:12:59 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k11GCJKX093206; Wed, 1 Feb 2006 11:12:23 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Stefan Ehmann Date: Wed, 1 Feb 2006 10:44:42 -0500 User-Agent: KMail/1.9.1 References: <200601311739.27980.jhb@freebsd.org> <1138788002.701.0.camel@localhost> In-Reply-To: <1138788002.701.0.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602011044.44271.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1264/Wed Feb 1 07:38:31 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: anholt@freebsd.org, current@freebsd.org Subject: Re: Patch to fix i915 drm with vgapci changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 16:12:28 -0000 On Wednesday 01 February 2006 05:00, Stefan Ehmann wrote: > On Tue, 2006-01-31 at 17:39 -0500, John Baldwin wrote: > > This patch uses an identify routine in the agp driver to add the agp > > child to vgapci instead of having vgapci guess based on the PCIY_AGP > > capability. Patch is at > > http://www.FreeBSD.org/~jhb/patches/agp_vgapci.patch > > Doesn't compile because of missing return statement. > > Otherwise it works fine for me. Sorry, that's because the identify routine is supposed to return void. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 16:41:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E60C416A422 for ; Wed, 1 Feb 2006 16:41:25 +0000 (GMT) (envelope-from dscheidt@panix.com) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8535943D4C for ; Wed, 1 Feb 2006 16:41:25 +0000 (GMT) (envelope-from dscheidt@panix.com) Received: from panix1.panix.com (panix1.panix.com [166.84.1.1]) by mail1.panix.com (Postfix) with ESMTP id 93D2658B3A; Wed, 1 Feb 2006 11:41:24 -0500 (EST) Received: (from dscheidt@localhost) by panix1.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k11GfOO15956; Wed, 1 Feb 2006 11:41:24 -0500 (EST) Date: Wed, 1 Feb 2006 11:41:24 -0500 From: David Scheidt To: Alexander Leidinger Message-ID: <20060201164124.GA28139@panix.com> References: <17373.50882.270841.554876@roam.psg.com> <43DECB94.50307@lclark.edu> <17375.1454.11511.502872@roam.psg.com> <20060131102914.660ukp2ko4wgogoc@netchild.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060131102914.660ukp2ko4wgogoc@netchild.homeip.net> User-Agent: Mutt/1.5.10i Cc: Randy Bush , Eric Anholt , FreeBSD Current Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 16:41:26 -0000 On Tue, Jan 31, 2006 at 10:29:14AM +0100, Alexander Leidinger wrote: > Date: Tue, 31 Jan 2006 10:29:14 +0100 > From: Alexander Leidinger > To: Randy Bush > Cc: Eric Anholt , > FreeBSD Current > Subject: Re: xorg 6.9.0 mem leak > > Randy Bush wrote: > > >>Note that any app leaking pixmaps or other X resources will > >>have those resources charged to X, not the app. xrestop can > >>find offenders usually if it's some app's fault. > > > >so it's firefox. thanks. > > I can confirm that I see something like this too. At work on Solaris 10 with > Firefox 1.5 I notice a sudden death of firefox when I let BigBrother refresh I'm running firefox 1.5 on a fairly recent 6-STABLE, and see massive memory leaks. They seem to be related to javascript. From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 16:59:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 139CA16A422 for ; Wed, 1 Feb 2006 16:59:41 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84BB743D58 for ; Wed, 1 Feb 2006 16:59:40 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.3/8.13.1) with ESMTP id k11GxcSv028787 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 1 Feb 2006 17:59:38 +0100 (CET) (envelope-from mime@traveller.cz) From: Michal Mertl To: freebsd-current@freebsd.org Content-Type: text/plain Date: Wed, 01 Feb 2006 17:59:33 +0100 Message-Id: <1138813174.1358.34.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: em(4) stops forwarding X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 16:59:41 -0000 Hello, I've been running CURRENT for long time and never experienced problem with the built-in em(4) card before. Recently (I first noticed it on Jan 24) the card has stopped working several times. Nothing gets into the log file. Carrier is still detected properly but no data is exchanged. Ifconfig up/down doesn't help but kldunload/load does. When I run tcpdump I don't see any packet coming in but I see some outgoing. Can someone suggest what to look at when it happens the next time? I have DDB compiled in. I will try to sniff the wire using another machine next time to see if the card sends out anything. The command 'pciconf -lv' says about the card this: em0@pci2:1:0: class=0x020000 card=0x05491014 chip=0x101e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82540EP Gigabit Ethernet Controller (Mobile)' class = network subclass = ethernet The dmesg: em0: port 0x8000-0x803f mem 0xc0220000-0xc023ffff,0xc0200000-0xc020ffff irq 11 at device 1.0 on pci2 em0: Ethernet address: 00:0d:60:cd:ae:e2 em0: [FAST] The interrupt is shared since the machine is a notebook. I don't know if it was just a coincidence but I think that it happened at the same time as my USB mouse stopped working - the USB controller is on the same irq. Michal From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 17:39:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0CCB16A420 for ; Wed, 1 Feb 2006 17:39:04 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39CE543D46 for ; Wed, 1 Feb 2006 17:39:04 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 7492588 for multiple; Wed, 01 Feb 2006 12:39:38 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k11Hd2m2094204; Wed, 1 Feb 2006 12:39:02 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 1 Feb 2006 12:40:10 -0500 User-Agent: KMail/1.9.1 References: <200602011341.k11Dfbq1008941@lurza.secnetix.de> In-Reply-To: <200602011341.k11Dfbq1008941@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602011240.11682.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1264/Wed Feb 1 07:38:31 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Oliver Fromme Subject: Re: nextboot (was Re: boot block differences between 4.x and 6.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: Wed, 01 Feb 2006 17:39:04 -0000 On Wednesday 01 February 2006 08:41, Oliver Fromme wrote: > Julian Elischer wrote: > > Oliver Fromme wrote: > > > [...] > > > I think the most visible changes in the boot blocks was > > > UFS2 support and the removal of nextboot(8) support. > > > > which I hope to put back because we continue to need it. > > I agree that it's needed. It's a very useful feature. > > > (The new nextboot being dependent on the root filesystem still being ok > > which is unacceptable to most embedded devices I've worked on, and why > > we still use the old bootblocks on all systems shipped.). > > > >From my point of view, the biggest problem with the old > > nextboot was the fact that it ignored loader(8) and tried > to load the kernel directly. While that might work under > certain conditions, it's not good in general. > > Therefore I think that a new nextboot implementation > should be implemented in loader itself. Since loader(8) > doesn't (and shouldn't) support writing to UFS2, the > state information should be written to an unused area in > block 2 on the disk, or something similar. In fact, one > byte is sufficient: It can be used as an index into a > table (ASCII text file), e.g. /boot/nextboot.conf. > > Would that be feasible to implement? /boot/loader already does nextboot and does it by using UFS writing (which it does implement and use on archs whose disk drivers support writing such as i386) to overwrite (but not extend) /boot/nextboot.conf. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 18:22:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38AD416A422 for ; Wed, 1 Feb 2006 18:22:12 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4764D43D7B for ; Wed, 1 Feb 2006 18:22:01 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 2460C5E48EE; Wed, 1 Feb 2006 10:22:01 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 214A65E48BB; Wed, 1 Feb 2006 10:21:56 -0800 (PST) In-Reply-To: <17374.36245.570152.464206@roam.psg.com> References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Wed, 1 Feb 2006 10:21:53 -0800 To: Randy Bush X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: current@freebsd.org, Kris Kennaway Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 18:22:12 -0000 On Jan 30, 2006, at 2:05 PM, Randy Bush wrote: >>> and the Xorg one just keeps growing and growing and growing. >> That's a different matter though. > > and that's my point > >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU >> COMMAND >> 2166 randy 4 20 0 166M 108M kserel 3:51 0.00% >> firefox-bin >> 1343 randy 1 96 0 126M 83500K select 2:44 2.00% >> Xorg >> 1394 randy 4 20 0 102M 51456K kserel 0:08 0.00% >> nautilus > > and now > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU > COMMAND > 2166 randy 4 20 0 166M 110M kserel 4:26 0.00% > firefox-bin > 1343 randy 1 96 0 142M 86032K select 3:14 2.39% Xorg > 1394 randy 4 20 0 102M 51456K kserel 0:08 0.00% > nautilus > > notice the growth in xorg and only xorg. > > and, from x's pov, all i have been doing is typing in an emacs window, > thought there are 42 other windows open. > > and it will just keep growing if i walk away for a few hours. I've been running Xorg, firefox, and emacs, since last night (with jemalloc's redzone code enabled) on a two-day-old -current build, and after many invocations of firefox and emacs, with serious attempts to make firefox use lots of memory, Xorg's, memory usage has stabilized at ~75 MB mapped, and ~35 MB resident. Neither number has increased this morning (other than fluctuations when launching/terminating firefox). I see no evidence that jemalloc is doing anything wrong, or that Xorg's memory usage is excessive when utilizing jemalloc. Perhaps gnome is causing issues for you. In any case, I'm not going to look into this any further unless someone provides concrete, detailed evidence that jemalloc is behaving badly. Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 18:25:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 037F816A420; Wed, 1 Feb 2006 18:25:17 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id A58DF43D45; Wed, 1 Feb 2006 18:25:16 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 9102C5E48BB; Wed, 1 Feb 2006 10:25:16 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 1816A5E48BB; Wed, 1 Feb 2006 10:25:16 -0800 (PST) In-Reply-To: <200602011424.57722.doconnor@gsoft.com.au> References: <200601301652.16237.doconnor@gsoft.com.au> <1713BECB-9E36-4D12-A063-46AB2EC0AB2F@freebsd.org> <200601311805.07556.doconnor@gsoft.com.au> <200602011424.57722.doconnor@gsoft.com.au> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Wed, 1 Feb 2006 10:25:13 -0800 To: Daniel O'Connor X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org, Michael Nottebrock , Kris Kennaway Subject: Re: KDE 3.5.0 seems much chubbier than 3.4.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 18:25:17 -0000 On Jan 31, 2006, at 7:54 PM, Daniel O'Connor wrote: > Is there a simple way to revert to the old malloc? Just back out > malloc.c? Yes, you can revert to revision 1.92 of src/lib/libc/stdlib/malloc.c . Jason From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 18:29:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AAF016A420 for ; Wed, 1 Feb 2006 18:29:25 +0000 (GMT) (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 E409643D45 for ; Wed, 1 Feb 2006 18:29:23 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k11ITKka034282; Wed, 1 Feb 2006 11:29:21 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43E0FE09.50804@samsco.org> Date: Wed, 01 Feb 2006 11:29:29 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Mertl References: <1138813174.1358.34.camel@genius.i.cz> In-Reply-To: <1138813174.1358.34.camel@genius.i.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: em(4) stops forwarding X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 18:29:25 -0000 Michal Mertl wrote: > Hello, > > I've been running CURRENT for long time and never experienced problem > with the built-in em(4) card before. Recently (I first noticed it on Jan > 24) the card has stopped working several times. Nothing gets into the > log file. Carrier is still detected properly but no data is exchanged. > Ifconfig up/down doesn't help but kldunload/load does. When I run > tcpdump I don't see any packet coming in but I see some outgoing. > > Can someone suggest what to look at when it happens the next time? I > have DDB compiled in. I will try to sniff the wire using another machine > next time to see if the card sends out anything. > > The command 'pciconf -lv' says about the card this: > em0@pci2:1:0: class=0x020000 card=0x05491014 chip=0x101e8086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82540EP Gigabit Ethernet Controller (Mobile)' > class = network > subclass = ethernet > > The dmesg: > em0: port > 0x8000-0x803f mem 0xc0220000-0xc023ffff,0xc0200000-0xc020ffff irq 11 at > device 1.0 on pci2 > em0: Ethernet address: 00:0d:60:cd:ae:e2 > em0: [FAST] > > The interrupt is shared since the machine is a notebook. I don't know if > it was just a coincidence but I think that it happened at the same time > as my USB mouse stopped working - the USB controller is on the same irq. > > Michal > What is sharing the interrupt? Scott From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 18:33:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7796016A420; Wed, 1 Feb 2006 18:33:27 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02CE243D64; Wed, 1 Feb 2006 18:33:27 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4MnG-000LPq-1H; Wed, 01 Feb 2006 18:33:26 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4MnF-0001Nn-7P; Wed, 01 Feb 2006 10:33:25 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17376.65268.396436.72837@roam.psg.com> Date: Wed, 1 Feb 2006 10:33:24 -0800 To: "Daniel O'Connor" References: <200601301652.16237.doconnor@gsoft.com.au> <1713BECB-9E36-4D12-A063-46AB2EC0AB2F@freebsd.org> <200601311805.07556.doconnor@gsoft.com.au> <200602011424.57722.doconnor@gsoft.com.au> Cc: Kris Kennaway , freebsd-current@freebsd.org, Jason Evans , Michael Nottebrock Subject: Re: KDE 3.5.0 seems much chubbier than 3.4.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 18:33:27 -0000 >> Hmm, not sure it was unbounded, but it was certainly consuming a lot of >> extra memory. Note that with the debugging off top shows it as.. >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND >> 19876 root 1 100 0 315M 136M select 18:16 13.67% Xorg > > Things still seem to be using more memory than I would expect.. Certainly my > laptop is swapping more than I expect :( > > Is there a simple way to revert to the old malloc? Just back out malloc.c? > I'd go back to KDE 3.4.2 but that is a lot more complex :) been there. it was the recent firefox. randy From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 18:46:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F242016A422 for ; Wed, 1 Feb 2006 18:46:43 +0000 (GMT) (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 E89B543D5F for ; Wed, 1 Feb 2006 18:46:33 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k11IkWvO011036; Wed, 1 Feb 2006 10:46:32 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k11IkWXY011035; Wed, 1 Feb 2006 10:46:32 -0800 (PST) (envelope-from sgk) Date: Wed, 1 Feb 2006 10:46:32 -0800 From: Steve Kargl To: Andrew Gallatin Message-ID: <20060201184632.GA94815@troutmask.apl.washington.edu> References: <200601311109.k0VB9MRq025366@repoman.freebsd.org> <20060201104752.A68774@grasshopper.cs.duke.edu> <20060201160923.GA67621@troutmask.apl.washington.edu> <17376.58731.618704.264566@grasshopper.cs.duke.edu> <20060201171754.GA67925@troutmask.apl.washington.edu> <20060201125456.A68851@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060201125456.A68851@grasshopper.cs.duke.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Memory modified panic -- was: Re: cvs commit: src/sys/kern kern_malloc.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 18:46:44 -0000 (cc'd to current) On Wed, Feb 01, 2006 at 12:54:56PM -0500, Andrew Gallatin wrote: > Steve Kargl [sgk@troutmask.apl.washington.edu] wrote: >> On Wed, Feb 01, 2006 at 11:44:27AM -0500, Andrew Gallatin wrote: >>> Steve Kargl writes: >>>> On Wed, Feb 01, 2006 at 10:47:52AM -0500, Andrew Gallatin wrote: >>>>> WARNING: WITNESS option enabled, expect reduced performance. >>>>> Memory modified after free 0xffffff0000006d00(248) val=5 @ >>>>> 0xffffff0000006dd0 >>>>> kernel trap 9 with interrupts disabled >>>> >>>> You can trigger this panic without the red zone stuff. >>>> See my string of post from yesterday. Something went >>> >>> Your panic looks like the same panic as mine, but with memguard rather >>> than redzone. These systems do similar things, I suppose it is only >>> natural that they'd be hit by the same bug. >> >> You get it without memguard, too. Kris suggested that I try memguard >> to capture the problem. Unfortunately, memguard actually made >> matters worse in that I did not even make it to single user mode >> before a panic. > > Odd. I do not get it without using either memguard or redzone. > I have a (mostly generic) kernel with WITNESS & INVARIANTS > that boots fine. > > Maybe we should move this to -current or -amd64, as it does not > seem to be directly related to this commit.. The system boots without memguard or redzone here as well. However, I can panic the system with any significant load and filesystem activity. Currently, a "make buildworld" with a "gmake check-gfortran" in a GCC build tree will kill my system. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 19:05:58 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78CF316A420; Wed, 1 Feb 2006 19:05:58 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 184A843D49; Wed, 1 Feb 2006 19:05:57 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4NIj-000MDz-FY; Wed, 01 Feb 2006 19:05:57 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4NIi-0001RX-JX; Wed, 01 Feb 2006 11:05:56 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17377.1683.980768.797313@roam.psg.com> Date: Wed, 1 Feb 2006 11:05:55 -0800 To: Jason Evans References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> Cc: current@freebsd.org, Kris Kennaway Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 19:05:58 -0000 > I've been running Xorg, firefox, and emacs, since last night (with > jemalloc's redzone code enabled) on a two-day-old -current build, and > after many invocations of firefox and emacs, with serious attempts to > make firefox use lots of memory, Xorg's, memory usage has stabilized > at ~75 MB mapped, and ~35 MB resident. recent discussion somewhere casts suspicion on javascript. do you have it enabled? i am testing that hypothesis now. randy From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 19:07:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4669C16A420 for ; Wed, 1 Feb 2006 19:07:46 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9951E43D72 for ; Wed, 1 Feb 2006 19:07:35 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 79BCD5E48EE; Wed, 1 Feb 2006 11:07:35 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id E57035E48E5; Wed, 1 Feb 2006 11:07:30 -0800 (PST) In-Reply-To: <17377.1683.980768.797313@roam.psg.com> References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> <17377.1683.980768.797313@roam.psg.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88599CE0-9255-40A1-8713-B7184146842E@freebsd.org> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Wed, 1 Feb 2006 11:07:27 -0800 To: Randy Bush X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: current@freebsd.org, Kris Kennaway Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 19:07:46 -0000 On Feb 1, 2006, at 11:05 AM, Randy Bush wrote: >> I've been running Xorg, firefox, and emacs, since last night (with >> jemalloc's redzone code enabled) on a two-day-old -current build, and >> after many invocations of firefox and emacs, with serious attempts to >> make firefox use lots of memory, Xorg's, memory usage has stabilized >> at ~75 MB mapped, and ~35 MB resident. > > recent discussion somewhere casts suspicion on javascript. do you > have it enabled? i am testing that hypothesis now. Yes, I had javascript enabled for much of the time I was running firefox. Jason From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 19:15:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7BDD16A420; Wed, 1 Feb 2006 19:15:40 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61CD943D46; Wed, 1 Feb 2006 19:15:40 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4NS7-000MT6-W8; Wed, 01 Feb 2006 19:15:40 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4NS7-0001Sn-76; Wed, 01 Feb 2006 11:15:39 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17377.2266.614310.573994@roam.psg.com> Date: Wed, 1 Feb 2006 11:15:38 -0800 To: Jason Evans References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> Cc: current@freebsd.org, Kris Kennaway Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 19:15:41 -0000 > I've been running Xorg, firefox, and emacs, since last night (with > jemalloc's redzone code enabled) on a two-day-old -current build btw, when was the firefox built? i am on $FreeBSD: ports/www/firefox/Makefile,v 1.145 2005/12/15 17:11:32 marcus Exp $ randy From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 19:22:18 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AFA716A420 for ; Wed, 1 Feb 2006 19:22:18 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAF3343D48 for ; Wed, 1 Feb 2006 19:22:17 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 96B455E48EE; Wed, 1 Feb 2006 11:22:17 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id F13B65E4893; Wed, 1 Feb 2006 11:22:15 -0800 (PST) In-Reply-To: <17377.2266.614310.573994@roam.psg.com> References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> <17377.2266.614310.573994@roam.psg.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Wed, 1 Feb 2006 11:22:13 -0800 To: Randy Bush X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: current@freebsd.org Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 19:22:18 -0000 On Feb 1, 2006, at 11:15 AM, Randy Bush wrote: >> I've been running Xorg, firefox, and emacs, since last night (with >> jemalloc's redzone code enabled) on a two-day-old -current build > > btw, when was the firefox built? i am on > > $FreeBSD: ports/www/firefox/Makefile,v 1.145 2005/12/15 17:11:32 > marcus Exp > $ I built firefox yesterday, using the same version of the port Makefile as above. Jason From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 19:27:37 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6055E16A420 for ; Wed, 1 Feb 2006 19:27:37 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC6DF43D46 for ; Wed, 1 Feb 2006 19:27:36 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Ndg-000Mn2-B1; Wed, 01 Feb 2006 19:27:36 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Ndf-0001UH-ID; Wed, 01 Feb 2006 11:27:35 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17377.2983.58360.592928@roam.psg.com> Date: Wed, 1 Feb 2006 11:27:35 -0800 To: David Scheidt References: <17373.50882.270841.554876@roam.psg.com> <43DECB94.50307@lclark.edu> <17375.1454.11511.502872@roam.psg.com> <20060131102914.660ukp2ko4wgogoc@netchild.homeip.net> <20060201164124.GA28139@panix.com> Cc: FreeBSD Current Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 19:27:37 -0000 > I'm running firefox 1.5 on a fairly recent 6-STABLE, and see massive > memory leaks. They seem to be related to javascript. if i turn javascript off, the leak continues 5000000 2053 45 1 16578 451 657355K 60K 657416K ? washingtonpo 5000000 2053 45 1 16801 450 667667K 60K 667727K ? washingtonpo 5000000 483 44 1 16800 143 667685K 16K 667702K ? washingtonpo 5000000 483 44 1 16852 144 673796K 16K 673813K ? washingtonpo 5000000 483 44 1 17023 145 677964K 16K 677981K ? washingtonpo given the inability of Jason Evans to replicate. we need to think a bit about a forward debugging path. randy From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 19:48:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DDAC16A422; Wed, 1 Feb 2006 19:48:13 +0000 (GMT) (envelope-from dougb@freebsd.org) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id E861C43D4C; Wed, 1 Feb 2006 19:48:08 +0000 (GMT) (envelope-from dougb@freebsd.org) Received: from [192.168.1.101] (70-32-110-40.vnnyca.adelphia.net[70.32.110.40]) by comcast.net (rwcrmhc13) with ESMTP id <20060201194302m1300akn3de>; Wed, 1 Feb 2006 19:43:02 +0000 Message-ID: <43E10F45.90601@FreeBSD.org> Date: Wed, 01 Feb 2006 11:43:01 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Sean McNeil References: <43E05ED9.9000900@FreeBSD.org> <1138786880.99058.3.camel@triton.mcneil.com> In-Reply-To: <1138786880.99058.3.camel@triton.mcneil.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Robert Watson , current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 19:48:13 -0000 Sean McNeil wrote: > This turned out to be an errant port that was > installing /usr/local/lib/libcom_err.so.2.1 and I guess was later fixed. > Seems like it might have been the fault of cracklib. Sorry for the > confusion and noise. No worries, glad to hear that it's sorted out for you. As Robert said, if you can figure out exactly what port it is that caused this error, it would be useful if you could mention it on freebsd-ports@. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 19:59:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3135616A420 for ; Wed, 1 Feb 2006 19:59:35 +0000 (GMT) (envelope-from air.lightz@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63BAA43D45 for ; Wed, 1 Feb 2006 19:59:34 +0000 (GMT) (envelope-from air.lightz@gmail.com) Received: by uproxy.gmail.com with SMTP id k3so2513ugf for ; Wed, 01 Feb 2006 11:59:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=hh7wh0xr8KHFSwQNfEnINKJHajg5MmTg+0TV/4cf2hPAtan/m8YhPNN3paVom3iMrf+sYL599T/N4rx5vkJNrEdffovLlHTBNY58SKQxXB3nnCLuTvuesfHN0LumQgn0Zjdqlp9kztIX4xytdBFJhLGoLMtdJypWCis6g0/8x+0= Received: by 10.48.80.8 with SMTP id d8mr1553600nfb; Wed, 01 Feb 2006 11:59:32 -0800 (PST) Received: by 10.49.26.14 with HTTP; Wed, 1 Feb 2006 11:59:32 -0800 (PST) Message-ID: <1b62a7390602011159l6c43827ei31e25e2d315185a3@mail.gmail.com> Date: Wed, 1 Feb 2006 14:59:32 -0500 From: Ryan R To: freebsd-current@freebsd.org MIME-Version: 1.0 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 Subject: For the love of God, is it even possible to make the Atheros ath.patch & updated HAL actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 19:59:35 -0000 *Sigh* Hi again everyone.. I'm a novice BSD user who recently purchased an Atheros wireless card. The card is an "Engenius EMP 8602", 6th Generation Atheros AR5006 a/b/g chipset= . ( http://www.netgate.com/product_info.php?products_id=3D279 for product specs). I have been racking my brain for DAYS trying to get Sam Leffler's ( http://people.freebsd.org/~sam ) ath.patch and updated HAL binary to work i= n *ANY* version of FreeBSD. First, I was told to do a MINIMAL install, then cvsup to RELENG_6 and attempt to apply the ath.patch. The patch fails at least 7 hunks in various places in various files, 90% of the failed hunks are in if_ath.c. I was then told to # cd /usr/src/sys/contrib/dev # mv ath ath.original # tar -xzvf ath_hal_20051212.tgz # mv ath_hal_20051212 ath to update the /usr/src/sys/contrib/dev directory. Well lo and behold, the bloody thing wont compile.. It spits out all kinds of errors from if_ath.c about 'undeclared functions' and 'needing more parameters to function' So I scrapped that installation and figured I'd give 7.0-CURRENT a try, in hopes that maybe the patch was FINALLY applied to the kernel for me, but nope.. It seems only tiny bits and pieces from the ath.patch have made it into the actual kernel source. The stock kernel source does not have enoug= h of the patch in it to make my wireless card work, and trying to apply the patch to the 7.0 kernel is a complete failure as well. So my question is; if the patch doesn't apply cleanly to either RELENG_6 no= r HEAD, then what the heck WILL it apply cleanly to? This FreeBSD installation is sitting here doing absolutely nothing because it's a complete waste on my Laptop since there is NO wireless support for it at all. Yet it works just fine in Linux.. Does anybody have even the slightest clue when this code may actually make it into the kernel sources? Or better yet, does the patch cleanly apply an= d compile for ANYBODY? I posted this on bsdforums.org and people there can't get it to compile either.. I e-mailed the author of the patch but I guess he's way too busy and didn't get a chance to respond to me I'm at my wits end here so any help would be appreciated, I really don't want to have to just depend on Linux or Windows XP for this system when I'v= e fallen in love with everything OTHER than this major problem in FreeBSD :( Thanks guys; anxiously awaiting any help -Ryan From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 20:02:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B992416A423 for ; Wed, 1 Feb 2006 20:02:23 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AD3543D45 for ; Wed, 1 Feb 2006 20:02:22 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 2B9E81A3C1F; Wed, 1 Feb 2006 12:02:22 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8097552167; Wed, 1 Feb 2006 15:02:21 -0500 (EST) Date: Wed, 1 Feb 2006 15:02:21 -0500 From: Kris Kennaway To: Randy Bush Message-ID: <20060201200221.GA31743@xor.obsecurity.org> References: <17373.50882.270841.554876@roam.psg.com> <43DECB94.50307@lclark.edu> <17375.1454.11511.502872@roam.psg.com> <20060131102914.660ukp2ko4wgogoc@netchild.homeip.net> <20060201164124.GA28139@panix.com> <17377.2983.58360.592928@roam.psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <17377.2983.58360.592928@roam.psg.com> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current , David Scheidt Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 20:02:23 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 01, 2006 at 11:27:35AM -0800, Randy Bush wrote: > > I'm running firefox 1.5 on a fairly recent 6-STABLE, and see massive > > memory leaks. They seem to be related to javascript.=20 >=20 > if i turn javascript off, the leak continues >=20 > 5000000 2053 45 1 16578 451 657355K 60K 657416K ? washin= gtonpo > 5000000 2053 45 1 16801 450 667667K 60K 667727K ? washin= gtonpo > 5000000 483 44 1 16800 143 667685K 16K 667702K ? washin= gtonpo > 5000000 483 44 1 16852 144 673796K 16K 673813K ? washin= gtonpo > 5000000 483 44 1 17023 145 677964K 16K 677981K ? washin= gtonpo >=20 > given the inability of Jason Evans to replicate. > we need to think a bit about a forward debugging path. It will presumably involve the firefox developers. Kris --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD4RPMWry0BWjoQKURAk6yAJsHjv+dH6KX2Jvi7WP30Ne1ps3NwACbBckh dunSLO3biAGaFSS5eTtpZZU= =ZQX2 -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 20:19:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FEB216A422 for ; Wed, 1 Feb 2006 20:19:33 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A70243E67 for ; Wed, 1 Feb 2006 20:16:03 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 01 Feb 2006 12:15:07 -0800 Message-ID: <43E116CA.9060201@elischer.org> Date: Wed, 01 Feb 2006 12:15:06 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <200602011341.k11Dfbq1008941@lurza.secnetix.de> In-Reply-To: <200602011341.k11Dfbq1008941@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: nextboot (was Re: boot block differences between 4.x and 6.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: Wed, 01 Feb 2006 20:19:33 -0000 Oliver Fromme wrote: >Julian Elischer wrote: > > Oliver Fromme wrote: > > > [...] > > > I think the most visible changes in the boot blocks was > > > UFS2 support and the removal of nextboot(8) support. > > > > which I hope to put back because we continue to need it. > >I agree that it's needed. It's a very useful feature. > > > (The new nextboot being dependent on the root filesystem still being ok > > which is unacceptable to most embedded devices I've worked on, and why > > we still use the old bootblocks on all systems shipped.). > >>From my point of view, the biggest problem with the old >nextboot was the fact that it ignored loader(8) and tried >to load the kernel directly. While that might work under >certain conditions, it's not good in general. > >Therefore I think that a new nextboot implementation >should be implemented in loader itself. Since loader(8) >doesn't (and shouldn't) support writing to UFS2, the >state information should be written to an unused area in >block 2 on the disk, or something similar. In fact, one >byte is sufficient: It can be used as an index into a >table (ASCII text file), e.g. /boot/nextboot.conf. > >Would that be feasible to implement? > > The old nextboot used the 2nd block of the filesystem to hold information. But I can't remember if it used that information itself at all to decide whether to load boot1/boot2 from another partition, or whether it just always loaded it from the first 8k of the forst BSD partition.. I believe the latter. If I had lots of time to do it, I think I'd want to make a 'bootconfig' partition that covered the place where the info is stored and then try and interpret SOME of the information recovered to decide what drive/slice to load the rest of the boot1/boot2 combo. When we wrote the original nextboot code, we wanted to select between two root partitions, so that a failure to boot would result in a fallback to the other root, but we didn't want the bootblock writing anywhere in a filesystem, nor did we want the we kept free otherwise. We were only concerned with one drive however. At Ironport we use the identical scheme again. Allowing one root partition to be upgraded (with a newfs if needed) while teh other is being run on, and then rebooting into the new one with confidence that if it fails to get all the way up another reboot would come back to the previous root. Having the information as to where to boot to, on one of those partitions is not an option.. it may be failing because the filesystem, is in fact screwed. >Best regards > Oliver > > > From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 20:21:18 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91B6016A46B; Wed, 1 Feb 2006 20:21:17 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6DF943E22; Wed, 1 Feb 2006 20:20:04 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 01 Feb 2006 12:20:05 -0800 Message-ID: <43E117F3.9090400@elischer.org> Date: Wed, 01 Feb 2006 12:20:03 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200602011341.k11Dfbq1008941@lurza.secnetix.de> <200602011240.11682.jhb@freebsd.org> In-Reply-To: <200602011240.11682.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Oliver Fromme Subject: Re: nextboot (was Re: boot block differences between 4.x and 6.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: Wed, 01 Feb 2006 20:21:19 -0000 John Baldwin wrote: >On Wednesday 01 February 2006 08:41, Oliver Fromme wrote: > > >>Julian Elischer wrote: >> > Oliver Fromme wrote: >> > > [...] >> > > I think the most visible changes in the boot blocks was >> > > UFS2 support and the removal of nextboot(8) support. >> > >> > which I hope to put back because we continue to need it. >> >>I agree that it's needed. It's a very useful feature. >> >> > (The new nextboot being dependent on the root filesystem still being ok >> > which is unacceptable to most embedded devices I've worked on, and why >> > we still use the old bootblocks on all systems shipped.). >> >> >>>From my point of view, the biggest problem with the old >> >>nextboot was the fact that it ignored loader(8) and tried >>to load the kernel directly. While that might work under >>certain conditions, it's not good in general. >> >>Therefore I think that a new nextboot implementation >>should be implemented in loader itself. Since loader(8) >>doesn't (and shouldn't) support writing to UFS2, the >>state information should be written to an unused area in >>block 2 on the disk, or something similar. In fact, one >>byte is sufficient: It can be used as an index into a >>table (ASCII text file), e.g. /boot/nextboot.conf. >> >>Would that be feasible to implement? >> >> > >/boot/loader already does nextboot and does it by using UFS writing (which it >does implement and use on archs whose disk drivers support writing such as >i386) to overwrite (but not extend) /boot/nextboot.conf. > > which is exactly the feature that I wanted to avoid with the original nextboot(8). Do NOT get any where-to-boot-from info from the possibly suspect filesystem. Do NOT write back to the "possibly-suspect-filesystem". The original nextboot was BIOS specific and not portable which is why the new one has some good points (portable), but it didn't rely on correctness of the bootblock FS code or an intact first FS. From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 21:27:23 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 233BC16A44A; Wed, 1 Feb 2006 21:27:23 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 745B943D48; Wed, 1 Feb 2006 21:27:15 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id 2D909579E; Wed, 1 Feb 2006 22:35:23 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on cvs.freesbie.org X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 Received: from [192.168.99.16] (host14-150.pool875.interbusiness.it [87.5.150.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP; Wed, 1 Feb 2006 22:35:22 +0100 (CET) Message-ID: <43E127A5.9060503@freesbie.org> Date: Wed, 01 Feb 2006 22:27:01 +0100 From: Dario Freni User-Agent: Mozilla Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Poul-Henning Kamp References: <3281.1138742578@critter.freebsd.dk> In-Reply-To: <3281.1138742578@critter.freebsd.dk> X-Enigmail-Version: 0.94.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF60174883D20568F7055FDA3" X-Virus-Scanned: ClamAV using ClamSMTP Cc: rizzo@icir.org, rwatson@freebsd.org, small@freebsd.org, "M. Warner Losh" , current@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 21:27:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF60174883D20568F7055FDA3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Poul-Henning Kamp ha scritto: > In message <20060131.131654.134137067.imp@bsdimp.com>, "M. Warner Losh"= writes: >> In message: <43DFC2D5.7040706@errno.com> >> Sam Leffler writes: >=20 >> Since I've started working on the bring up on an ARM based board, I've= >> been wanting something that is easy to work with and that worked. I >> think it would help us a lot in the embedded space if we had something= >> integrated into the base OS to do this stuff. >=20 > I agree. I think we need to be much more inclusive in our concept of > a 'release' than we are now. >=20 > As I see it, PicoBSD with its "additive" approach would cover the > low-capacity (<32 MB ?) range, NanoBSD with its "subtractive" approach > takes over from there, FreeSBIE covers the "don't touch my disk" > range and finally the full blown release as we know it. >=20 Actually, FreeSBIE 2 toolkit covers both approaches. It is successfully used in embedded enviroments. pfSense (www.pfsense.com) use it either for creating an install livecd as well as embedded images for soekris-like machines. It can perfectly act as NanoBSD (the only difference is the partitioning scheme which is trivial to reproduce by customizing FreeSBIE's image script). Nobody of you mind importing the toolkit in the source tree? :) --=20 Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --------------enigF60174883D20568F7055FDA3 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.1 (Darwin) iD8DBQFD4Serymi72IiShysRAqK2AJ9fiNtXlzHcpiDIBrGGT3QH+BCNxQCaAqvd bm3Meu90tj3qgOVPKS59mSI= =T553 -----END PGP SIGNATURE----- --------------enigF60174883D20568F7055FDA3-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 21:49:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6093216A420 for ; Wed, 1 Feb 2006 21:49:41 +0000 (GMT) (envelope-from atrens@nortel.com) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEE7043D45 for ; Wed, 1 Feb 2006 21:49:40 +0000 (GMT) (envelope-from atrens@nortel.com) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k11LnZj24155; Wed, 1 Feb 2006 16:49:35 -0500 (EST) Received: from [10.0.10.2] ([47.128.22.25] RDNS failed) by zcarhxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Feb 2006 16:49:20 -0500 Message-ID: <43E12CD1.1060702@nortel.com> Date: Wed, 01 Feb 2006 16:49:05 -0500 From: "Andrew Atrens" User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051129) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan R References: <1b62a7390602011159l6c43827ei31e25e2d315185a3@mail.gmail.com> In-Reply-To: <1b62a7390602011159l6c43827ei31e25e2d315185a3@mail.gmail.com> X-Enigmail-Version: 0.93.0.0 OpenPGP: id=A09D78CC; url= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2006 21:49:20.0300 (UTC) FILETIME=[5B4DF6C0:01C62779] X-Mailman-Approved-At: Wed, 01 Feb 2006 22:00:56 +0000 Cc: freebsd-current@freebsd.org Subject: Re: For the love of God, is it even possible to make the Atheros ath.patch & updated HAL actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 21:49:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ryan R wrote: > *Sigh* > > Hi again everyone.. > > I'm a novice BSD user who recently purchased an Atheros wireless card. The > card is an "Engenius EMP 8602", 6th Generation Atheros AR5006 a/b/g chipset. > ( http://www.netgate.com/product_info.php?products_id=279 for product > specs). > > I have been racking my brain for DAYS trying to get Sam Leffler's ( > http://people.freebsd.org/~sam ) ath.patch and updated HAL binary to work in > *ANY* version of FreeBSD. First, I was told to do a MINIMAL install, then > cvsup to RELENG_6 and attempt to apply the ath.patch. The patch fails at > least 7 hunks in various places in various files, 90% of the failed hunks > are in if_ath.c. I was then told to > > # cd /usr/src/sys/contrib/dev > # mv ath ath.original > # tar -xzvf ath_hal_20051212.tgz > # mv ath_hal_20051212 ath > > to update the /usr/src/sys/contrib/dev directory. Well lo and behold, the > bloody thing wont compile.. It spits out all kinds of errors from if_ath.c > about 'undeclared functions' and 'needing more parameters to function' > > So I scrapped that installation and figured I'd give 7.0-CURRENT a try, in > hopes that maybe the patch was FINALLY applied to the kernel for me, but > nope.. It seems only tiny bits and pieces from the ath.patch have made it > into the actual kernel source. The stock kernel source does not have enough > of the patch in it to make my wireless card work, and trying to apply the > patch to the 7.0 kernel is a complete failure as well. > > So my question is; if the patch doesn't apply cleanly to either RELENG_6 nor > HEAD, then what the heck WILL it apply cleanly to? This FreeBSD > installation is sitting here doing absolutely nothing because it's a > complete waste on my Laptop since there is NO wireless support for it at > all. Yet it works just fine in Linux.. > > > > Does anybody have even the slightest clue when this code may actually make > it into the kernel sources? Or better yet, does the patch cleanly apply and > compile for ANYBODY? I posted this on bsdforums.org and people there can't > get it to compile either.. I e-mailed the author of the patch but I guess > he's way too busy and didn't get a chance to respond to me > > I'm at my wits end here so any help would be appreciated, I really don't > want to have to just depend on Linux or Windows XP for this system when I've > fallen in love with everything OTHER than this major problem in FreeBSD :( Ryan, If I recall the ath patch was pretty small. You could try applying the bits manually. I'm using DragonFly .. I think it took me about an hour to manually merge in the changes. And it works for me now. Having said that, the new hal isn't entirely well behaved on FreeBSD (or DragonFly). Under load you'll see hw error interrupts and the occasional watchdog timeout. Not-under-load, it works just fine. Sam's aware of the problems, but has said that tracking down the root cause is non-trivial because the vap changes to the madwifi-ng code obscure the probable differences between it and the FreeBSD driver. I was thinking it was init or dma timing related. Sam thinks it might be calibration. I haven't been able to track it down (no time, and even if I had time it would still be a considerable challenge), and Sam, I believe, is short of time himself these days. I shouldn't speak for him actually. Sam ? Andrew. > > Thanks guys; anxiously awaiting any help > -Ryan > _______________________________________________ > 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" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD4SzO8It2CaCdeMwRAnAmAJ9lq6DFgBpfSLpQ7maob8ex39gFBwCgmSzh I1Gvsq5yE7wAGapl/oYrNek= =BKPd -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:04:14 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 945D616A420; Wed, 1 Feb 2006 22:04:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE93F43D70; Wed, 1 Feb 2006 22:04:09 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 01 Feb 2006 14:04:09 -0800 Message-ID: <43E13058.7020708@elischer.org> Date: Wed, 01 Feb 2006 14:04:08 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dario Freni References: <3281.1138742578@critter.freebsd.dk> <43E127A5.9060503@freesbie.org> In-Reply-To: <43E127A5.9060503@freesbie.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: small@freebsd.org, rizzo@icir.org, Poul-Henning Kamp , rwatson@freebsd.org, "M. Warner Losh" , current@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 22:04:14 -0000 Dario Freni wrote: >Poul-Henning Kamp ha scritto: > > >>In message <20060131.131654.134137067.imp@bsdimp.com>, "M. Warner Losh" writes: >> >> >>>In message: <43DFC2D5.7040706@errno.com> >>> Sam Leffler writes: >>> >>> >>>Since I've started working on the bring up on an ARM based board, I've >>>been wanting something that is easy to work with and that worked. I >>>think it would help us a lot in the embedded space if we had something >>>integrated into the base OS to do this stuff. >>> >>> >>I agree. I think we need to be much more inclusive in our concept of >>a 'release' than we are now. >> >>As I see it, PicoBSD with its "additive" approach would cover the >>low-capacity (<32 MB ?) range, NanoBSD with its "subtractive" approach >>takes over from there, FreeSBIE covers the "don't touch my disk" >>range and finally the full blown release as we know it. >> >> >> > >Actually, FreeSBIE 2 toolkit covers both approaches. It is successfully >used in embedded enviroments. pfSense (www.pfsense.com) use it either >for creating an install livecd as well as embedded images for >soekris-like machines. It can perfectly act as NanoBSD (the only >difference is the partitioning scheme which is trivial to reproduce by >customizing FreeSBIE's image script). > >Nobody of you mind importing the toolkit in the source tree? :) > > on the contrary i thin it should be there.. *somewhere*. the question is, "where?" I thought that's why you have access? From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:04:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAA0F16A420; Wed, 1 Feb 2006 22:04:54 +0000 (GMT) (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 3DB1543D5F; Wed, 1 Feb 2006 22:04:42 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k11M4bKL035456; Wed, 1 Feb 2006 15:04:37 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43E1307D.9030907@samsco.org> Date: Wed, 01 Feb 2006 15:04:45 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <200602011341.k11Dfbq1008941@lurza.secnetix.de> <200602011240.11682.jhb@freebsd.org> <43E117F3.9090400@elischer.org> In-Reply-To: <43E117F3.9090400@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Oliver Fromme Subject: Re: nextboot (was Re: boot block differences between 4.x and 6.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: Wed, 01 Feb 2006 22:04:55 -0000 Julian Elischer wrote: > John Baldwin wrote: > >> On Wednesday 01 February 2006 08:41, Oliver Fromme wrote: >> >> >>> Julian Elischer wrote: >>> > Oliver Fromme wrote: >>> > > [...] >>> > > I think the most visible changes in the boot blocks was >>> > > UFS2 support and the removal of nextboot(8) support. >>> > >>> > which I hope to put back because we continue to need it. >>> >>> I agree that it's needed. It's a very useful feature. >>> >>> > (The new nextboot being dependent on the root filesystem still >>> being ok >>> > which is unacceptable to most embedded devices I've worked on, and why >>> > we still use the old bootblocks on all systems shipped.). >>> >>> >>>> From my point of view, the biggest problem with the old >>> >>> >>> nextboot was the fact that it ignored loader(8) and tried >>> to load the kernel directly. While that might work under >>> certain conditions, it's not good in general. >>> >>> Therefore I think that a new nextboot implementation >>> should be implemented in loader itself. Since loader(8) >>> doesn't (and shouldn't) support writing to UFS2, the >>> state information should be written to an unused area in >>> block 2 on the disk, or something similar. In fact, one >>> byte is sufficient: It can be used as an index into a >>> table (ASCII text file), e.g. /boot/nextboot.conf. >>> >>> Would that be feasible to implement? >>> >> >> >> /boot/loader already does nextboot and does it by using UFS writing >> (which it does implement and use on archs whose disk drivers support >> writing such as i386) to overwrite (but not extend) /boot/nextboot.conf. >> >> > > which is exactly the feature that I wanted to avoid with the original > nextboot(8). > Do NOT get any where-to-boot-from info from the possibly suspect > filesystem. > Do NOT write back to the "possibly-suspect-filesystem". > > The original nextboot was BIOS specific and not portable which is why > the new one > has some good points (portable), but it didn't rely on correctness of the > bootblock FS code or an intact first FS. > It doesn't allocate new blocks or alter metadata. It only modifies existing data blocks. It is no more unsafe than mounting an unclean filesystem while bgfsck is running, and actually is a whole lot more safe than that. Scott From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:09:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEF2216A420 for ; Wed, 1 Feb 2006 22:09:49 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAF2A43D55 for ; Wed, 1 Feb 2006 22:09:43 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 8B26B5E48EE; Wed, 1 Feb 2006 14:09:43 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id C41515E48BB for ; Wed, 1 Feb 2006 14:09:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <7A70B364-75C8-4522-9CFC-1448DBFD853E@freebsd.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Jason Evans Date: Wed, 1 Feb 2006 14:09:35 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Subject: subdisk6: detached --> Fatal trap 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 22:09:50 -0000 I've been trying to get FreeBSD running on a new machine with the following hardware: Tyan S2895 motherboard, BIOS v1.02 2x Opteron 275 8 GB ECC RAM 400 GB SATA HDD IDE DVD/CD drive Initially, installation went fine using snapshot 012 from ftp.freebsd.org. However, once the system is up and running, within minutes of loading the filesystem with a cvsup or cvs checkout, I get errors something like: subdisk6: detached g_vfs_done():ad6s1f[WRITE(offset=10217842688, length=2048)]error = 6 ad6: detached Fatal trap 9 [...] g_vfs_done():[12-15 more messages like the one above.] Sometimes I get a bit of information about the CPU state, but it's usually corrupted. The machine has failed to drop to ddb most of the time, and haven't been lucky enough to get a prompt the last several hangs. Now, the real fun is that after this happens a few times, the machine will no longer finish booting, either from the HDD or from the install CD. Booting hangs after probing acd0. I'm going to have to install Linux to blow away the MBR again, and try this a third time. If I understand the error messages above correctly, the device driver for the SATA drive is detaching the device for some reason, and the g_vfs_done() message is simply due to the drive having been yanked. I have never seen any messages that indicate why the HDD is being detached. I did not have these problems when I installed from snapshot 011 (November 2005), but when I built/installed head as of ~3 days ago, the above problems surfaced, and after a few crashes I had to reinstall from scratch (after overwriting the MBR with GRUB). Has anyone seen similar behavior? Does anyone know how to fix this? Barring answers to the above, can anyone provide pointers in tracking this down? Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:14:13 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E6BB16A420 for ; Wed, 1 Feb 2006 22:14:13 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A04543D45 for ; Wed, 1 Feb 2006 22:14:13 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 574C546C2C; Wed, 1 Feb 2006 17:13:59 -0500 (EST) Date: Wed, 1 Feb 2006 22:15:50 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20060201221213.L87763@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-audit@TrustedBSD.org Subject: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 22:14:13 -0000 As Wayne and I are in the process of merging the TrustedBSD audit3 branch contents into the FreeBSD CVS HEAD (7-CURRENT), there may be periods where the tree is (hopefully briefly) unbuildable. This integration process will take a couple of days to complete, due to the scope of the changes. So far, the kernel audit framework has been committed (src/sys/security/audit), as has an initial vendor import of OpenBSM for user space (src/contrib/openbsm). What remains to be committed are the substantial changes to gather audit data in system calls, the mappings of system calls to audit events, and integration into the user space build and user space applications (such as login). These bits are the trickier bits as the patches are large and touch a lot of parts of the tree. I'll send out follow-up e-mail once the worst is past, along with information on what it all means, and how to try it out (for those not already on trustedbsd-audit, who have been hearing about this for a while). Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:15:37 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F32616A420 for ; Wed, 1 Feb 2006 22:15:37 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (ruprt.hosting4u.cz [82.208.25.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36C5743D45 for ; Wed, 1 Feb 2006 22:15:35 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id BCEFB4E707; Wed, 1 Feb 2006 23:15:35 +0100 (CET) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05506-06; Wed, 1 Feb 2006 23:15:35 +0100 (CET) Received: from gandalf (105.121.95.80.hell.iczf.net [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 8862B4E705; Wed, 1 Feb 2006 23:15:35 +0100 (CET) From: =?us-ascii?Q?Daniel_Dvorak?= To: "'Ryan R'" Date: Wed, 1 Feb 2006 23:15:33 +0100 Message-ID: <004601c6277d$050f1e70$6508280a@tocnet28.jspoj.czf> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1b62a7390602011159l6c43827ei31e25e2d315185a3@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcYna/FNJAROoGEeTvmDxjidXDXO4AACmNsg X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Cc: freebsd-current@freebsd.org Subject: RE: For the love of God, is it even possible to make the Atheros ath.patch & updated HALactually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 22:15:37 -0000 > -----Original Message----- > From: owner-freebsd-current@freebsd.org > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Ryan R > Sent: Wednesday, February 01, 2006 9:00 PM > To: freebsd-current@freebsd.org > Subject: For the love of God,is it even possible to make the > Atheros ath.patch & updated HALactually work? > > *Sigh* > > Hi again everyone.. > > I'm a novice BSD user who recently purchased an Atheros > wireless card. The card is an "Engenius EMP 8602", 6th > Generation Atheros AR5006 a/b/g chipset. > ( http://www.netgate.com/product_info.php?products_id=279 for > product specs). > > I have been racking my brain for DAYS trying to get Sam > Leffler's ( http://people.freebsd.org/~sam ) ath.patch and > updated HAL binary to work in > *ANY* version of FreeBSD. First, I was told to do a MINIMAL > install, then cvsup to RELENG_6 and attempt to apply the > ath.patch. The patch fails at least 7 hunks in various > places in various files, 90% of the failed hunks are in > if_ath.c. I was then told to > > # cd /usr/src/sys/contrib/dev > # mv ath ath.original > # tar -xzvf ath_hal_20051212.tgz > # mv ath_hal_20051212 ath > > to update the /usr/src/sys/contrib/dev directory. Well lo > and behold, the bloody thing wont compile.. It spits out all > kinds of errors from if_ath.c about 'undeclared functions' > and 'needing more parameters to function' > > So I scrapped that installation and figured I'd give > 7.0-CURRENT a try, in hopes that maybe the patch was FINALLY > applied to the kernel for me, but nope.. It seems only tiny > bits and pieces from the ath.patch have made it into the > actual kernel source. The stock kernel source does not have > enough of the patch in it to make my wireless card work, and > trying to apply the patch to the 7.0 kernel is a complete > failure as well. > > So my question is; if the patch doesn't apply cleanly to > either RELENG_6 nor HEAD, then what the heck WILL it apply > cleanly to? This FreeBSD installation is sitting here doing > absolutely nothing because it's a complete waste on my Laptop > since there is NO wireless support for it at all. Yet it > works just fine in Linux.. Really ? :-) Do you think about madwifi-ng ? I hope not. Ng deos not work just fine at all !!! :-) WME (WMM), unexpected deassociation, TPC, DFS (radar sim), option to enable/disable DFS does not exist and so on things always panic the Debian GNU/Linux very well, even at boot time! The opposite that the implementation ath and ath hal 0.9.14.9 is more or less stable even with wme and tpc enabled in FreeBSD for the long time. And madwifi-old does not support these new ath chipsets, because of new version HAL 0.9.16.3. Madwifi-old = freebsd ath implementation plus wds, sample rate 1.2 and some more non-essential features. To June/July 2005 madwifi was very unstable, after merging cvs BSD tree of madwifi to cvs head tree of madwifi = now madwifi-old is more or less stable, but without wme or TPC. And that bsd tree was based on Sam L. good or perfect work for FreeBSD, until merging code from FreeBSD from Sam L. work, madwifi was unstable hazard code ! > Does anybody have even the slightest clue when this code may > actually make it into the kernel sources? Yes, this question is a bit interesting. I do not understand why this new version of hal could not be committed to head, if the current is the "bleeding edge" of FreeBSD DEVELOPMENT and "This code has been in test for a while and should be fine to use but I will not commit it until I get feedback." said Sam L. on the 13th of December 2005. But why ? If we have the CURRENT BRANCH for exact purpouses, at least I think it after reading the Handbook. I think if Sam needs some board feedback, so current source tree is the perfect place, where is useful and where it could get the well feedback. So actualy I do not know the answer to your question and I am glad to see your question here. > Or better yet, > does the patch cleanly apply and compile for ANYBODY? I > posted this on bsdforums.org and people there can't get it to > compile either.. I know about at least one man Jiri M., he is active in this mailling list too. And he succeed with compiling new hal in current and maybe in releng_6. The details he could tell you. > I e-mailed the author of the patch but I > guess he's way too busy and didn't get a chance to respond to me > > I'm at my wits end here so any help would be appreciated, I > really don't want to have to just depend on Linux or Windows > XP for this system when I've fallen in love with everything > OTHER than this major problem in FreeBSD :( > > Thanks guys; anxiously awaiting any help -Ryan > _______________________________________________ > 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" _____ avast! Antivirus : Odchozi zprava cista. Virova databaze (VPS): 0605-4, 01.02.2006 Testovano: 1.2.2006 23:15:32 avast! - copyright (c) 1988-2005 ALWIL Software. From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:16:17 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DE8216A420; Wed, 1 Feb 2006 22:16:17 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3071E43D48; Wed, 1 Feb 2006 22:16:17 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 01 Feb 2006 14:16:17 -0800 Message-ID: <43E13330.709@elischer.org> Date: Wed, 01 Feb 2006 14:16:16 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <3281.1138742578@critter.freebsd.dk> <43E127A5.9060503@freesbie.org> <43E13058.7020708@elischer.org> In-Reply-To: <43E13058.7020708@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: small@freebsd.org, rizzo@icir.org, Poul-Henning Kamp , rwatson@freebsd.org, Dario Freni , "M. Warner Losh" , current@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 22:16:17 -0000 Julian Elischer wrote: > Dario Freni wrote: > >> >> >> Nobody of you mind importing the toolkit in the source tree? :) >> >> > > on the contrary i thin it should be there.. *somewhere*. > the question is, "where?" BTW freesbie web page looks a bit sad with teh last post being in Dec 2004 Some_Freesbie_person (TM) should put something new there.. > > > I thought that's why you have access? > > _______________________________________________ > 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 Feb 1 22:22:45 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 588C916A420; Wed, 1 Feb 2006 22:22:45 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F22E43D45; Wed, 1 Feb 2006 22:22:41 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 83A07998465; Wed, 1 Feb 2006 23:22:39 +0100 (CET) Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 80279-07-2; Wed, 1 Feb 2006 23:22:36 +0100 (CET) Received: from [80.98.231.227] (catv-5062e7e3.catv.broadband.hu [80.98.231.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.t-hosting.hu (Postfix) with ESMTP id 209F6998474; Wed, 1 Feb 2006 23:22:36 +0100 (CET) Message-ID: <43E134AB.8000600@t-hosting.hu> Date: Wed, 01 Feb 2006 23:22:35 +0100 From: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20060201221213.L87763@fledge.watson.org> In-Reply-To: <20060201221213.L87763@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at t-hosting.hu X-Mailman-Approved-At: Wed, 01 Feb 2006 22:27:26 +0000 Cc: trustedbsd-audit@TrustedBSD.org, current@FreeBSD.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 22:22:45 -0000 Robert Watson wrote: > > As Wayne and I are in the process of merging the TrustedBSD audit3 > branch contents into the FreeBSD CVS HEAD (7-CURRENT), there may be > periods where the tree is (hopefully briefly) unbuildable. This > integration process will take a couple of days to complete, due to the > scope of the changes. So far, the kernel audit framework has been > committed (src/sys/security/audit), as has an initial vendor import of > OpenBSM for user space (src/contrib/openbsm). What remains to be > committed are the substantial changes to gather audit data in system > calls, the mappings of system calls to audit events, and integration > into the user space build and user space applications (such as > login). These bits are the trickier bits as the patches are large and > touch a lot of parts of the tree. > > I'll send out follow-up e-mail once the worst is past, along with > information on what it all means, and how to try it out (for those not > already on trustedbsd-audit, who have been hearing about this for a > while). > > Robert N M Watson > Do you plan to merge it to RELENG_6? If so, when? Maybe for the upcoming 6.1? Or only for 6.2 or later? Regards, Gabor Kovesdan From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:30:59 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5259416A420 for ; Wed, 1 Feb 2006 22:30:59 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7A1643D45 for ; Wed, 1 Feb 2006 22:30:58 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1B77F46B16; Wed, 1 Feb 2006 17:30:50 -0500 (EST) Date: Wed, 1 Feb 2006 22:32:41 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= In-Reply-To: <43E134AB.8000600@t-hosting.hu> Message-ID: <20060201222704.G87763@fledge.watson.org> References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1804086051-1138833161=:87763" Cc: trustedbsd-audit@TrustedBSD.org, current@FreeBSD.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 22:30:59 -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-1804086051-1138833161=:87763 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 1 Feb 2006, K=F6vesd=E1n G=E1bor wrote: > Robert Watson wrote: > >> As Wayne and I are in the process of merging the TrustedBSD audit3 branc= h=20 >> contents into the FreeBSD CVS HEAD (7-CURRENT), there may be periods whe= re=20 >> the tree is (hopefully briefly) unbuildable. This integration process w= ill=20 >> take a couple of days to complete, due to the scope of the changes. So= =20 >> far, the kernel audit framework has been committed=20 >> (src/sys/security/audit), as has an initial vendor import of OpenBSM for= =20 >> user space (src/contrib/openbsm). What remains to be committed are the= =20 >> substantial changes to gather audit data in system calls, the mappings o= f=20 >> system calls to audit events, and integration into the user space build = and=20 >> user space applications (such as login). These bits are the trickier bi= ts=20 >> as the patches are large and touch a lot of parts of the tree. >>=20 >> I'll send out follow-up e-mail once the worst is past, along with=20 >> information on what it all means, and how to try it out (for those not= =20 >> already on trustedbsd-audit, who have been hearing about this for a whil= e). >>=20 > Do you plan to merge it to RELENG_6? If so, when? Maybe for the upcoming= =20 > 6.1? Or only for 6.2 or later? It depends a bit how well this shakes out. The code is definitely still=20 "experimental", in that the set of events audited is not yet complete. The= re=20 are three general sorts of weaknesses in the set of events currently audite= d: (1) Our auditing of system calls in compatibility APIs, such as Linux, is n= ot yet complete. A lot of this simply consists of completing the mapping= of non-FreeBSD system calls to BSM audit event identifiers. In other cas= es, we need to add new events or additional argument gathering. For examp= le, the Linux compatibility support includes some Linux-specific system ca= lls that do not appear in Darwin, FreeBSD, or Solaris, and will require specific new event types to be assigned and arguments to be gathered. (2) Argument gathering for FreeBSD system calls is not complete. A moderat= e number of new system calls have been added since we began work on the audit code, including support for POSIX message queues and a new mount mechanism. In addition, some current system calls are not fully audite= d -- for example, ACL-related operations. (3) Not all user space commands requiring audit support have been modified = to perform CAPP-required auditing. For example, sshd doesn't currently h= ave its audit support hooked up (although the support in it for Solaris an= d Darwin BSM should work on FreeBSD). Things like lpr, adduser, and so = on require additional audit support. Finally, lots of testing is required. With all this in mind, it is not yet ruled out that we could ship initial= =20 "experimental" audit support in 6.1-RELEASE. In fact, the timing is curren= tly=20 such that it will be possible, assuming all goes well, and allowing for the= =20 fact that it really will be an experimental feature and not production feat= ure=20 in 6.1. We were quite careful to merge the necessary ABI changes to RELENG= _6=20 before the 6.0 release so that merging it would be possible without breakin= g=20 existing 6.x device drivers. Help in continuing development and testing would be most welcome! We'll se= nd=20 out e-mail with details regarding configuring the audit support (etc) once = the=20 merge is a bit further along. Thanks, Robert N M Watson --0-1804086051-1138833161=:87763-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:32:27 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B9CE16A420; Wed, 1 Feb 2006 22:32:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 064C743D45; Wed, 1 Feb 2006 22:32:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 01 Feb 2006 14:32:26 -0800 Message-ID: <43E136F9.6080306@elischer.org> Date: Wed, 01 Feb 2006 14:32:25 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> In-Reply-To: <43E134AB.8000600@t-hosting.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: trustedbsd-audit@TrustedBSD.org, Robert Watson , current@freebsd.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 22:32:27 -0000 Kövesdán Gábor wrote: > Robert Watson wrote: > >> >> As Wayne and I are in the process of merging the TrustedBSD audit3 >> branch contents into the FreeBSD CVS HEAD (7-CURRENT), there may be >> periods where the tree is (hopefully briefly) unbuildable. This >> integration process will take a couple of days to complete, due to >> the scope of the changes. So far, the kernel audit framework has >> been committed (src/sys/security/audit), as has an initial vendor >> import of OpenBSM for user space (src/contrib/openbsm). What remains >> to be committed are the substantial changes to gather audit data in >> system calls, the mappings of system calls to audit events, and >> integration into the user space build and user space applications >> (such as login). These bits are the trickier bits as the patches are >> large and touch a lot of parts of the tree. >> >> I'll send out follow-up e-mail once the worst is past, along with >> information on what it all means, and how to try it out (for those >> not already on trustedbsd-audit, who have been hearing about this for >> a while). >> >> Robert N M Watson >> > Do you plan to merge it to RELENG_6? If so, when? Maybe for the > upcoming 6.1? Or only for 6.2 or later? is there a website about all this stuff? "What's it for?" > > Regards, > > Gabor Kovesdan > _______________________________________________ > 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 Feb 1 22:43:26 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D48916A420; Wed, 1 Feb 2006 22:43:26 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D0E843D46; Wed, 1 Feb 2006 22:43:26 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4QhB-0001K9-P6; Wed, 01 Feb 2006 22:43:26 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4QhB-0001pG-01; Wed, 01 Feb 2006 14:43:25 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17377.14732.391882.775974@roam.psg.com> Date: Wed, 1 Feb 2006 14:43:24 -0800 To: Jason Evans References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> Cc: current@freebsd.org, Kris Kennaway Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 22:43:26 -0000 > I've been running Xorg, firefox, and emacs, since last night (with > jemalloc's redzone code enabled) on a two-day-old -current build, and > after many invocations of firefox and emacs, with serious attempts to > make firefox use lots of memory, Xorg's, memory usage has stabilized > at ~75 MB mapped, and ~35 MB resident. what seems to be common with those of us seeing leakage is multiple windows and many tabs. i standardly have three windows each with six to ten tabs. randy From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:48:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD5ED16A420; Wed, 1 Feb 2006 22:48:08 +0000 (GMT) (envelope-from gpalmer@freebsd.org) Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6258B43D45; Wed, 1 Feb 2006 22:48:08 +0000 (GMT) (envelope-from gpalmer@freebsd.org) Received: from uucp by noop.colo.erols.net with local-rmail (Exim 4.52 (FreeBSD)) id 1F4Qlj-0008Yh-Rw; Wed, 01 Feb 2006 17:48:07 -0500 Received: from localhost.home.in-addr.com ([127.0.0.1]:57811) by rimmer.home.in-addr.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Qgm-0005ye-V8; Wed, 01 Feb 2006 22:43:01 +0000 Message-ID: <43E13974.8010801@freebsd.org> Date: Wed, 01 Feb 2006 22:43:00 +0000 From: Gary Palmer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051130 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: FreeBSD Current References: <17373.50882.270841.554876@roam.psg.com> <43DECB94.50307@lclark.edu> <17375.1454.11511.502872@roam.psg.com> <20060131102914.660ukp2ko4wgogoc@netchild.homeip.net> <20060201164124.GA28139@panix.com> <17377.2983.58360.592928@roam.psg.com> <20060201200221.GA31743@xor.obsecurity.org> In-Reply-To: <20060201200221.GA31743@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 22:48:08 -0000 Kris Kennaway wrote: >On Wed, Feb 01, 2006 at 11:27:35AM -0800, Randy Bush wrote: > > >>>I'm running firefox 1.5 on a fairly recent 6-STABLE, and see massive >>>memory leaks. They seem to be related to javascript. >>> >>> >>if i turn javascript off, the leak continues >> >>5000000 2053 45 1 16578 451 657355K 60K 657416K ? washingtonpo >>5000000 2053 45 1 16801 450 667667K 60K 667727K ? washingtonpo >>5000000 483 44 1 16800 143 667685K 16K 667702K ? washingtonpo >>5000000 483 44 1 16852 144 673796K 16K 673813K ? washingtonpo >>5000000 483 44 1 17023 145 677964K 16K 677981K ? washingtonpo >> >>given the inability of Jason Evans to replicate. >>we need to think a bit about a forward debugging path. >> >> > >It will presumably involve the firefox developers. > > Firefox 1.5.0.1 was recently released which contains fixes for "several memory leaks". From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:53:56 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EABF516A420 for ; Wed, 1 Feb 2006 22:53:55 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4789A43D53 for ; Wed, 1 Feb 2006 22:53:55 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id ABE9246B17; Wed, 1 Feb 2006 17:53:43 -0500 (EST) Date: Wed, 1 Feb 2006 22:55:40 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <43E136F9.6080306@elischer.org> Message-ID: <20060201224413.W90364@fledge.watson.org> References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <43E136F9.6080306@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-audit@TrustedBSD.org, =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= , current@freebsd.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 22:53:56 -0000 On Wed, 1 Feb 2006, Julian Elischer wrote: >>> I'll send out follow-up e-mail once the worst is past, along with >>> information on what it all means, and how to try it out (for those not >>> already on trustedbsd-audit, who have been hearing about this for a >>> while). >>> >> Do you plan to merge it to RELENG_6? If so, when? Maybe for the upcoming >> 6.1? Or only for 6.2 or later? > > is there a website about all this stuff? "What's it for?" I'm sure I promised to answer exactly that question in my followup e-mail once the integration is done. :-) The quick answer is that this is an implementation of security event auditing, as required by the Orange Book C2 and later Common Criteria CAPP security evaluation/standard. These documents provide specifications for a set of functional requirements (and assurance requirements) regarding the behavior of operating systems with respect to security. One of the requirements is the fine-grained and configurable logging of security-relevant events. Security-relevant turns out to be pretty all-inclusive, as CAPP requires the ability to log the results of access control decisions associated with discretionary access control, which means basically all file I/O, including path lookups. So what is present in our implementation is: - The introduction of a centralized kernel audit event engine, src/sys/security/audit, which includes various system calls, an event queue, kernel worker thread to process the queue, interfaces to capture system call information, a system call for user applications to submit audit records, pre-selection mechanism, etc. - OpenBSM, an implementation of the Solaris/OpenSolaris Basic Security Module API and file format for audit trails. This is derived from the BSM audit support found in the Apple Mac OS X and Darwin operating systems, although substantially reworked, cleaned up, and synchronized to recent BSM changes in Solaris, such as 64-bit records. - auditd, a daemon for managing audit event logs and the audit subsystem. - Modifications throughout the kernel and in many places in user space to generate audit records. Unlike existing logging and tracing mechanisms, audit has to meet a number of reliability, security, and functional requirements that basically drove the implementation of a new logging system rather than adaptation of an existing one: - Only authorized processes can read and write to the audit log. - Detailed subject and object information, including file paths, full credential information for processes, etc. - Configurable log granularity by user, subsystem, operation, including the ability to control the logging of non-attributable events. - Audit log reduction tools and pre-selection mechanism. - Reliability requirements relating to maximum record loss in the event of power loss, configurable ability to fail-stop the system when the audit store is filled. - Portable log format based on the de facto industry standard BSM format (used by Solaris, Mac OS X, and a moderate number of intrusion detection tools, post-mortem tools, etc). The implementation is not yet fully complete, but it's now at the point where more broad exposure and testing would be very helpful. The hope is to have much of the current implementation merged in the next couple of days, and the remainder over the next couple of weeks. Since I did the intro for this, I should take this opportunity to thank Apple Computer for sponsoring the original development work as part of their Common Criteria CAPP evaluation for Mac OS X, and then releasing the results under a BSD license (announcement on this to follow), SPARTA for releasing extensions and additional work on the system, not to mention the team of people who have been involved in porting over, adapting, and substantially enhancing the Darwin audit support, including Wayne Salamon (part of the original audit development team), who has done extensive development work on it, and Tom Rhodes, who has written a lot of the new documentation including a new handbook chapter on configuring audit support. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 22:54:28 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6759616A420 for ; Wed, 1 Feb 2006 22:54:28 +0000 (GMT) (envelope-from mattjreimer@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id C535743D4C for ; Wed, 1 Feb 2006 22:54:27 +0000 (GMT) (envelope-from mattjreimer@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so256831nzo for ; Wed, 01 Feb 2006 14:54:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dtoStNWXgeLLEbyn4twaPH7wqU7ZXNc8vmKCO8Gn14SIW4YTnPE8lDrb/l+z+SDyNENZ9FF9X47Ix/TvpXUq3yzFKx2BjyWfny7KJ7AtbWX6jGNVoYfcz6UYS+wJeO8HU9LkZJNPdIh3tiFJB9GfF5FDSqlgtX8O6zwdkPOEAX8= Received: by 10.64.243.3 with SMTP id q3mr36994qbh; Wed, 01 Feb 2006 14:54:26 -0800 (PST) Received: by 10.64.213.13 with HTTP; Wed, 1 Feb 2006 14:54:26 -0800 (PST) Message-ID: Date: Wed, 1 Feb 2006 14:54:26 -0800 From: Matt Reimer To: Randy Bush In-Reply-To: <17377.14732.391882.775974@roam.psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17373.50882.270841.554876@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> <17377.14732.391882.775974@roam.psg.com> Cc: Kris Kennaway , Jason Evans , current@freebsd.org Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 22:54:28 -0000 On 2/1/06, Randy Bush wrote: > > I've been running Xorg, firefox, and emacs, since last night (with > > jemalloc's redzone code enabled) on a two-day-old -current build, and > > after many invocations of firefox and emacs, with serious attempts to > > make firefox use lots of memory, Xorg's, memory usage has stabilized > > at ~75 MB mapped, and ~35 MB resident. > > what seems to be common with those of us seeing leakage is multiple > windows and many tabs. i standardly have three windows each with > six to ten tabs. Maybe what's eating up the memory is Firefox 1.5's new feature to cache extra data in RAM in order to make Back/Forward fast. Matt From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 23:04:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD80416A420 for ; Wed, 1 Feb 2006 23:04:55 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (mailtest.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EDA543D58 for ; Wed, 1 Feb 2006 23:04:41 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 9DE878A0028 for ; Wed, 1 Feb 2006 15:06:22 -0800 (PST) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36427-01-32 for ; Wed, 1 Feb 2006 15:06:16 -0800 (PST) Received: from s157.sbo (s157.sbo [192.168.0.157]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 53A868A0021 for ; Wed, 1 Feb 2006 15:06:16 -0800 (PST) From: Freddie Cash To: freebsd-current@freebsd.org Date: Wed, 1 Feb 2006 15:04:34 -0800 User-Agent: KMail/1.9.1 References: <17373.50882.270841.554876@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> <17377.14732.391882.775974@roam.psg.com> In-Reply-To: <17377.14732.391882.775974@roam.psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602011504.34905.fcash@ocis.net> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 23:04:55 -0000 On Wednesday 01 February 2006 02:43 pm, Randy Bush wrote: > > I've been running Xorg, firefox, and emacs, since last night (with > > jemalloc's redzone code enabled) on a two-day-old -current build, and > > after many invocations of firefox and emacs, with serious attempts to > > make firefox use lots of memory, Xorg's, memory usage has stabilized > > at ~75 MB mapped, and ~35 MB resident. > what seems to be common with those of us seeing leakage is multiple > windows and many tabs. i standardly have three windows each with > six to ten tabs. Is this the issue you are running into: http://primates.ximian.com/~federico/news-2005-11.html#moz-images -- Freddie Cash fcash@ocis.net From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 23:04:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6154716A420 for ; Wed, 1 Feb 2006 23:04:59 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFCDB43D8B for ; Wed, 1 Feb 2006 23:04:48 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.199] ([10.0.0.199]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id k11N4ko7016262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2006 15:04:47 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <43E13E8C.4070800@errno.com> Date: Wed, 01 Feb 2006 15:04:44 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: dandee@volny.cz References: <004601c6277d$050f1e70$6508280a@tocnet28.jspoj.czf> In-Reply-To: <004601c6277d$050f1e70$6508280a@tocnet28.jspoj.czf> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Ryan R' , freebsd-current@freebsd.org Subject: Re: For the love of God, is it even possible to make the Atheros ath.patch & updated HALactually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 23:04:59 -0000 Daniel Dvorak wrote: <...stuff removed...> >> Does anybody have even the slightest clue when this code may >> actually make it into the kernel sources? > > Yes, this question is a bit interesting. I do not understand why this new > version of hal could not be committed to head, if the current is the > "bleeding edge" of FreeBSD DEVELOPMENT and "This code has been in test for a > while and should be fine to use but I will not commit it until I get > feedback." said Sam L. on the 13th of December 2005. > > But why ? If we have the CURRENT BRANCH for exact purpouses, at least I > think it after reading the Handbook. > > I think if Sam needs some board feedback, so current source tree is the > perfect place, where is useful and where it could get the well feedback. > > So actualy I do not know the answer to your question and I am glad to see > your question here. The hal+patch has a showstopper bug that I've been unable to resolve. Until that problem is resolved I won't commit the hal. In the mean time I am considering splitting out some of the driver changes and committing those. All the net80211 changes I was holding at the time I made the above comment have been committed to HEAD+RELENG_6. > >> Or better yet, >> does the patch cleanly apply and compile for ANYBODY? I >> posted this on bsdforums.org and people there can't get it to >> compile either.. > > I know about at least one man Jiri M., he is active in this mailling list > too. And he succeed with compiling new hal in current and maybe in releng_6. > The details he could tell you. I posted recently that I would re-spin the ath patch and post mail when it was available. I have yet to do that as I was hoping to resolve the bug and just commit everything to cvs. Sorry folks are having problems. My goal is to get this stuff into 6.1 but it's looking tight. I'm well aware that all/most new cards are using the latest chips that are not supported by the 0.9.14.9 hal. Sam From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 23:05:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1989516A420 for ; Wed, 1 Feb 2006 23:05:33 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FA1E43D68 for ; Wed, 1 Feb 2006 23:05:25 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4R2S-0001qU-4o; Wed, 01 Feb 2006 23:05:24 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4R2R-0001rc-Am; Wed, 01 Feb 2006 15:05:23 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17377.16050.816820.12311@roam.psg.com> Date: Wed, 1 Feb 2006 15:05:22 -0800 To: Matt Reimer References: <17373.50882.270841.554876@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> <17377.14732.391882.775974@roam.psg.com> Cc: current@freebsd.org Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 23:05:33 -0000 > Maybe what's eating up the memory is Firefox 1.5's new feature to > cache extra data in RAM in order to make Back/Forward fast. couldn't say. but it keeps leaking if i just leave it alone for hours. randy From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 23:23:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6B3616A420; Wed, 1 Feb 2006 23:23:44 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10BA643D6E; Wed, 1 Feb 2006 23:23:37 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k11NNU7a097186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2006 09:53:36 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Randy Bush Date: Thu, 2 Feb 2006 09:52:22 +1030 User-Agent: KMail/1.9.1 References: <200601301652.16237.doconnor@gsoft.com.au> <200602011424.57722.doconnor@gsoft.com.au> <17376.65268.396436.72837@roam.psg.com> In-Reply-To: <17376.65268.396436.72837@roam.psg.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12379833.XJuOrvBiWy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200602020952.39010.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: Kris Kennaway , freebsd-current@freebsd.org, Jason Evans , Michael Nottebrock Subject: Re: KDE 3.5.0 seems much chubbier than 3.4.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 23:23:44 -0000 --nextPart12379833.XJuOrvBiWy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 02 February 2006 05:03, Randy Bush wrote: > >> Hmm, not sure it was unbounded, but it was certainly consuming a lot of > >> extra memory. Note that with the debugging off top shows it as.. > >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMA= ND > >> 19876 root 1 100 0 315M 136M select 18:16 13.67% Xorg > > > > Things still seem to be using more memory than I would expect.. Certain= ly > > my laptop is swapping more than I expect :( > > > > Is there a simple way to revert to the old malloc? Just back out > > malloc.c? I'd go back to KDE 3.4.2 but that is a lot more complex :) > > been there. it was the recent firefox. Except I'm not running firefox. Also, xrestop shows X using 120Mb of pixmaps. X's size is 315M, and I have a 64Mb video card. 64 + 120 =3D 184 315 - 184 =3D 131 ie 131Mb of space that X is using but no obvious reason.. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart12379833.XJuOrvBiWy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD4UK+5ZPcIHs/zowRAtI1AJ4uKYYnB6+7vZ8FjEVvbiRCuXC/UQCeKhoW d1lcgtr5n4/SevQUXMGH9ns= =1lPM -----END PGP SIGNATURE----- --nextPart12379833.XJuOrvBiWy-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 1 23:34:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 848DD16A420 for ; Wed, 1 Feb 2006 23:34:46 +0000 (GMT) (envelope-from josh.carroll@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96C5943D83 for ; Wed, 1 Feb 2006 23:34:04 +0000 (GMT) (envelope-from josh.carroll@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so184104wxc for ; Wed, 01 Feb 2006 15:34:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GrMF/KFiBiJmVui5Cd9pKUzAgfwbomK5G6qMFBdCD1HFQi479w+QObF04hpJqaDruetOX5O3NTLaKe1HhbmoZg5Z+Zxrp0E9s+NviPkaHcxGXqdgjRqA1dj1qZLJsnArPKuhZk7En3ypsqbitxaeQT/GbsZoATwsu95PD4p9lyk= Received: by 10.70.92.1 with SMTP id p1mr111976wxb; Wed, 01 Feb 2006 15:34:03 -0800 (PST) Received: by 10.70.27.17 with HTTP; Wed, 1 Feb 2006 15:34:03 -0800 (PST) Message-ID: <8cb6106e0602011534n85f3373p8f31cdf34dfacb2@mail.gmail.com> Date: Wed, 1 Feb 2006 15:34:03 -0800 From: Josh Carroll Sender: josh.carroll@gmail.com To: current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17373.50882.270841.554876@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> <17377.14732.391882.775974@roam.psg.com> Cc: Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Feb 2006 23:34:46 -0000 Assuming it is the pixmaps being cached by firefox causing this growth, can someone with this problem please see this thread: http://forums.mozillazine.org/viewtopic.php?t=3D354828#memcache And set the maximum memory cache to 8000 or 16000, then see if this problem persists? The quick way to do this is: about:config Create a new integer key, named "browser.cache.memory.capacity" and assign a value in KB for the cache size. You can confirm the size set by opening: about:cache You should see: Maximum storage size: 16000 KiB (or whatever you set it to). Watching xrestop, the Pxm mem value for Firefox should not exceed your maximum set. If it remains below your value, but you still see X.org or Firefox consuming/leaking memory, it may be an entirely different problem, but I suspect this will fix the problem. Josh On 2/1/06, Matt Reimer wrote: > On 2/1/06, Randy Bush wrote: > > > I've been running Xorg, firefox, and emacs, since last night (with > > > jemalloc's redzone code enabled) on a two-day-old -current build, and > > > after many invocations of firefox and emacs, with serious attempts to > > > make firefox use lots of memory, Xorg's, memory usage has stabilized > > > at ~75 MB mapped, and ~35 MB resident. > > > > what seems to be common with those of us seeing leakage is multiple > > windows and many tabs. i standardly have three windows each with > > six to ten tabs. > > Maybe what's eating up the memory is Firefox 1.5's new feature to > cache extra data in RAM in order to make Back/Forward fast. > > Matt > _______________________________________________ > 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 Feb 1 23:56:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D21B16A420; Wed, 1 Feb 2006 23:56:00 +0000 (GMT) (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 0935D43D58; Wed, 1 Feb 2006 23:55:57 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k11NtuTL000868; Wed, 1 Feb 2006 15:55:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k11Ntupg000867; Wed, 1 Feb 2006 15:55:56 -0800 (PST) (envelope-from sgk) Date: Wed, 1 Feb 2006 15:55:56 -0800 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Message-ID: <20060201235556.GA708@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: HEADSUP: New pts code triggers panics on amd64 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: Wed, 01 Feb 2006 23:56:00 -0000 After a binary search, I have determined that the new pts code is triggering kernel panics on an AMD64 system. Using this supfile file, I retrieve the src/sys *default host=cvsup10.freebsd.org *default base=/usr *default release=cvs tag=. *default delete use-rel-suffix *default prefix=/usr #*default date=2006.01.26.01.30.00 <-- Good working kernel *default date=2006.01.26.01.31.00 <-- kernel dies within 5 to 10 minutes. src-sys The difference in the src/sys between the above time stamps are Updating collection src-sys/cvs Edit src/sys/conf/files Checkout src/sys/kern/tty_pts.c Edit src/sys/kern/tty_pty.c Edit src/sys/sys/ttycom.h My kernel is UP on a dual processor Tyan K8S Pro motherboard with 12 GB of memory. I have no loaded modules. I have neither MEMGUARD or REDZONES compiled into the kernel. Attempts to use MEMGUARD results in a kernel that does not even make to single user mode. With vm.old_contigmalloc=1 Memory modified after free 0xfffffff024e38f200(504) val = deadc0dd @ 0xfffffff024e38f2d0 panic: Most recently used by DEVFS1 KDB: stack backtrace: panic() at panic+0x1c1 mtrash_ctor() at mtrash_ctor+0x78 uma_zalloc_arg() at uma_zalloc_arg+0x306 malloc() at malloc+0x3a fdinit() at fdinit+0x24 fdcopy() at fdcopy+0x24 fork1() at fork1+0x6df vfork() at vfork+0x1c syscall() at syscall+0x517 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (66, FreeBSD ELF64, vfork) rip = 0x2006a5b4d, rsp=0xfffffffda50, rbp = 0 --- With vm.old_contigmalloc=0 Memory modified after free (sorry forgot to write this down) panic: Most recently used by DEVFS1 KDB: stack backtrace: panic() at panic+0x1c1 mtrash_ctor() at mtrash_ctor+0x78 uma_zalloc_arg() at uma_zalloc_arg+0x306 malloc() at malloc+0x3a devfs_alloc() at devfs_alloc+0x1a make_dev_credv() at make_dev_credv+0x4b make_dev_cred() at make_dev_cred+0x8e ptcopen() at ptcopen+0x111 giant_open() at giant_open+0x5f devfs_open() at devfs_open+0x23b VOP_OPEN_APV() at VOP_OPEN_APV+0x74 vn_open_cred() at vn_open_cred+0x38c kern_open() at kern_open+0xfd open() at open+0x25 syscall() at syscall+0x517 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (5, FreeBSD ELF64, open) rip = 0x200aeebcc, rsp=0xfffffff2e58, rbp = 0xffffffff --- Script started on Wed Feb 1 15:32:43 2006 troutmask:root[201] kgdb /boot/kernel/kernel vmcore.0 [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: Memory modified after free 0xffffff0254d62600(504) val=deadc0dd @ 0xffffff0254d626d0 panic: Most recently used by DEVFS1 KDB: stack backtrace: panic() at panic+0x1c1 mtrash_ctor() at mtrash_ctor+0x78 uma_zalloc_arg() at uma_zalloc_arg+0x306 malloc() at malloc+0xa3 devfs_alloc() at devfs_alloc+0x1a make_dev_credv() at make_dev_credv+0x4b make_dev_cred() at make_dev_cred+0x8e ptcopen() at ptcopen+0x111 giant_open() at giant_open+0x5f devfs_open() at devfs_open+0x23b VOP_OPEN_APV() at VOP_OPEN_APV+0x74 vn_open_cred() at vn_open_cred+0x38c kern_open() at kern_open+0xfd open() at open+0x25 syscall() at syscall+0x517 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (5, FreeBSD ELF64, open), rip = 0x200aeebcc, rsp = 0x7fffffff2e58, rbp = 0xffffffff --- KDB: enter: panic Uptime: 6m10s Dumping 12223 MB (3 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 4031MB (1031920 pages) ... ok chunk 2: 8192MB (2097152 pages) #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xffffffff8027f809 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff8027f2da in panic ( fmt=0xffffffff80476e34 "Most recently used by %s\n") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xffffffff803b9ad8 in mtrash_ctor (mem=0x0, size=0, arg=0x0, flags=0) at /usr/src/sys/vm/uma_dbg.c:137 #4 0xffffffff803b8046 in uma_zalloc_arg (zone=0xffffff02fffeae40, udata=0x0, flags=1282) at /usr/src/sys/vm/uma_core.c:1846 #5 0xffffffff80273d93 in malloc (size=15, mtp=0xffffffff805aac60, flags=1282) at uma.h:275 #6 0xffffffff80228dca in devfs_alloc () at /usr/src/sys/fs/devfs/devfs_devs.c:121 #7 0xffffffff80254d1b in make_dev_credv (devsw=0xffffffff805c0e40, minornr=0, cr=0xffffff0250378380, uid=0, gid=0, mode=438, fmt=0xffffffff80462900 "tty%c%r", ap=0xffffffffbd5e2530) at /usr/src/sys/kern/kern_conf.c:523 #8 0xffffffff80254ebe in make_dev_cred (devsw=0x0, minornr=0, cr=0x0, uid=0, gid=0, mode=0, fmt=0x0) at /usr/src/sys/kern/kern_conf.c:581 #9 0xffffffff802c0ce1 in ptcopen (dev=0x0, flag=0, devtype=0, td=0xffffff0250378380) at /usr/src/sys/kern/tty_pty.c:163 #10 0xffffffff80253caf in giant_open (dev=0xffffff024d8fc400, oflags=32771, devtype=8192, td=0xffffff024fcc5000) at /usr/src/sys/kern/kern_conf.c:242 #11 0xffffffff8022bcdb in devfs_open (ap=0xffffffffbd5e2770) at /usr/src/sys/fs/devfs/devfs_vnops.c:680 #12 0xffffffff8042b3f4 in VOP_OPEN_APV (vop=0x0, a=0xffffffffbd5e2770) at vnode_if.c:365 #13 0xffffffff802f855c in vn_open_cred (ndp=0xffffffffbd5e2990, flagp=0xffffffffbd5e28dc, cmode=8, cred=0xffffff0250378380, fdidx=6) at vnode_if.h:198 #14 0xffffffff802ee83d in kern_open (td=0xffffff024fcc5000, path=0x519fab
, pathseg=UIO_USERSPACE, flags=32771, mode=-1117902448) at /usr/src/sys/kern/vfs_syscalls.c:977 #15 0xffffffff802eef35 in open (td=0x0, uap=0xffffffffbd5e2c00) at /usr/src/sys/kern/vfs_syscalls.c:943 #16 0xffffffff803ea0e7 in syscall (frame= {tf_rdi = 5349291, tf_rsi = 32770, tf_rdx = 10, tf_rcx = 8601451180, tf_r8 = -2142762872, tf_r9 = 140737488301656, tf_rax = 5, tf_rbx = 0, tf_rbp = 4294967295, tf_r10 = 1, tf_r11 = 514, tf_r12 = 6, tf_r13 = 5349291, tf_r14 = 5349280, tf_r15 = 1, tf_trapno = 22, tf_addr = 0, tf_flags = 0, tf_err = 2, tf_rip = 8601398220, tf_cs = 43, tf_rflags = 582, tf_rsp = 140737488301656, tf_ss = 35}) at /usr/src/sys/amd64/amd64/trap.c:821 #17 0xffffffff803d8048 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:270 #18 0x0000000200aeebcc in ?? () -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 00:02:34 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E4AB16A427 for ; Thu, 2 Feb 2006 00:02:34 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.FreeBSD.org (Postfix) with SMTP id 01BB143D46 for ; Thu, 2 Feb 2006 00:02:32 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 9168 invoked from network); 2 Feb 2006 00:02:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=rRjeG2xILBnd5Ri1Lwn4b4PDsVrNSE26LoGPBOexR/2ZN/6nIv2LR7xFHF7t3lKJwo8xP36WeN65NnD5l2jxP9D93m2Iy1jO5ZExHKDIqQv1VC98zP3+DTGVV3Ickg9XX96Kc7p+s/112TfgcJbRw3wcp4LQwh0nIulH6YlL38Q= ; Received: from unknown (HELO ?70.30.133.184?) (mikej@rogers.com@70.30.133.184 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 2 Feb 2006 00:02:32 -0000 Message-ID: <43E14C53.3060400@rogers.com> Date: Wed, 01 Feb 2006 19:03:31 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Robert Watson References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> In-Reply-To: <20060201222704.G87763@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: trustedbsd-audit@TrustedBSD.org, =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= , current@FreeBSD.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 00:02:34 -0000 Robert Watson wrote: > > On Wed, 1 Feb 2006, Kövesdán Gábor wrote: > >> Do you plan to merge it to RELENG_6? If so, when? Maybe for the >> upcoming 6.1? Or only for 6.2 or later? > > It depends a bit how well this shakes out. The code is definitely > still "experimental", in that the set of events audited is not yet > complete. There are three general sorts of weaknesses in the set of > events currently audited: > With all this in mind, it is not yet ruled out that we could ship > initial "experimental" audit support in 6.1-RELEASE. In fact, the > timing is currently such that it will be possible, assuming all goes > well, and allowing for the fact that it really will be an experimental > feature and not production feature in 6.1. We were quite careful to > merge the necessary ABI changes to RELENG_6 before the 6.0 release so > that merging it would be possible without breaking existing 6.x device > drivers. Personally, i would like to see less "experimental" code in 6.1. Perhaps it would be better to wait until everyone feels the code is ready? From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 00:34:20 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4480F16A420 for ; Thu, 2 Feb 2006 00:34:20 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2411843D68 for ; Thu, 2 Feb 2006 00:34:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8BEF846B0E; Wed, 1 Feb 2006 19:34:08 -0500 (EST) Date: Thu, 2 Feb 2006 00:36:15 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Jakubik In-Reply-To: <43E14C53.3060400@rogers.com> Message-ID: <20060202003229.N87763@fledge.watson.org> References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> <43E14C53.3060400@rogers.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1008067053-1138840575=:87763" Cc: trustedbsd-audit@TrustedBSD.org, =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= , current@FreeBSD.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 00:34:20 -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-1008067053-1138840575=:87763 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 1 Feb 2006, Mike Jakubik wrote: > Robert Watson wrote: >>=20 >> On Wed, 1 Feb 2006, K=F6vesd=E1n G=E1bor wrote: >>=20 >>> Do you plan to merge it to RELENG_6? If so, when? Maybe for the upcomin= g=20 >>> 6.1? Or only for 6.2 or later? >>=20 >> It depends a bit how well this shakes out. The code is definitely still= =20 >> "experimental", in that the set of events audited is not yet complete.= =20 >> There are three general sorts of weaknesses in the set of events current= ly=20 >> audited: >> With all this in mind, it is not yet ruled out that we could ship initia= l=20 >> "experimental" audit support in 6.1-RELEASE. In fact, the timing is=20 >> currently such that it will be possible, assuming all goes well, and=20 >> allowing for the fact that it really will be an experimental feature and= =20 >> not production feature in 6.1. We were quite careful to merge the=20 >> necessary ABI changes to RELENG_6 before the 6.0 release so that merging= it=20 >> would be possible without breaking existing 6.x device drivers. > > Personally, i would like to see less "experimental" code in 6.1. Perhaps = it=20 > would be better to wait until everyone feels the code is ready? Audit is a feature optionally compiled into the kernel -- the goal of=20 providing it via RELENG_6, if we decide to go that way, would be to allow= =20 early adopters to compile in the option if they needed to use it. The main= =20 things standing between us and a merge to RELENG_6 is making sure that file= =20 formats are finalized, in order to prevent backward/forward incompatibiliti= es=20 being introduced. Without the code compiled into the kernel, the audit sys= tem=20 is completely disabled, although the command line tools to process audit lo= gs=20 from audit-enabled systems will be present and will operate. I agree that= =20 caution is required -- on the other hand, audit is a feature that can be=20 incrementally improved as time goes by as long as the basic framework (whic= h=20 has not changed significantly in several months) works properly. The main= =20 things remaining to be added are capturing of additional information, which= =20 will not change the basic file format. Even without the additional=20 information captured, audit is still very useful. All that said -- we'll see where things sit in a couple of weeks, and as=20 reports of more widespread use come in. Robert N M Watson --0-1008067053-1138840575=:87763-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 00:37:28 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F0E616A420; Thu, 2 Feb 2006 00:37:28 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62BE943D53; Thu, 2 Feb 2006 00:37:24 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id 90CCA5783; Thu, 2 Feb 2006 01:45:31 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on cvs.freesbie.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.168.99.16] (host14-150.pool875.interbusiness.it [87.5.150.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP; Thu, 2 Feb 2006 01:45:31 +0100 (CET) Message-ID: <43E15438.80700@freesbie.org> Date: Thu, 02 Feb 2006 01:37:12 +0100 From: Dario Freni User-Agent: Mozilla Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Julian Elischer References: <3281.1138742578@critter.freebsd.dk> <43E127A5.9060503@freesbie.org> <43E13058.7020708@elischer.org> <43E13330.709@elischer.org> In-Reply-To: <43E13330.709@elischer.org> X-Enigmail-Version: 0.94.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig04C287225C7733E4C7CD3CF2" X-Virus-Scanned: ClamAV using ClamSMTP Cc: small@freebsd.org, rizzo@icir.org, Poul-Henning Kamp , rwatson@freebsd.org, "M. Warner Losh" , current@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 00:37:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig04C287225C7733E4C7CD3CF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Julian Elischer ha scritto: > Julian Elischer wrote: >=20 >> Dario Freni wrote: >> >>> >>> >>> Nobody of you mind importing the toolkit in the source tree? :) >>> =20 >>> >> >> on the contrary i thin it should be there.. *somewhere*. >> the question is, "where?" >=20 >=20 > BTW freesbie web page looks a bit sad with teh last post being in Dec = 2004 > Some_Freesbie_person (TM) should put something new there.. I'm working on the new site, it will be up in a couple of days. Most of the people helping us with site, translation, mirrors, etc. were quite busy this year or disappeared at all, now I'm waking up all the tasks. The "news" are on the blog, actually. Sorry for that. >> I thought that's why you have access? Access to what? :) I have only a perforce access derived from SoC and I try to keep my project dir in sync with freesbie's cvs. --=20 Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --------------enig04C287225C7733E4C7CD3CF2 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.1 (Darwin) iD8DBQFD4VQ7ymi72IiShysRAh0TAJ9MzB7G0fpfCvfQE/7kGy78homgHwCcDtD3 W807H8BYC5P68u14/OwMa+g= =hOJO -----END PGP SIGNATURE----- --------------enig04C287225C7733E4C7CD3CF2-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 00:40:47 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04E8216A422; Thu, 2 Feb 2006 00:40:47 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C76F43D46; Thu, 2 Feb 2006 00:40:46 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 80BE61A3C1B; Wed, 1 Feb 2006 16:40:46 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 44B5B52EC1; Wed, 1 Feb 2006 19:40:45 -0500 (EST) Date: Wed, 1 Feb 2006 19:40:44 -0500 From: Kris Kennaway To: Mike Jakubik Message-ID: <20060202004044.GA99245@xor.obsecurity.org> References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> <43E14C53.3060400@rogers.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <43E14C53.3060400@rogers.com> User-Agent: Mutt/1.4.2.1i Cc: trustedbsd-audit@TrustedBSD.org, K?vesd?n G?bor , Robert Watson , current@FreeBSD.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 00:40:47 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 01, 2006 at 07:03:31PM -0500, Mike Jakubik wrote: > Robert Watson wrote: > > > >On Wed, 1 Feb 2006, K?vesd?n G?bor wrote: > > > >>Do you plan to merge it to RELENG_6? If so, when? Maybe for the=20 > >>upcoming 6.1? Or only for 6.2 or later? > > > >It depends a bit how well this shakes out. The code is definitely=20 > >still "experimental", in that the set of events audited is not yet=20 > >complete. There are three general sorts of weaknesses in the set of=20 > >events currently audited: > >With all this in mind, it is not yet ruled out that we could ship=20 > >initial "experimental" audit support in 6.1-RELEASE. In fact, the=20 > >timing is currently such that it will be possible, assuming all goes=20 > >well, and allowing for the fact that it really will be an experimental= =20 > >feature and not production feature in 6.1. We were quite careful to=20 > >merge the necessary ABI changes to RELENG_6 before the 6.0 release so=20 > >that merging it would be possible without breaking existing 6.x device= =20 > >drivers. >=20 > Personally, i would like to see less "experimental" code in 6.1. Perhaps= =20 > it would be better to wait until everyone feels the code is ready? Why do you care if code that is not enabled by default is present in the system? :-) Kris --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD4VULWry0BWjoQKURAhmKAJ4lFtHq7Nlc5tS7IVMwPJAgJd6RMwCg2BhW xMxXan43EQKxELJCkNOrZZM= =/6IH -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 00:48:47 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D4EC16A420; Thu, 2 Feb 2006 00:48:47 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D82143D46; Thu, 2 Feb 2006 00:48:46 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id 900C75783; Thu, 2 Feb 2006 01:56:55 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on cvs.freesbie.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 Received: from [192.168.99.16] (host14-150.pool875.interbusiness.it [87.5.150.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP; Thu, 2 Feb 2006 01:56:55 +0100 (CET) Message-ID: <43E156E7.8080900@freesbie.org> Date: Thu, 02 Feb 2006 01:48:39 +0100 From: Dario Freni User-Agent: Mozilla Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Julian Elischer References: <3281.1138742578@critter.freebsd.dk> <43E127A5.9060503@freesbie.org> <43E13058.7020708@elischer.org> In-Reply-To: <43E13058.7020708@elischer.org> X-Enigmail-Version: 0.94.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBA491804E988211CABF1715A" X-Virus-Scanned: ClamAV using ClamSMTP Cc: small@freebsd.org, rizzo@icir.org, Poul-Henning Kamp , rwatson@freebsd.org, "M. Warner Losh" , current@freebsd.org Subject: Re: [RFC] what do we do with picobsd ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 00:48:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBA491804E988211CABF1715A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Julian Elischer wrote: > on the contrary i thin it should be there.. *somewhere*. > the question is, "where?" I think that it can stay under tools. There's a port already under sysutils/freesbie (actually points to 1.x toolkit, will be updated in the weekend by the mantainer). We should also discuss the opportunity to use freesbie for release builds with bsdinstaller. Integrating the work already made with bsdinstaller test releases should be trivial. Bye, Dario P.S.: Maybe this belongs to arch@... --=20 Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --------------enigBA491804E988211CABF1715A 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.1 (Darwin) iD8DBQFD4Vbnymi72IiShysRArwWAJ44zYw3HDvBtXNv9v34eKSz4+r7PACg33O+ FnrSy7zsG+GdrZcQy3QviQw= =g4aT -----END PGP SIGNATURE----- --------------enigBA491804E988211CABF1715A-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 00:49:16 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83E1216A420 for ; Thu, 2 Feb 2006 00:49:16 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 202D543D45 for ; Thu, 2 Feb 2006 00:49:16 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 95D7346B4C; Wed, 1 Feb 2006 19:49:06 -0500 (EST) Date: Thu, 2 Feb 2006 00:51:13 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kris Kennaway In-Reply-To: <20060202004044.GA99245@xor.obsecurity.org> Message-ID: <20060202004845.C87763@fledge.watson.org> References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> <43E14C53.3060400@rogers.com> <20060202004044.GA99245@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mike Jakubik , K?vesd?n G?bor , current@FreeBSD.org, trustedbsd-audit@TrustedBSD.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 00:49:16 -0000 On Wed, 1 Feb 2006, Kris Kennaway wrote: >> Personally, i would like to see less "experimental" code in 6.1. Perhaps it >> would be better to wait until everyone feels the code is ready? > > Why do you care if code that is not enabled by default is present in the > system? :-) Well, I think there are some potential risks. The main ones are: (1) That the unconditionally compiled bits cause problems. Primarily this is the audit support in login, sshd, etc. Apple has been running with basically the same code for a couple of years now, but there is always risk in change. (2) Risk to users who do try the experimental support and run into bugs, or run into things that we will change for a 6.2 release as we fix problems. The first set is happily quite a small set; the second set of potential problems is something that we'll need to think about and manage carefully. We're not yet committed to audit3 in RELENG_6_2, in the sense that there's a long way to go and nothing is in that tree yet. It would be quite desirable though, if we can pull it all together. In a week or so, we'll have a much better idea of how things look. Maybe we can get you to run audit on the ports build cluster. :-) Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 00:54:13 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C09516A420 for ; Thu, 2 Feb 2006 00:54:13 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.FreeBSD.org (Postfix) with SMTP id 4C3A743D48 for ; Thu, 2 Feb 2006 00:54:12 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 95928 invoked from network); 2 Feb 2006 00:54:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=13FEGRysWQfUqxcImfH7G/MYwnkiQILkMfrREhZ15WLRa+SJXtVDHRsReZDPNloYbnH4t41JoPxcQRgSPkH61hZTslrtK6+tlXheN4yBg9dg9txvqz5l/oCFswIPyt/XmlaT7Zz8NiL7zX31RCQwXoM1eeKdXCcmRpOCbLL/BJ8= ; Received: from unknown (HELO ?70.30.133.184?) (mikej@rogers.com@70.30.133.184 with plain) by smtp102.rog.mail.re2.yahoo.com with SMTP; 2 Feb 2006 00:54:11 -0000 Message-ID: <43E1586E.6090203@rogers.com> Date: Wed, 01 Feb 2006 19:55:10 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kris Kennaway References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> <43E14C53.3060400@rogers.com> <20060202004044.GA99245@xor.obsecurity.org> In-Reply-To: <20060202004044.GA99245@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: trustedbsd-audit@TrustedBSD.org, K?vesd?n G?bor , Robert Watson , current@FreeBSD.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 00:54:13 -0000 Kris Kennaway wrote: > On Wed, Feb 01, 2006 at 07:03:31PM -0500, Mike Jakubik wrote: > >> Personally, i would like to see less "experimental" code in 6.1. Perhaps >> it would be better to wait until everyone feels the code is ready? >> > > Why do you care if code that is not enabled by default is present in > the system? :-) > > Kris > Well... While you, me, and other viewers of this list may be fully aware of the situation, some else who is either new to FreeBSD or missed out on this info may try it and possibly be disappointed. Which would ruin their experience and/or opinion of FreeBSD in general. I guess if it does make it in, it would be a good idea to clearly notify the user that it is still experimental, etc.. From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 00:58:23 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6424716A420; Thu, 2 Feb 2006 00:58:23 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id C33A943D48; Thu, 2 Feb 2006 00:58:22 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id A87E81A3C1F; Wed, 1 Feb 2006 16:58:22 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2D9B5516E3; Wed, 1 Feb 2006 19:58:20 -0500 (EST) Date: Wed, 1 Feb 2006 19:58:19 -0500 From: Kris Kennaway To: Robert Watson Message-ID: <20060202005819.GA8761@xor.obsecurity.org> References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> <43E14C53.3060400@rogers.com> <20060202004044.GA99245@xor.obsecurity.org> <20060202004845.C87763@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <20060202004845.C87763@fledge.watson.org> User-Agent: Mutt/1.4.2.1i Cc: trustedbsd-audit@TrustedBSD.org, current@FreeBSD.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 00:58:23 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 02, 2006 at 12:51:13AM +0000, Robert Watson wrote: > We're not yet committed to audit3 in RELENG_6_2, in the sense that there'= s=20 > a long way to go and nothing is in that tree yet. It would be quite=20 > desirable though, if we can pull it all together. In a week or so, we'll= =20 > have a much better idea of how things look. Maybe we can get you to run= =20 > audit on the ports build cluster. :-) I'll be happy to, if it's relatively easy to configure meaningfully. kris --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD4VkrWry0BWjoQKURAlzcAJ9RkWYQQ56WtT4q/RQaYxM4JB9RJQCgiP3G VSKq1PSdZq3zGJGkX9h3n/w= =Bj6z -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 01:08:56 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36EA716A420; Thu, 2 Feb 2006 01:08:56 +0000 (GMT) (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 C279443D48; Thu, 2 Feb 2006 01:08:53 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k1218p8d055927; Wed, 1 Feb 2006 20:08:51 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 1 Feb 2006 20:08:29 -0500 User-Agent: KMail/1.6.2 References: <17373.50882.270841.554876@roam.psg.com> <20060201200221.GA31743@xor.obsecurity.org> <43E13974.8010801@freebsd.org> In-Reply-To: <43E13974.8010801@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200602012008.34093.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV devel-20050919/1266/Wed Feb 1 17:21:42 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Gary Palmer , Joe Marcus Clarke , David Scheidt Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 01:08:56 -0000 On Wednesday 01 February 2006 05:43 pm, Gary Palmer wrote: > Kris Kennaway wrote: > >On Wed, Feb 01, 2006 at 11:27:35AM -0800, Randy Bush wrote: > >>>I'm running firefox 1.5 on a fairly recent 6-STABLE, and see > >>> massive memory leaks. They seem to be related to javascript. > >> > >>if i turn javascript off, the leak continues > >> > >>5000000 2053 45 1 16578 451 657355K 60K 657416K ? > >> washingtonpo 5000000 2053 45 1 16801 450 667667K > >> 60K 667727K ? washingtonpo 5000000 483 44 1 16800 > >> 143 667685K 16K 667702K ? washingtonpo 5000000 483 > >> 44 1 16852 144 673796K 16K 673813K ? washingtonpo > >> 5000000 483 44 1 17023 145 677964K 16K 677981K ? > >> washingtonpo > >> > >>given the inability of Jason Evans to > >> replicate. we need to think a bit about a forward debugging > >> path. > > > >It will presumably involve the firefox developers. > > Firefox 1.5.0.1 was recently released which contains fixes for > "several memory leaks". Firefox 1.5.0.1 port: http://people.freebsd.org/~jkim/firefox-1.5.0.1.diff Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 01:15:52 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D52E816A422 for ; Thu, 2 Feb 2006 01:15:52 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C236643D48 for ; Thu, 2 Feb 2006 01:15:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1CCB546B49; Wed, 1 Feb 2006 20:15:40 -0500 (EST) Date: Thu, 2 Feb 2006 01:17:47 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Jakubik In-Reply-To: <43E1586E.6090203@rogers.com> Message-ID: <20060202011453.Y87763@fledge.watson.org> References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> <43E14C53.3060400@rogers.com> <20060202004044.GA99245@xor.obsecurity.org> <43E1586E.6090203@rogers.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-audit@TrustedBSD.org, K?vesd?n G?bor , current@FreeBSD.org, Kris Kennaway Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 01:15:53 -0000 On Wed, 1 Feb 2006, Mike Jakubik wrote: > Kris Kennaway wrote: >> On Wed, Feb 01, 2006 at 07:03:31PM -0500, Mike Jakubik wrote: >> >>> Personally, i would like to see less "experimental" code in 6.1. Perhaps >>> it would be better to wait until everyone feels the code is ready? >> >> Why do you care if code that is not enabled by default is present in the >> system? :-) > > Well... While you, me, and other viewers of this list may be fully aware of > the situation, some else who is either new to FreeBSD or missed out on this > info may try it and possibly be disappointed. Which would ruin their > experience and/or opinion of FreeBSD in general. I guess if it does make it > in, it would be a good idea to clearly notify the user that it is still > experimental, etc.. In the past, we've marked features as experimental using a man page note, e.g., in the mac(4) man page: NAME mac -- Mandatory Access Control SYNOPSIS options MAC ... BUGS See mac(9) concerning appropriateness for production use. The TrustedBSD MAC Framework is considered experimental in FreeBSD. And as such in the release notes. However, maybe we could add the following also: - Dependence on defining "options EXPERIMENTAL" in the kernel configuration file -- if the kernel isn't compiled with the EXPERIMENTAL option, a compile error warning that it needs to be defined will be generated. - When a kernel is configured with an experimental feature, config generates a warning, similar to the ones it currently generates about GPL'd components, etc. And we should make sure there is a note in the handbook section as well. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 01:16:52 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D035716A420; Thu, 2 Feb 2006 01:16:52 +0000 (GMT) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (creme-brulee.marcuscom.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B30F43D48; Thu, 2 Feb 2006 01:16:52 +0000 (GMT) (envelope-from marcus@FreeBSD.org) Received: from shumai.marcuscom.com (shumai.marcuscom.com [192.168.1.4]) by creme-brulee.marcuscom.com (8.13.4/8.13.4) with ESMTP id k121HAoX039559; Wed, 1 Feb 2006 20:17:10 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Jung-uk Kim In-Reply-To: <200602012008.34093.jkim@FreeBSD.org> References: <17373.50882.270841.554876@roam.psg.com> <20060201200221.GA31743@xor.obsecurity.org> <43E13974.8010801@freebsd.org> <200602012008.34093.jkim@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hozn1bn7hEqMaonGbS2T" Organization: FreeBSD, Inc. Date: Wed, 01 Feb 2006 20:16:51 -0500 Message-Id: <1138843011.29492.19.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Cc: Gary Palmer , freebsd-current@FreeBSD.org, David Scheidt Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 01:16:53 -0000 --=-hozn1bn7hEqMaonGbS2T Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2006-02-01 at 20:08 -0500, Jung-uk Kim wrote: > On Wednesday 01 February 2006 05:43 pm, Gary Palmer wrote: > > Kris Kennaway wrote: > > >On Wed, Feb 01, 2006 at 11:27:35AM -0800, Randy Bush wrote: > > >>>I'm running firefox 1.5 on a fairly recent 6-STABLE, and see > > >>> massive memory leaks. They seem to be related to javascript. > > >> > > >>if i turn javascript off, the leak continues > > >> > > >>5000000 2053 45 1 16578 451 657355K 60K 657416K ?=20 > > >> washingtonpo 5000000 2053 45 1 16801 450 667667K =20 > > >> 60K 667727K ? washingtonpo 5000000 483 44 1 16800=20 > > >> 143 667685K 16K 667702K ? washingtonpo 5000000 483 =20 > > >> 44 1 16852 144 673796K 16K 673813K ? washingtonpo > > >> 5000000 483 44 1 17023 145 677964K 16K 677981K ? > > >> washingtonpo > > >> > > >>given the inability of Jason Evans to > > >> replicate. we need to think a bit about a forward debugging > > >> path. > > > > > >It will presumably involve the firefox developers. > > > > Firefox 1.5.0.1 was recently released which contains fixes for > > "several memory leaks". >=20 > Firefox 1.5.0.1 port: >=20 > http://people.freebsd.org/~jkim/firefox-1.5.0.1.diff We were already testing RC 1, and I presume ahze will put the final 1.5.0.1 port in the tree soon. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-hozn1bn7hEqMaonGbS2T Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD4V2Db2iPiv4Uz4cRAqCbAKCnZrkqIO5qpoVLJQbQIPEjufAq7wCfTodS Vvf9YPfqfbgfQOBRLwoGpcs= =VXxp -----END PGP SIGNATURE----- --=-hozn1bn7hEqMaonGbS2T-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 02:14:10 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C50816A420; Thu, 2 Feb 2006 02:14:10 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (ns1.pittgoth.com [216.38.206.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16D6543D46; Thu, 2 Feb 2006 02:14:09 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from localhost (net-ix.gw.ai.net [205.134.160.6] (may be forged)) (authenticated bits=0) by pittgoth.com (8.13.4/8.13.4) with ESMTP id k122sL7W055797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Feb 2006 21:54:21 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Wed, 1 Feb 2006 21:14:00 -0500 From: Tom Rhodes To: Robert Watson Message-Id: <20060201211400.09e9fdb8.trhodes@FreeBSD.org> In-Reply-To: <20060202011453.Y87763@fledge.watson.org> References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> <43E14C53.3060400@rogers.com> <20060202004044.GA99245@xor.obsecurity.org> <43E1586E.6090203@rogers.com> <20060202011453.Y87763@fledge.watson.org> X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mikej@rogers.com, trustedbsd-audit@TrustedBSD.org, gabor.kovesdan@t-hosting.hu, current@FreeBSD.org, kris@obsecurity.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 02:14:10 -0000 On Thu, 2 Feb 2006 01:17:47 +0000 (GMT) Robert Watson wrote: > On Wed, 1 Feb 2006, Mike Jakubik wrote: > > > Kris Kennaway wrote: > >> On Wed, Feb 01, 2006 at 07:03:31PM -0500, Mike Jakubik wrote: > >> > >>> Personally, i would like to see less "experimental" code in 6.1. Perhaps > >>> it would be better to wait until everyone feels the code is ready? > >> > >> Why do you care if code that is not enabled by default is present in the > >> system? :-) > > > > Well... While you, me, and other viewers of this list may be fully aware of > > the situation, some else who is either new to FreeBSD or missed out on this > > info may try it and possibly be disappointed. Which would ruin their > > experience and/or opinion of FreeBSD in general. I guess if it does make it > > in, it would be a good idea to clearly notify the user that it is still > > experimental, etc.. > > In the past, we've marked features as experimental using a man page note, > e.g., in the mac(4) man page: > > NAME > mac -- Mandatory Access Control > > SYNOPSIS > options MAC > > ... > > BUGS > See mac(9) concerning appropriateness for production use. The TrustedBSD > MAC Framework is considered experimental in FreeBSD. > > And as such in the release notes. However, maybe we could add the following > also: > > - Dependence on defining "options EXPERIMENTAL" in the kernel configuration > file -- if the kernel isn't compiled with the EXPERIMENTAL option, a compile > error warning that it needs to be defined will be generated. > > - When a kernel is configured with an experimental feature, config generates a > warning, similar to the ones it currently generates about GPL'd components, > etc. > > And we should make sure there is a note in the handbook section as well. There is, IIRC. I'll double check to make sure. -- Tom Rhodes From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 03:15:17 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E22F116A420 for ; Thu, 2 Feb 2006 03:15:17 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp100.rog.mail.re2.yahoo.com (smtp100.rog.mail.re2.yahoo.com [206.190.36.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 33EFB43D5A for ; Thu, 2 Feb 2006 03:15:16 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 49749 invoked from network); 2 Feb 2006 03:15:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CsGsw19Zq70vgXbPimcxbHwsic+RIJe43mZ2gTDXga315FY/OlzizmpygjU6LxtB/8tQiQO4AXu7YVXb1+8DmDsbMA8DMkHUIAC7L+grPNBr/R/1RElIReXWTntA3p0RYPsYiOLMDNWfi82PS6H9VHgEMaJjudNd1/FacMMIUjY= ; Received: from unknown (HELO ?70.30.133.184?) (mikej@rogers.com@70.30.133.184 with plain) by smtp100.rog.mail.re2.yahoo.com with SMTP; 2 Feb 2006 03:15:15 -0000 Message-ID: <43E1797F.4010902@rogers.com> Date: Wed, 01 Feb 2006 22:16:15 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Robert Watson References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> <43E14C53.3060400@rogers.com> <20060202004044.GA99245@xor.obsecurity.org> <43E1586E.6090203@rogers.com> <20060202011453.Y87763@fledge.watson.org> In-Reply-To: <20060202011453.Y87763@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: trustedbsd-audit@TrustedBSD.org, K?vesd?n G?bor , current@FreeBSD.org, Kris Kennaway Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 03:15:18 -0000 Robert Watson wrote: > And as such in the release notes. However, maybe we could add the > following also: > > - Dependence on defining "options EXPERIMENTAL" in the kernel > configuration > file -- if the kernel isn't compiled with the EXPERIMENTAL option, a > compile > error warning that it needs to be defined will be generated. > > - When a kernel is configured with an experimental feature, config > generates a > warning, similar to the ones it currently generates about GPL'd > components, > etc. I think thats a great idea. This is something that would be easily identified by a user. The bottom of a man page or relnotes may not always be viewed. This should apply to all code/features that are experimental. From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 06:44:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A24316A420 for ; Thu, 2 Feb 2006 06:44:57 +0000 (GMT) (envelope-from Thomas.Gellekum@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 2995243D4C for ; Thu, 2 Feb 2006 06:44:55 +0000 (GMT) (envelope-from Thomas.Gellekum@gmx.de) Received: (qmail invoked by alias); 02 Feb 2006 06:44:54 -0000 Received: from bras-co-85-197-1-147.westend.de (EHLO hanbruch.tg.intern) [85.197.1.147] by mail.gmx.net (mp020) with SMTP; 02 Feb 2006 07:44:54 +0100 X-Authenticated: #18235045 To: Randy Bush References: <17373.50882.270841.554876@roam.psg.com> <43DE2130.70203@yahoo.com.br> <17374.8868.815312.597508@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> <17377.14732.391882.775974@roam.psg.com> From: Thomas Gellekum In-Reply-To: <17377.14732.391882.775974@roam.psg.com> Date: 02 Feb 2006 07:44:52 +0100 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Emacs Gnus X-Y-GMX-Trusted: 0 Cc: Kris Kennaway , Jason Evans , current@freebsd.org Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 06:44:57 -0000 Randy Bush writes: > > I've been running Xorg, firefox, and emacs, since last night (with > > jemalloc's redzone code enabled) on a two-day-old -current build, and > > after many invocations of firefox and emacs, with serious attempts to > > make firefox use lots of memory, Xorg's, memory usage has stabilized > > at ~75 MB mapped, and ~35 MB resident. > > what seems to be common with those of us seeing leakage is multiple > windows and many tabs. i standardly have three windows each with > six to ten tabs. Might be another meaningless coincidence, but I've had problems similar to this with the GTK2 Smokey-Blue theme on older firefoxes. Since then I've switched to Clearlooks and firefox-1.5, with no apparent ill effects. tg From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 07:11:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11F5F16A420 for ; Thu, 2 Feb 2006 07:11:45 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3123843D4C for ; Thu, 2 Feb 2006 07:11:43 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail09.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k127BdYF027368 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Feb 2006 18:11:41 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k127Bd2r003330; Thu, 2 Feb 2006 18:11:39 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k127BbaH003329; Thu, 2 Feb 2006 18:11:37 +1100 (EST) (envelope-from peter) Date: Thu, 2 Feb 2006 18:11:37 +1100 From: Peter Jeremy To: "Daniel O'Connor" Message-ID: <20060202071137.GB921@turion.vk2pj.dyndns.org> References: <200601301652.16237.doconnor@gsoft.com.au> <200602011424.57722.doconnor@gsoft.com.au> <17376.65268.396436.72837@roam.psg.com> <200602020952.39010.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <200602020952.39010.doconnor@gsoft.com.au> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: KDE 3.5.0 seems much chubbier than 3.4.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 07:11:45 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2006-Feb-02 09:52:22 +1030, Daniel O'Connor wrote: >Also, xrestop shows X using 120Mb of pixmaps. >X's size is 315M, and I have a 64Mb video card. > >64 + 120 =3D 184 >315 - 184 =3D 131 > >ie 131Mb of space that X is using but no obvious reason.. There's a lot more to X than the video memory and pixmaps. In my case (this is X.org 6.9.0 on 6-stable/amd64 but the principle is the same), I have 32MB video RAM, 28MB pixmaps and ps report that X is using 78MB - a difference of 18M. If I look at the process memory map (see procfs(5)), the breakdown is: 38MB vnode backed (mostly shared libraries) 32MB device (video memory) 6.75MB swap + default (malloc'd space, stack etc) This suggests that X is storing a lot of pixmaps in video RAM (for efficiency). --=20 Peter Jeremy --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD4bCn/opHv/APuIcRAn32AKCrMlzMD3dsVV2bH3FwN04Eto+UcwCeMri0 d4WUc7lCxw/mutMGSd1Nmrw= =AIUv -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 07:43:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D069E16A420 for ; Thu, 2 Feb 2006 07:43:33 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8645E43D48 for ; Thu, 2 Feb 2006 07:43:28 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k127h4X6009411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2006 18:13:09 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Peter Jeremy Date: Thu, 2 Feb 2006 18:12:56 +1030 User-Agent: KMail/1.9.1 References: <200601301652.16237.doconnor@gsoft.com.au> <200602020952.39010.doconnor@gsoft.com.au> <20060202071137.GB921@turion.vk2pj.dyndns.org> In-Reply-To: <20060202071137.GB921@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3255083.LCvO2a4O8M"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200602021812.59001.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: KDE 3.5.0 seems much chubbier than 3.4.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 07:43:33 -0000 --nextPart3255083.LCvO2a4O8M Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 02 February 2006 17:41, Peter Jeremy wrote: > On Thu, 2006-Feb-02 09:52:22 +1030, Daniel O'Connor wrote: > >Also, xrestop shows X using 120Mb of pixmaps. > >X's size is 315M, and I have a 64Mb video card. > > > >64 + 120 =3D 184 > >315 - 184 =3D 131 > > > >ie 131Mb of space that X is using but no obvious reason.. > > There's a lot more to X than the video memory and pixmaps. Sure, but 131Mb is a lot of "other". > In my case (this is X.org 6.9.0 on 6-stable/amd64 but the principle is > the same), I have 32MB video RAM, 28MB pixmaps and ps report that X > is using 78MB - a difference of 18M. > > If I look at the process memory map (see procfs(5)), the breakdown is: > 38MB vnode backed (mostly shared libraries) > 32MB device (video memory) > 6.75MB swap + default (malloc'd space, stack etc) > > This suggests that X is storing a lot of pixmaps in video RAM (for > efficiency). [inchoate 18:12] ~ >ps -axw| grep bin/X 826 ?? S 66:52.15 /usr/X11R6/bin/X -nolisten tcp :0 -auth /var/run/= xauth/A:0-lKynIa (Xorg) [inchoate 18:12] ~ >sudo cat /proc/826/map cat: /proc/826/map: File too large Broken in -current? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3255083.LCvO2a4O8M Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD4bgC5ZPcIHs/zowRAvycAJ42HP6gRu4LoAPWuKbdq5ZdexHHdgCfRDrN 8QmbpurdEPyoeaecepTVGhE= =phSI -----END PGP SIGNATURE----- --nextPart3255083.LCvO2a4O8M-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 07:51:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B8BC16A420 for ; Thu, 2 Feb 2006 07:51:00 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4291743D82 for ; Thu, 2 Feb 2006 07:50:50 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so328943nzo for ; Wed, 01 Feb 2006 23:50:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ejCqOUKysioNM8PDJQp5hBqUUdn1bZ0KycClOGjKmkcs45DZa/XcAmHMAcpcZv88nAfSKp9v8ToKCegG5N2K8PQr+LM7MVQGdT/LJ+dwWy+8Bfz7vkaJP/gX2OP5IbuW1SRjcynoe4ftHJ/XbHFMMVbkELr3ydrysrFytvM0jT4= Received: by 10.65.98.11 with SMTP id a11mr192749qbm; Wed, 01 Feb 2006 23:50:50 -0800 (PST) Received: by 10.65.150.12 with HTTP; Wed, 1 Feb 2006 23:50:50 -0800 (PST) Message-ID: <7579f7fb0602012350y4aacee80g7f7b87bafc87459f@mail.gmail.com> Date: Wed, 1 Feb 2006 23:50:50 -0800 From: Matthew Jacob To: FreeBSD Current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: unstable kernels in -current right now? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 07:51:00 -0000 The kernels I'm building for i386 don't compile all the way through (dies in the if_bridge and ipfw modules) and panic when I log in with the stack trace of panic: mutex Giant not owned at ../../../kern/vfs_subr.c:2029 vrele do_execve kern_execve exeve syscall Anybody on this one? From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 08:01:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECB5516A420 for ; Thu, 2 Feb 2006 08:01:01 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C35343D45 for ; Thu, 2 Feb 2006 08:01:00 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail18.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k1280wDx025961 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Feb 2006 19:00:59 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k1280wQ1003485; Thu, 2 Feb 2006 19:00:58 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k1280wlb003484; Thu, 2 Feb 2006 19:00:58 +1100 (EST) (envelope-from peter) Date: Thu, 2 Feb 2006 19:00:58 +1100 From: Peter Jeremy To: "Daniel O'Connor" Message-ID: <20060202080058.GC921@turion.vk2pj.dyndns.org> References: <200601301652.16237.doconnor@gsoft.com.au> <200602020952.39010.doconnor@gsoft.com.au> <20060202071137.GB921@turion.vk2pj.dyndns.org> <200602021812.59001.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="96YOpH+ONegL0A3E" Content-Disposition: inline In-Reply-To: <200602021812.59001.doconnor@gsoft.com.au> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: KDE 3.5.0 seems much chubbier than 3.4.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 08:01:02 -0000 --96YOpH+ONegL0A3E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2006-Feb-02 18:12:56 +1030, Daniel O'Connor wrote: >On Thursday 02 February 2006 17:41, Peter Jeremy wrote: >> On Thu, 2006-Feb-02 09:52:22 +1030, Daniel O'Connor wrote: >> >Also, xrestop shows X using 120Mb of pixmaps. >> >X's size is 315M, and I have a 64Mb video card. >> > >> >64 + 120 =3D 184 >> >315 - 184 =3D 131 >> > >> >ie 131Mb of space that X is using but no obvious reason.. >> >> There's a lot more to X than the video memory and pixmaps. > >Sure, but 131Mb is a lot of "other". Yes, I suspect that some of that is freed memory that hasn't been released. >> In my case (this is X.org 6.9.0 on 6-stable/amd64 but the principle is >> the same), I have 32MB video RAM, 28MB pixmaps and ps report that X >> is using 78MB - a difference of 18M. >> >> If I look at the process memory map (see procfs(5)), the breakdown is: >> 38MB vnode backed (mostly shared libraries) >> 32MB device (video memory) >> 6.75MB swap + default (malloc'd space, stack etc) >> >> This suggests that X is storing a lot of pixmaps in video RAM (for >> efficiency). > >[inchoate 18:12] ~ >ps -axw| grep bin/X > 826 ?? S 66:52.15 /usr/X11R6/bin/X -nolisten tcp :0 -auth /var/run= /xauth/A:0-lKynIa (Xorg) >[inchoate 18:12] ~ >sudo cat /proc/826/map >cat: /proc/826/map: File too large > >Broken in -current? Pilot error. /proc/.../map is a text file but has "unusual" semantics to ensure atomicity - you have to issue a read with a big enough block size that the entire map can be fetched in a single read. The following is off a -current sysem (but pre-jemalloc running X.org 6.8.2). The X server is 81204KB virtual, 62228KB resident. server# ps -axlww|grep n/X 0 712 709 1 96 0 81204 62228 select Ss ?? 6:21.92 /usr/X1= 1R6/bin/X -nolisten tcp -once :2 -auth /usr/X11R6/lib/X11/xdm/authdir/authf= iles/A:2-g79Knf (Xorg) server# dd if=3D/proc/712/map bs=3D64k 0x8048000 0x81c2000 319 0 0xc3a70438 r-x 4 2 0x0 COW NC vnode /usr/X11R6/bi= n/Xorg 0x81c2000 0x81d1000 15 0 0xc3a4f9d8 rw- 1 0 0x2180 COW NNC vnode /usr/X11R6= /bin/Xorg 0x81d1000 0x81e3000 17 0 0xc402d870 rw- 1 0 0x2180 COW NNC default - 0x81e3000 0x89b2000 1999 0 0xc5799bb8 rwx 1 0 0x2180 COW NNC default - 0x89b2000 0x8b4c000 409 0 0xc3a70780 rwx 1 0 0x2180 COW NNC default - 0x8b4c000 0x8b7c000 48 0 0xc4889078 rwx 1 0 0x2180 COW NNC default - 0x8b7c000 0x8c5d000 225 0 0xc567b8e8 rwx 1 0 0x2180 COW NNC default - 0x8c5d000 0x8c67000 10 0 0xc560ca50 rwx 1 0 0x2180 COW NC default - 0x8c67000 0x8fe8000 897 0 0xc3eaa5a0 rwx 1 0 0x2180 COW NNC default - 0x8fe8000 0x9322000 826 0 0xc3b367f8 rwx 1 0 0x2180 NCOW NNC default - 0x281c2000 0x281e8000 27 0 0xc103a528 r-x 125 54 0x4 COW NC vnode /libexec/= ld-elf.so.1 0x281e8000 0x281ea000 2 0 0xc3a4fb40 rw- 1 0 0x2180 COW NC vnode /libexec/l= d-elf.so.1 0x281ea000 0x281ef000 5 0 0xc55469d8 rw- 1 0 0x2180 COW NC default - 0x281ef000 0x28200000 9 0 0xc577d000 rwx 1 0 0x2180 COW NC swap - 0x28200000 0x2820f000 14 0 0xc1029780 r-x 38 24 0x0 COW NC vnode /lib/libz.= so.3 0x2820f000 0x28210000 1 0 0xc3a4fca8 r-x 1 0 0x2180 COW NC vnode /lib/libz.= so.3 0x28210000 0x28211000 1 0 0xc3a4fbb8 rwx 1 0 0x2180 COW NC vnode /lib/libz.= so.3 0x28211000 0x28226000 11 0 0xc1028708 r-x 47 26 0x0 COW NC vnode /lib/libm.= so.4 0x28226000 0x28227000 1 0 0xc3a4fd20 r-x 1 0 0x2180 COW NC vnode /lib/libm.= so.4 0x28227000 0x2822a000 2 0 0xc3a4fd98 rwx 1 0 0x2180 COW NC vnode /lib/libm.= so.4 0x2822a000 0x2822b000 0 0 0xc3a4f3c0 r-x 11 6 0x0 COW NC vnode /usr/X11R6/l= ib/libXau.so.0 0x2822b000 0x2822c000 1 0 0xc3a70a50 r-x 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/libXau.so.0 0x2822c000 0x2822d000 1 0 0xc3a70168 rwx 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/libXau.so.0 0x2822d000 0x2822f000 2 0 0xc3a2e8e8 r-x 11 6 0x0 COW NC vnode /usr/X11R6/l= ib/libXdmcp.so.0 0x2822f000 0x28230000 1 0 0xc3a70078 r-x 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/libXdmcp.so.0 0x28230000 0x28232000 2 0 0xc3a70708 rwx 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/libXdmcp.so.0 0x28232000 0x28301000 164 0 0xc3a4fe88 r-x 1 0 0x2180 COW NC vnode /lib/lib= c.so.6 0x28301000 0x28302000 1 0 0xc3a70ac8 r-x 1 0 0x2180 COW NC vnode /lib/libc.= so.6 0x28302000 0x28308000 6 0 0xc49730f0 rwx 1 0 0x2180 COW NNC vnode /lib/libc= =2Eso.6 0x28308000 0x2831b000 9 0 0xc3f49bb8 rwx 1 0 0x2180 COW NNC default - 0x2831b000 0x2831f000 3 0 0xc3aba438 rwx 10 0 0x180 NCOW NNC device - 0x2831f000 0x2832a000 4 0 0xc3a71a50 r-x 6 4 0x0 COW NC vnode /usr/X11R6/li= b/modules/fonts/libfreetype.so 0x2832a000 0x2832b000 1 0 0xc3a719d8 r-x 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/modules/fonts/libfreetype.so 0x2832b000 0x2832c000 1 0 0xc3a71960 rwx 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/modules/fonts/libfreetype.so 0x2832c000 0x28394000 0 0 0xc3a718e8 r-x 18 12 0x0 COW NC vnode /usr/local/= lib/libfreetype.so.9 0x28394000 0x28395000 1 0 0xc3a71870 r-x 1 0 0x2180 COW NC vnode /usr/local= /lib/libfreetype.so.9 0x28395000 0x28398000 3 0 0xc3a717f8 rwx 1 0 0x2180 COW NC vnode /usr/local= /lib/libfreetype.so.9 0x28398000 0x283a8000 16 0 0xc3aba438 rwx 10 0 0x180 NCOW NNC device - 0x283a8000 0x283aa000 2 0 0xc457aca8 rwx 5 0 0x180 NCOW NNC device - 0x283aa000 0x283b2000 0 0 0xc457aca8 rwx 5 0 0x180 NCOW NNC device - 0x283b2000 0x283b4000 0 0 0xc457aca8 rwx 5 0 0x180 NCOW NNC device - 0x283bd000 0x283c4000 7 0 0xc3d5cca8 rwx 1 0 0x2180 COW NNC default - 0x283c4000 0x283de000 0 0 0xc414abb8 rwx 3 0 0x190 NCOW NNC swap - 0x28400000 0x2a400000 8192 0 0xc3aba438 rwx 10 0 0x180 NCOW NNC device - 0x2a400000 0x2ac00000 2048 0 0xc3aba438 rwx 10 0 0x180 NCOW NNC device - 0x2ac00000 0x2ac40000 9 0 0xc3aba438 rwx 10 0 0x180 NCOW NNC device - 0x2ac40000 0x2b540000 0 0 0xc457aca8 rwx 5 0 0x180 NCOW NNC device - 0x2b540000 0x2bd40000 0 0 0xc457aca8 rwx 5 0 0x180 NCOW NNC device - 0x2bd40000 0x2bda0000 50 0 0xc51fc960 rwx 3 0 0x190 NCOW NNC swap - 0x2bda0000 0x2be00000 96 0 0xc4443528 rwx 3 0 0x190 NCOW NNC swap - 0xbfba0000 0xbfbe0000 56 0 0xc56ca870 rwx 1 0 0x2180 COW NC default - 0xbfbe0000 0xbfc00000 32 0 0xc51d52d0 rwx 1 0 0x2180 COW NNC default - 0+1 records in 0+1 records out 4110 bytes transferred in 0.045363 secs (90603 bytes/sec) server#=20 Note that my 6.9.0 map is about 3 times as large. --=20 Peter Jeremy --96YOpH+ONegL0A3E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD4bw5/opHv/APuIcRAjYAAKC0vMVccXnoVwkhzuWixUTOVaXr/wCgoK+Y eSW7S8r5vPetFtVKNGBFn6k= =xFtS -----END PGP SIGNATURE----- --96YOpH+ONegL0A3E-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 08:36:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3BE416A420 for ; Thu, 2 Feb 2006 08:36:33 +0000 (GMT) (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 10A1B43D49 for ; Thu, 2 Feb 2006 08:36:32 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from [10.0.0.1] (67-40-203-22.tukw.qwest.net [67.40.203.22]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.1/8.13.1) with ESMTP id k128aTDx014978; Thu, 2 Feb 2006 03:36:30 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 2 Feb 2006 00:34:57 -0800 (PST) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Matthew Jacob In-Reply-To: <7579f7fb0602012350y4aacee80g7f7b87bafc87459f@mail.gmail.com> Message-ID: <20060202003440.R562@10.0.0.1> References: <7579f7fb0602012350y4aacee80g7f7b87bafc87459f@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.52 on 216.240.101.25 Cc: FreeBSD Current Subject: Re: unstable kernels in -current right now? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 08:36:33 -0000 On Wed, 1 Feb 2006, Matthew Jacob wrote: > The kernels I'm building for i386 don't compile all the way through > (dies in the if_bridge and ipfw modules) and panic when I log in with > the stack trace of > > panic: mutex Giant not owned at ../../../kern/vfs_subr.c:2029 > vrele > do_execve > kern_execve > exeve > syscall This is my fault. Patch will be in the tree in about 10 minutes. Thanks, Jeff > > > Anybody on this one? > _______________________________________________ > 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 Feb 2 09:03:04 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E57516A420; Thu, 2 Feb 2006 09:03:04 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail25.syd.optusnet.com.au (mail25.syd.optusnet.com.au [211.29.133.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id A356643D48; Thu, 2 Feb 2006 09:03:03 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail25.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k1292wQG000700 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Feb 2006 20:02:58 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k1292vbh003686; Thu, 2 Feb 2006 20:02:57 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k1292uck003685; Thu, 2 Feb 2006 20:02:56 +1100 (EST) (envelope-from peter) Date: Thu, 2 Feb 2006 20:02:56 +1100 From: Peter Jeremy To: Mike Jakubik Message-ID: <20060202090256.GE921@turion.vk2pj.dyndns.org> References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> <43E14C53.3060400@rogers.com> <20060202004044.GA99245@xor.obsecurity.org> <43E1586E.6090203@rogers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E1586E.6090203@rogers.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: trustedbsd-audit@TrustedBSD.org, Robert Watson , current@freebsd.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 09:03:04 -0000 On Wed, 2006-Feb-01 19:55:10 -0500, Mike Jakubik wrote: >Well... While you, me, and other viewers of this list may be fully aware >of the situation, some else who is either new to FreeBSD or missed out >on this info may try it and possibly be disappointed. Which would ruin >their experience and/or opinion of FreeBSD in general. I guess if it >does make it in, it would be a good idea to clearly notify the user that >it is still experimental, etc.. IMHO, once the API/ABI is stable, there is no reason why it can't be MFC'd as long as someone is willing to to do the work (including maintenance). The advantages are that the code is available to a larger group of users and therefore will (hopefully) get more testing. The more testing it gets, the sooner the "experimental" tag can be removed. The users for whom the audit framework is important will mostly not want to run bleeding edge code and so getting audit into -STABLE (and production quality) is important to this group. Keep in mind that FreeBSD has shipped for years with utilities and kernel options that have "use at your own risk" warnings all over them. Looking at RELENG_4 LINT (the oldest I have readily to hand): # NOTE 1: The options, CPU_BTB_EN, CPU_LOOP_EN, CPU_IORT, # CPU_LOOP_EN and CPU_RSTK_EN should not be used because of CPU bugs. # These options may crash your system. ... # Protocol families: # Only the INET (Internet) family is officially supported in FreeBSD. # Source code for the NS (Xerox Network Service) is provided for amusement # value. ... # Experimental IPsec implementation that uses the kernel crypto # framework. ... # NB: The NULL, PORTAL, UMAP and UNION filesystems are known to be # buggy, and WILL panic your system if you attempt to do anything with # them. They are included here as an incentive for some enterprising # soul to sit down and fix them. ... # apm: Laptop Advanced Power Management (experimental) ... # Note that this ACPI support is experimental and it's use may result in # machine hangs or kernel panics. ... # ihfc driver for Cologne Chip ISA chipsets (experimental!) -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 09:09:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 660F716A420; Thu, 2 Feb 2006 09:09:47 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 041B543D48; Thu, 2 Feb 2006 09:09:46 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4aTK-000GjO-FY; Thu, 02 Feb 2006 09:09:46 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4aTJ-00068O-NW; Thu, 02 Feb 2006 01:09:45 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17377.52313.223292.867132@roam.psg.com> Date: Thu, 2 Feb 2006 01:09:45 -0800 To: Gary Palmer References: <17373.50882.270841.554876@roam.psg.com> <43DECB94.50307@lclark.edu> <17375.1454.11511.502872@roam.psg.com> <20060131102914.660ukp2ko4wgogoc@netchild.homeip.net> <20060201164124.GA28139@panix.com> <17377.2983.58360.592928@roam.psg.com> <20060201200221.GA31743@xor.obsecurity.org> <43E13974.8010801@freebsd.org> Cc: FreeBSD Current Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 09:09:47 -0000 > Firefox 1.5.0.1 was recently released which contains fixes for "several > memory leaks". and it's in ports. and it did not fix what i am seeing. randy From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 09:11:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6935216A420; Thu, 2 Feb 2006 09:11:35 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id E48DF43D49; Thu, 2 Feb 2006 09:11:34 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4aV4-000Glz-IQ; Thu, 02 Feb 2006 09:11:34 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4aV3-00068r-QB; Thu, 02 Feb 2006 01:11:33 -0800 From: Randy Bush Message-ID: <17377.52421.306578.72826@roam.psg.com> Date: Thu, 2 Feb 2006 01:11:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Gary Palmer References: <17373.50882.270841.554876@roam.psg.com> <43DECB94.50307@lclark.edu> <17375.1454.11511.502872@roam.psg.com> <20060131102914.660ukp2ko4wgogoc@netchild.homeip.net> <20060201164124.GA28139@panix.com> <17377.2983.58360.592928@roam.psg.com> <20060201200221.GA31743@xor.obsecurity.org> <43E13974.8010801@freebsd.org> Cc: FreeBSD Current Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 09:11:35 -0000 >> Firefox 1.5.0.1 was recently released which contains fixes for "several >> memory leaks". > and it's in ports. and it did not fix what i am seeing. hmmm. maybe not. the new port is DISTVERSION= 1.5 PORTREVISION= 6 PORTEPOCH= 1 sorry for the contusion randy From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 09:20:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 621BB16A420 for ; Thu, 2 Feb 2006 09:20:19 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABEBD43D62 for ; Thu, 2 Feb 2006 09:20:14 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4adP-000GyT-Qy; Thu, 02 Feb 2006 09:20:12 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4adP-00069r-2h; Thu, 02 Feb 2006 01:20:11 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17377.52938.578073.23073@roam.psg.com> Date: Thu, 2 Feb 2006 01:20:10 -0800 To: Freddie Cash References: <17373.50882.270841.554876@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> <17377.14732.391882.775974@roam.psg.com> <200602011504.34905.fcash@ocis.net> Cc: freebsd-current@freebsd.org Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 09:20:19 -0000 > Is this the issue you are running into: > http://primates.ximian.com/~federico/news-2005-11.html#moz-images not sure, of course. but o this would not seem to be a recent phenomonon, and my leak is o my leak keeps leaking more when i do nothing, i.e. when no new images are being loaded. well, on that last point, i do have an mrtg running that refreshes itself every five minutes. and it has 20+ gif graphs. randy From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 09:32:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A04016A427 for ; Thu, 2 Feb 2006 09:32:22 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BC1443D49 for ; Thu, 2 Feb 2006 09:32:22 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4apB-000HIC-HA; Thu, 02 Feb 2006 09:32:21 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4apA-0006Bp-P7; Thu, 02 Feb 2006 01:32:20 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17377.53668.270774.740608@roam.psg.com> Date: Thu, 2 Feb 2006 01:32:20 -0800 To: Josh Carroll References: <17373.50882.270841.554876@roam.psg.com> <17374.32961.768874.463443@roam.psg.com> <20060130214226.GA68308@xor.obsecurity.org> <17374.35319.265698.476631@roam.psg.com> <20060130215408.GA68492@xor.obsecurity.org> <17374.36245.570152.464206@roam.psg.com> <00D8C07F-FA95-47B6-9EF9-6C25652E93D2@freebsd.org> <17377.14732.391882.775974@roam.psg.com> <8cb6106e0602011534n85f3373p8f31cdf34dfacb2@mail.gmail.com> Cc: current@freebsd.org Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 09:32:22 -0000 > http://forums.mozillazine.org/viewtopic.php?t=354828#memcache > And set the maximum memory cache to 8000 or 16000, then see if this > problem persists? > about:config > Create a new integer key, named "browser.cache.memory.capacity" and > assign a value in KB for the cache size. > about:cache > Maximum storage size: 16000 KiB (or whatever you set it to). > Watching xrestop, the Pxm mem value for Firefox should not exceed your > maximum set. no change. note that it seems to not be using all of the cache as set. Memory cache device Number of entries: 873 Maximum storage size: 32000 KiB Storage in use: 26533 KiB Inactive storage: 1665 KiB randy From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 10:02:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7330F16A422; Thu, 2 Feb 2006 10:02:22 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80F7743D4C; Thu, 2 Feb 2006 10:02:20 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5E999.dip.t-dialin.net [84.165.233.153]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id k129qbhj098867; Thu, 2 Feb 2006 10:52:37 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id k12A2IIX061391; Thu, 2 Feb 2006 11:02:18 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 02 Feb 2006 11:02:17 +0100 Message-ID: <20060202110217.h1qei951c4kgkssc@netchild.homeip.net> X-Priority: 3 (Normal) Date: Thu, 02 Feb 2006 11:02:17 +0100 From: Alexander Leidinger To: Randy Bush References: <17373.50882.270841.554876@roam.psg.com> <43DECB94.50307@lclark.edu> <17375.1454.11511.502872@roam.psg.com> <20060131102914.660ukp2ko4wgogoc@netchild.homeip.net> <20060201164124.GA28139@panix.com> <17377.2983.58360.592928@roam.psg.com> <20060201200221.GA31743@xor.obsecurity.org> <43E13974.8010801@freebsd.org> <17377.52421.306578.72826@roam.psg.com> In-Reply-To: <17377.52421.306578.72826@roam.psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: Gary Palmer , FreeBSD Current Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 10:02:22 -0000 Randy Bush wrote: >>> Firefox 1.5.0.1 was recently released which contains fixes for "several >>> memory leaks". >> and it's in ports. and it did not fix what i am seeing. > > hmmm. maybe not. the new port is > > DISTVERSION= 1.5 > PORTREVISION= 6 > PORTEPOCH= 1 > > sorry for the contusion A buggy extension is also possible... see: http://forums.mozillazine.org/viewtopic.php?t=354828#2051115 Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 The real reason large families benefit society is because at least a few of the children in the world shouldn't be raised by beginners. From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 10:16:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D654516A420 for ; Thu, 2 Feb 2006 10:16:01 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32ED543D45 for ; Thu, 2 Feb 2006 10:16:00 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.3/8.13.1) with ESMTP id k12AFunG001583 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 2 Feb 2006 11:15:59 +0100 (CET) (envelope-from mime@traveller.cz) From: Michal Mertl To: Scott Long In-Reply-To: <43E0FE09.50804@samsco.org> References: <1138813174.1358.34.camel@genius.i.cz> <43E0FE09.50804@samsco.org> Content-Type: text/plain Date: Thu, 02 Feb 2006 11:15:51 +0100 Message-Id: <1138875351.1807.12.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: em(4) stops forwarding X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 10:16:02 -0000 Scott Long wrote: > Michal Mertl wrote: > > Hello, > > > > I've been running CURRENT for long time and never experienced problem > > with the built-in em(4) card before. Recently (I first noticed it on Jan > > 24) the card has stopped working several times. Nothing gets into the > > log file. Carrier is still detected properly but no data is exchanged. > > Ifconfig up/down doesn't help but kldunload/load does. When I run > > tcpdump I don't see any packet coming in but I see some outgoing. > > > > Can someone suggest what to look at when it happens the next time? I > > have DDB compiled in. I will try to sniff the wire using another machine > > next time to see if the card sends out anything. > > > > The command 'pciconf -lv' says about the card this: > > em0@pci2:1:0: class=0x020000 card=0x05491014 chip=0x101e8086 rev=0x03 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = '82540EP Gigabit Ethernet Controller (Mobile)' > > class = network > > subclass = ethernet > > > > The dmesg: > > em0: port > > 0x8000-0x803f mem 0xc0220000-0xc023ffff,0xc0200000-0xc020ffff irq 11 at > > device 1.0 on pci2 > > em0: Ethernet address: 00:0d:60:cd:ae:e2 > > em0: [FAST] > > > > The interrupt is shared since the machine is a notebook. I don't know if > > it was just a coincidence but I think that it happened at the same time > > as my USB mouse stopped working - the USB controller is on the same irq. > > > > Michal > > > > What is sharing the interrupt? vgapci0, ipw0, ehci0, uhci0-2. I don't think vgapci0 and ipw0 are really using the interrupt when I use em0. > > Scott > > From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 11:58:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D78B16A420 for ; Thu, 2 Feb 2006 11:58:59 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99DBD43D60 for ; Thu, 2 Feb 2006 11:58:54 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp208-69.lns1.adl2.internode.on.net [203.122.208.69]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k12Bwjc3012376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2006 22:28:51 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Peter Jeremy Date: Thu, 2 Feb 2006 22:28:30 +1030 User-Agent: KMail/1.9.1 References: <200601301652.16237.doconnor@gsoft.com.au> <200602021812.59001.doconnor@gsoft.com.au> <20060202080058.GC921@turion.vk2pj.dyndns.org> In-Reply-To: <20060202080058.GC921@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1832218.mcvY3qsCUu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200602022228.38939.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: KDE 3.5.0 seems much chubbier than 3.4.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 11:58:59 -0000 --nextPart1832218.mcvY3qsCUu Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 02 February 2006 18:30, Peter Jeremy wrote: > >Sure, but 131Mb is a lot of "other". > > Yes, I suspect that some of that is freed memory that hasn't been > released. Hmm.. There is memory pressure so I would think that is either a bug or a=20 misdiagnosis :) > Pilot error. /proc/.../map is a text file but has "unusual" semantics > to ensure atomicity - you have to issue a read with a big enough block > size that the entire map can be fetched in a single read. The following > is off a -current sysem (but pre-jemalloc running X.org 6.8.2). Ahh.. What does it mean? :) 0x8048000 0x819d000 193 202 0xc430fe88 r-x 2 1 0x0 COW NC vnode /usr/X11R6/= bin/Xorg 0x819d000 0x81ac000 11 0 0xc430fc30 rw- 1 0 0x2180 COW NNC vnode /usr/X11R6= /bin/Xorg 0x81ac000 0x81be000 17 0 0xc43228e8 rw- 1 0 0x2180 COW NNC default - 0x81be000 0xb000000 2819 0 0xc4321000 rwx 1 0 0x2180 COW NNC default - 0xb000000 0x12000000 9908 0 0xc45d2708 rwx 1 0 0x2180 NCOW NNC swap - 0x2819d000 0x281c0000 25 0 0xc143ab40 r-x 167 68 0x4 COW NC vnode /libexec/= ld-elf.so.1 0x281c0000 0x281c2000 2 0 0xc43211e0 rw- 1 0 0x2180 COW NC vnode /libexec/l= d-elf.so.1 0x281c2000 0x281c7000 4 0 0xc4322870 rw- 1 0 0x2180 COW NNC default - 0x281c7000 0x281cf000 8 0 0xc4321168 rwx 1 0 0x2180 COW NNC default - 0x281cf000 0x281dd000 12 0 0xc3c7e438 r-x 115 48 0x0 COW NC vnode /lib/libz= =2Eso.3 0x281dd000 0x281de000 1 0 0xc43212d0 r-x 1 0 0x2180 COW NC vnode /lib/libz.= so.3 0x281de000 0x281df000 0 0 0xc43222d0 rwx 1 0 0x2180 COW NNC vnode /lib/libz= =2Eso.3 0x281df000 0x281f2000 11 0 0xc14290f0 r-x 110 44 0x0 COW NC vnode /lib/libm= =2Eso.4 0x281f2000 0x281f3000 1 0 0xc4321528 r-x 1 0 0x2180 COW NC vnode /lib/libm.= so.4 0x281f3000 0x281f4000 1 0 0xc4322348 rwx 1 0 0x2180 COW NC vnode /lib/libm.= so.4 0x281f4000 0x281f5000 1 0 0xc43220f0 r-x 18 10 0x0 COW NC vnode /usr/X11R6/= lib/libXau.so.0 0x281f5000 0x281f6000 1 0 0xc4321438 r-x 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/libXau.so.0 0x281f6000 0x281f7000 0 0 0xc4321780 rwx 1 0 0x2180 COW NNC vnode /usr/X11R= 6/lib/libXau.so.0 0x281f7000 0x281f9000 1 0 0xc4321e88 r-x 7 4 0x0 COW NC vnode /usr/X11R6/li= b/libXdmcp.so.0 0x281f9000 0x281fa000 1 0 0xc43214b0 r-x 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/libXdmcp.so.0 0x281fa000 0x281fc000 2 0 0xc4321348 rwx 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/libXdmcp.so.0 0x281fc000 0x282c0000 145 0 0xc430fca8 r-x 1 0 0x2180 COW NC vnode /lib/lib= c.so.6 0x282c0000 0x282c1000 1 0 0xc43217f8 r-x 1 0 0x2180 COW NC vnode /lib/libc.= so.6 0x282c1000 0x282c7000 6 0 0xc43213c0 rwx 1 0 0x2180 COW NNC vnode /lib/libc= =2Eso.6 0x282c7000 0x282e3000 12 0 0xc3e2d1e0 rwx 1 0 0x2180 COW NNC default - 0x282e3000 0x2836a000 68 0 0xc433b960 r-x 1 0 0x2180 COW NC vnode /usr/X11R= 6/lib/modules/extensions/libglx.so.1 0x2836a000 0x2836b000 1 0 0xc433bd20 r-x 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/modules/extensions/libglx.so.1 0x2836b000 0x2838e000 0 0 0xc433bca8 rwx 1 0 0x2180 COW NNC vnode /usr/X11R= 6/lib/modules/extensions/libglx.so.1 0x2838e000 0x2838f000 0 0 0xc4322b40 rwx 1 0 0x2180 COW NNC default - 0x2838f000 0x28ac7000 300 0 0xc433b870 r-x 1 0 0x2180 COW NC vnode /usr/X11= R6/lib/libGLcore.so.1 0x28ac7000 0x28ac8000 0 0 0xc433bbb8 r-x 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/libGLcore.so.1 0x28ac8000 0x28afa000 0 0 0xc433bb40 rwx 1 0 0x2180 COW NNC vnode /usr/X11R= 6/lib/libGLcore.so.1 0x28afa000 0x28afe000 0 0 0xc4322e10 rwx 1 0 0x2180 NCOW NNC default - 0x28afe000 0x28aff000 1 0 0xc433ba50 r-x 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/libnvidia-tls.so.1 0x28aff000 0x28b00000 1 0 0xc433b9d8 rwx 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/libnvidia-tls.so.1 0x28b00000 0x28b0a000 10 0 0xc433b5a0 r-x 3 2 0x0 COW NC vnode /usr/X11R6/l= ib/modules/fonts/libfreetype.so 0x28b0a000 0x28b0b000 1 0 0xc433b528 r-x 1 0 0x2180 COW NC vnode /usr/X11R6= /lib/modules/fonts/libfreetype.so 0x28b0b000 0x28b0c000 1 0 0xc433b4b0 rwx 1 0 0x2180 COW NNC vnode /usr/X11R= 6/lib/modules/fonts/libfreetype.so 0x28b0c000 0x28b6d000 59 0 0xc433b438 r-x 76 24 0x0 COW NC vnode /usr/local= /lib/libfreetype.so.9 0x28b6d000 0x28b6e000 1 0 0xc433b3c0 r-x 1 0 0x2180 COW NC vnode /usr/local= /lib/libfreetype.so.9 0x28b6e000 0x28b71000 3 0 0xc433b348 rwx 1 0 0x2180 COW NNC vnode /usr/loca= l/lib/libfreetype.so.9 0x28b71000 0x28b72000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x28b72000 0x28b73000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x28b73000 0x28bd3000 16 0 0xc4322d20 rwx 1 0 0x2180 NCOW NNC device - 0x28bd3000 0x28be3000 16 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x28be3000 0x28bf3000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x28bf3000 0x28bfb000 8 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x28bfb000 0x28bfc000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x28bfc000 0x28bfd000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x28bfd000 0x29581000 2404 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29581000 0x29601000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29601000 0x29602000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29602000 0x29619000 1 0 0xc4322bb8 rwx 2 0 0x190 NCOW NNC swap - 0x29619000 0x29629000 16 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29629000 0x2962a000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2962a000 0x2963a000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2963a000 0x2964a000 16 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2964a000 0x2965a000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2965a000 0x2965b000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2965b000 0x2965c000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2965c000 0x29664000 8 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29664000 0x29665000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29665000 0x29666000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29666000 0x2987e000 529 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2987e000 0x298ff000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x298ff000 0x29900000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29900000 0x29910000 16 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29910000 0x29911000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29911000 0x29921000 1 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29921000 0x29929000 4 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2992a000 0x29932000 6 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29932000 0x29947000 5 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x29947000 0x2a30f000 10 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a30f000 0x2a317000 8 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a317000 0x2a407000 163 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a407000 0x2a40f000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a40f000 0x2a447000 29 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a447000 0x2a450000 7 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a450000 0x2a45c000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a464000 0x2a474000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a474000 0x2a47c000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a47c000 0x2a484000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a488000 0x2a490000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a490000 0x2a4a0000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a4ff000 0x2a513000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a51f000 0x2a54b000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a58b000 0x2a59b000 0 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a627000 0x2a827000 370 0 0xc4322c30 rwx 45 0 0x180 NCOW NNC device - 0x2a827000 0x2a8d2000 31 0 0xc39e13c0 r-x 1 0 0x0 COW NC vnode /usr/local/j= dk1.5.0/jre/lib/fonts/LucidaSansRegular.ttf 0xbfbe0000 0xbfc00000 18 0 0xc4321078 rwx 1 0 0x2180 COW NNC default - =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1832218.mcvY3qsCUu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD4fPu5ZPcIHs/zowRAuR1AJ9xjVp5c32h4ir2daOFy1BvROWJIgCfco6n pw+h4n3SXWRBdTbCOEvnqXE= =4tac -----END PGP SIGNATURE----- --nextPart1832218.mcvY3qsCUu-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 12:55:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9758E16A420 for ; Thu, 2 Feb 2006 12:55:17 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B76F43D48 for ; Thu, 2 Feb 2006 12:55:17 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4dzY-000M0g-RL; Thu, 02 Feb 2006 12:55:17 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4dzY-0000QG-3T; Thu, 02 Feb 2006 04:55:16 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17378.307.604113.440165@roam.psg.com> Date: Thu, 2 Feb 2006 02:55:15 -1000 To: Alexander Leidinger Cc: FreeBSD Current Subject: Re: xorg 6.9.0 mem leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 12:55:17 -0000 > A buggy extension is also possible... see: > http://forums.mozillazine.org/viewtopic.php?t=354828#2051115 Known Leaky Extensions The following extensions are known to have memory leaks: Fixed Adblock 0.5.3.042 that and hacking the diff to 1.5.1 seems to have staunched the flow. thank you and all the others who gave me clue along the way. randy From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 13:07:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2AAE16A420 for ; Thu, 2 Feb 2006 13:06:59 +0000 (GMT) (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 4349E43D45 for ; Thu, 2 Feb 2006 13:06:56 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k12D6tWF040143; Thu, 2 Feb 2006 06:06:55 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43E203F9.9060307@samsco.org> Date: Thu, 02 Feb 2006 06:07:05 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Mertl References: <1138813174.1358.34.camel@genius.i.cz> <43E0FE09.50804@samsco.org> <1138875351.1807.12.camel@genius.i.cz> In-Reply-To: <1138875351.1807.12.camel@genius.i.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: em(4) stops forwarding X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 13:07:00 -0000 Michal Mertl wrote: > Scott Long wrote: > >>Michal Mertl wrote: >> >>>Hello, >>> >>>I've been running CURRENT for long time and never experienced problem >>>with the built-in em(4) card before. Recently (I first noticed it on Jan >>>24) the card has stopped working several times. Nothing gets into the >>>log file. Carrier is still detected properly but no data is exchanged. >>>Ifconfig up/down doesn't help but kldunload/load does. When I run >>>tcpdump I don't see any packet coming in but I see some outgoing. >>> >>>Can someone suggest what to look at when it happens the next time? I >>>have DDB compiled in. I will try to sniff the wire using another machine >>>next time to see if the card sends out anything. >>> >>>The command 'pciconf -lv' says about the card this: >>>em0@pci2:1:0: class=0x020000 card=0x05491014 chip=0x101e8086 rev=0x03 >>>hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82540EP Gigabit Ethernet Controller (Mobile)' >>> class = network >>> subclass = ethernet >>> >>>The dmesg: >>>em0: port >>>0x8000-0x803f mem 0xc0220000-0xc023ffff,0xc0200000-0xc020ffff irq 11 at >>>device 1.0 on pci2 >>>em0: Ethernet address: 00:0d:60:cd:ae:e2 >>>em0: [FAST] >>> >>>The interrupt is shared since the machine is a notebook. I don't know if >>>it was just a coincidence but I think that it happened at the same time >>>as my USB mouse stopped working - the USB controller is on the same irq. >>> >>>Michal >>> >> >>What is sharing the interrupt? > > > vgapci0, ipw0, ehci0, uhci0-2. I don't think vgapci0 and ipw0 are really > using the interrupt when I use em0. > > Ouch. For now, edit /sys/dev/em/if_em.c and add the following line to the top of the file: #define NO_EM_FASTINTR Also, does your kernel config include the apic device? Scott From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 13:24:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E70F016A420 for ; Thu, 2 Feb 2006 13:24:19 +0000 (GMT) (envelope-from shigeru@iij.ad.jp) Received: from omgo.iij.ad.jp (omgo.iij.ad.jp [202.232.30.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FD4D43D45 for ; Thu, 2 Feb 2006 13:24:19 +0000 (GMT) (envelope-from shigeru@iij.ad.jp) Received: OTM-MO id k12DOHXT003901; Thu, 2 Feb 2006 22:24:17 +0900 (JST) DomainKey-Signature: a=rsa-sha1; s=omgo; d=iij.ad.jp; c=nofws; q=dns; h=date:message-id:to:cc:from:in-reply-to:references:x-mailer: mime-version:content-type:content-transfer-encoding; b=snXfAe3UjhKbLhrwtX2xwS32IKdRvrNCkrc433UU4ZBIPMLeEE7xf0+dnRC3Yc1Ec EbuXmSWQZ1iCXDqp/fUSg== Received: OTM-MIX0 id k12DOGUi016224; Thu, 2 Feb 2006 22:24:17 +0900 (JST) Received: from localhost (mercury.iij.ad.jp [192.168.184.90]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id k12DOGox026439; Thu, 2 Feb 2006 22:24:16 +0900 (JST) Date: Thu, 02 Feb 2006 22:24:16 +0900 (JST) Message-Id: <20060202.222416.39149923.shigeru@iij.ad.jp> To: scottl@samsco.org From: Yamamoto Shigeru In-Reply-To: <43E203F9.9060307@samsco.org> References: <43E0FE09.50804@samsco.org> <1138875351.1807.12.camel@genius.i.cz> <43E203F9.9060307@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mime@traveller.cz, freebsd-current@freebsd.org Subject: Re: em(4) stops forwarding X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 13:24:20 -0000 >>>>> "Scott" == Scott Long writes: Scott> Ouch. For now, edit /sys/dev/em/if_em.c and add the following line Scott> to the top of the file: Scott> #define NO_EM_FASTINTR I already tested this option. When setting NO_EM_FASTINTR, my machine is freezed(= no answer for ping). ;-( #When freezed, I use X window system. So, I can't check what is happend. Scott> Also, does your kernel config include the apic device? Yes, I configre my kernel with ACPI. Thanks, ------- YAMAMOTO Shigeru From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 13:52:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16DC816A420 for ; Thu, 2 Feb 2006 13:52:58 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CD7143D48 for ; Thu, 2 Feb 2006 13:52:56 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 22098 invoked from network); 2 Feb 2006 13:52:55 -0000 Received: from unknown (HELO localhost) ([pbs]775067@[217.187.177.111]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 2 Feb 2006 13:52:55 -0000 Date: Thu, 2 Feb 2006 14:52:54 +0100 From: Fabian Keil To: Yamamoto Shigeru Message-ID: <20060202145254.24b95f11@localhost> In-Reply-To: <20060202.222416.39149923.shigeru@iij.ad.jp> References: <43E0FE09.50804@samsco.org> <1138875351.1807.12.camel@genius.i.cz> <43E203F9.9060307@samsco.org> <20060202.222416.39149923.shigeru@iij.ad.jp> X-Mailer: Sylpheed-Claws 2.0.0 (GTK+ 2.8.6; i386-portbld-freebsd6.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2006-08-19.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_JNnghUaiw2zxDELM6ex6on0; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-current@freebsd.org Subject: Re: em(4) stops forwarding X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 13:52:58 -0000 --Sig_JNnghUaiw2zxDELM6ex6on0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Yamamoto Shigeru wrote: > >>>>> "Scott" =3D=3D Scott Long writes: > Scott> Also, does your kernel config include the apic device? >=20 > Yes, I configre my kernel with ACPI. ACPI doesn't require apic. Fabian --=20 http://www.fabiankeil.de/ --Sig_JNnghUaiw2zxDELM6ex6on0 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD4g69jV8GA4rMKUQRArimAJwJfHlhQt0+s8ZzirPrdsi1L7NfuwCfb7dz uyXzkCcPqeDp1CPN74c/6G8= =Okad -----END PGP SIGNATURE----- --Sig_JNnghUaiw2zxDELM6ex6on0-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 14:22:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE47216A432 for ; Thu, 2 Feb 2006 14:22:24 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id B593043D45 for ; Thu, 2 Feb 2006 14:22:18 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.3/8.13.1) with ESMTP id k12EME7P038302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 2 Feb 2006 15:22:17 +0100 (CET) (envelope-from mime@traveller.cz) From: Michal Mertl To: Scott Long In-Reply-To: <43E203F9.9060307@samsco.org> References: <1138813174.1358.34.camel@genius.i.cz> <43E0FE09.50804@samsco.org> <1138875351.1807.12.camel@genius.i.cz> <43E203F9.9060307@samsco.org> Content-Type: text/plain Date: Thu, 02 Feb 2006 15:22:10 +0100 Message-Id: <1138890130.9192.3.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: em(4) stops forwarding X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 14:22:24 -0000 Scott Long wrote: > Michal Mertl wrote: > > Scott Long wrote: > > > >>Michal Mertl wrote: > >> > >>>Hello, > >>> > >>>I've been running CURRENT for long time and never experienced problem > >>>with the built-in em(4) card before. Recently (I first noticed it on Jan > >>>24) the card has stopped working several times. Nothing gets into the > >>>log file. Carrier is still detected properly but no data is exchanged. > >>>Ifconfig up/down doesn't help but kldunload/load does. When I run > >>>tcpdump I don't see any packet coming in but I see some outgoing. > >>> > >>>Can someone suggest what to look at when it happens the next time? I > >>>have DDB compiled in. I will try to sniff the wire using another machine > >>>next time to see if the card sends out anything. > >>> > >>>The command 'pciconf -lv' says about the card this: > >>>em0@pci2:1:0: class=0x020000 card=0x05491014 chip=0x101e8086 rev=0x03 > >>>hdr=0x00 > >>> vendor = 'Intel Corporation' > >>> device = '82540EP Gigabit Ethernet Controller (Mobile)' > >>> class = network > >>> subclass = ethernet > >>> > >>>The dmesg: > >>>em0: port > >>>0x8000-0x803f mem 0xc0220000-0xc023ffff,0xc0200000-0xc020ffff irq 11 at > >>>device 1.0 on pci2 > >>>em0: Ethernet address: 00:0d:60:cd:ae:e2 > >>>em0: [FAST] > >>> > >>>The interrupt is shared since the machine is a notebook. I don't know if > >>>it was just a coincidence but I think that it happened at the same time > >>>as my USB mouse stopped working - the USB controller is on the same irq. > >>> > >>>Michal > >>> > >> > >>What is sharing the interrupt? > > > > > > vgapci0, ipw0, ehci0, uhci0-2. I don't think vgapci0 and ipw0 are really > > using the interrupt when I use em0. > > > > > > Ouch. For now, edit /sys/dev/em/if_em.c and add the following line to > the top of the file: > > #define NO_EM_FASTINTR Do you know the reason of the problem? Wouldn't it be better if I used stock driver and got some information for you when it doesn't work? I use the machine as my workstation so it isn't such a big problem when it looses the network. > Also, does your kernel config include the apic device? Yes, it does. But I believe that the chipset doesn't have it and neither the CPU supports it. Michal From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 14:33:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CB9A16A420 for ; Thu, 2 Feb 2006 14:33:54 +0000 (GMT) (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 B9EDE43D48 for ; Thu, 2 Feb 2006 14:33:49 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k12EXliS040616; Thu, 2 Feb 2006 07:33:47 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43E2184B.3040606@samsco.org> Date: Thu, 02 Feb 2006 07:33:47 -0700 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: Michal Mertl References: <1138813174.1358.34.camel@genius.i.cz> <43E0FE09.50804@samsco.org> <1138875351.1807.12.camel@genius.i.cz> <43E203F9.9060307@samsco.org> <1138890130.9192.3.camel@genius.i.cz> In-Reply-To: <1138890130.9192.3.camel@genius.i.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: em(4) stops forwarding X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 14:33:54 -0000 Michal Mertl wrote: > Scott Long wrote: > >>Michal Mertl wrote: >> >>>Scott Long wrote: >>> >>> >>>>Michal Mertl wrote: >>>> >>>> >>>>>Hello, >>>>> >>>>>I've been running CURRENT for long time and never experienced problem >>>>>with the built-in em(4) card before. Recently (I first noticed it on Jan >>>>>24) the card has stopped working several times. Nothing gets into the >>>>>log file. Carrier is still detected properly but no data is exchanged. >>>>>Ifconfig up/down doesn't help but kldunload/load does. When I run >>>>>tcpdump I don't see any packet coming in but I see some outgoing. >>>>> >>>>>Can someone suggest what to look at when it happens the next time? I >>>>>have DDB compiled in. I will try to sniff the wire using another machine >>>>>next time to see if the card sends out anything. >>>>> >>>>>The command 'pciconf -lv' says about the card this: >>>>>em0@pci2:1:0: class=0x020000 card=0x05491014 chip=0x101e8086 rev=0x03 >>>>>hdr=0x00 >>>>> vendor = 'Intel Corporation' >>>>> device = '82540EP Gigabit Ethernet Controller (Mobile)' >>>>> class = network >>>>> subclass = ethernet >>>>> >>>>>The dmesg: >>>>>em0: port >>>>>0x8000-0x803f mem 0xc0220000-0xc023ffff,0xc0200000-0xc020ffff irq 11 at >>>>>device 1.0 on pci2 >>>>>em0: Ethernet address: 00:0d:60:cd:ae:e2 >>>>>em0: [FAST] >>>>> >>>>>The interrupt is shared since the machine is a notebook. I don't know if >>>>>it was just a coincidence but I think that it happened at the same time >>>>>as my USB mouse stopped working - the USB controller is on the same irq. >>>>> >>>>>Michal >>>>> >>>> >>>>What is sharing the interrupt? >>> >>> >>>vgapci0, ipw0, ehci0, uhci0-2. I don't think vgapci0 and ipw0 are really >>>using the interrupt when I use em0. >>> >>> >> >>Ouch. For now, edit /sys/dev/em/if_em.c and add the following line to >>the top of the file: >> >>#define NO_EM_FASTINTR > > > Do you know the reason of the problem? Wouldn't it be better if I used > stock driver and got some information for you when it doesn't work? I > use the machine as my workstation so it isn't such a big problem when it > looses the network. > The problem is that the drivers that are sharing the interrupt, particularly the USB ones, can spend a very very long time waiting on locks to service the interrupt. During that time, the interrupt pin is masked and the all interrupts from all shared devices don't get delivered. So even though the if_em driver has a very fast interrupt handler, it still has to wait on the USB drivers. During that wait, a burst of network traffic might come into the card, filling its buffers and triggering an overflow. This would be especially likely to happen while the kernel is flushing out filesystem i/o. In theory the interrupt service latency shouldn't be any different whether the if_em driver is fast or not, but there might be coincidental timing issues that I don't understand. That's why I'd like you to set the #ifdef in the driver to revert it back to it's classic behaviour and see if the problem persists. If it doesn't, then I'll have to rethink some of the changes that I made to it. Scott > >>Also, does your kernel config include the apic device? > > > Yes, it does. But I believe that the chipset doesn't have it and neither > the CPU supports it. > > Michal > From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 18:13:37 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0A9A16A422 for ; Thu, 2 Feb 2006 18:13:37 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4061943D46 for ; Thu, 2 Feb 2006 18:13:34 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id k12IDYJW007272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Feb 2006 13:13:34 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k12IDSOo070467; Thu, 2 Feb 2006 13:13:28 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17378.19400.856354.995643@grasshopper.cs.duke.edu> Date: Thu, 2 Feb 2006 13:13:28 -0500 (EST) To: freebsd-current@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Subject: hwpmc & kernel modules? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 18:13:38 -0000 I'm currently doing a driver for a 10GbE nic, and now that it works, I'm disappointed to find that FreeBSD is considerably slower than Linux & Solaris on the same hardware (8Gb/s vs 5Gb/s). My driver is currently a module, and I'm having problems figuring out how much time my driver is using. Is there any way to profile kernel modules with hwpmc? It seems like the kgmon samples ignore loadable modules entirely. Is it possible to do what solaris does for crashdumps, and build an elf file with the modules linked in at their current locations? This would be helpful for post-mortum debugging too.. Thanks, Drew From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 18:39:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2710316A420 for ; Thu, 2 Feb 2006 18:39:19 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92F4143D48 for ; Thu, 2 Feb 2006 18:39:18 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 7578347 for multiple; Thu, 02 Feb 2006 13:39:44 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k12Id43J003311; Thu, 2 Feb 2006 13:39:06 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Julian Elischer Date: Thu, 2 Feb 2006 13:37:13 -0500 User-Agent: KMail/1.9.1 References: <200602011341.k11Dfbq1008941@lurza.secnetix.de> <200602011240.11682.jhb@freebsd.org> <43E117F3.9090400@elischer.org> In-Reply-To: <43E117F3.9090400@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602021337.15761.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1270/Thu Feb 2 07:47:37 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@freebsd.org, Oliver Fromme Subject: Re: nextboot (was Re: boot block differences between 4.x and 6.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: Thu, 02 Feb 2006 18:39:19 -0000 On Wednesday 01 February 2006 15:20, Julian Elischer wrote: > John Baldwin wrote: > >On Wednesday 01 February 2006 08:41, Oliver Fromme wrote: > >>Julian Elischer wrote: > >> > Oliver Fromme wrote: > >> > > [...] > >> > > I think the most visible changes in the boot blocks was > >> > > UFS2 support and the removal of nextboot(8) support. > >> > > >> > which I hope to put back because we continue to need it. > >> > >>I agree that it's needed. It's a very useful feature. > >> > >> > (The new nextboot being dependent on the root filesystem still being > >> > ok which is unacceptable to most embedded devices I've worked on, and > >> > why we still use the old bootblocks on all systems shipped.). > >>> > >>>From my point of view, the biggest problem with the old > >> > >>nextboot was the fact that it ignored loader(8) and tried > >>to load the kernel directly. While that might work under > >>certain conditions, it's not good in general. > >> > >>Therefore I think that a new nextboot implementation > >>should be implemented in loader itself. Since loader(8) > >>doesn't (and shouldn't) support writing to UFS2, the > >>state information should be written to an unused area in > >>block 2 on the disk, or something similar. In fact, one > >>byte is sufficient: It can be used as an index into a > >>table (ASCII text file), e.g. /boot/nextboot.conf. > >> > >>Would that be feasible to implement? > > > >/boot/loader already does nextboot and does it by using UFS writing (which > > it does implement and use on archs whose disk drivers support writing > > such as i386) to overwrite (but not extend) /boot/nextboot.conf. > > which is exactly the feature that I wanted to avoid with the original > nextboot(8). > Do NOT get any where-to-boot-from info from the possibly suspect > filesystem. Do NOT write back to the "possibly-suspect-filesystem". > > The original nextboot was BIOS specific and not portable which is why > the new one > has some good points (portable), but it didn't rely on correctness of the > bootblock FS code or an intact first FS. You are already presuming something of an FS as that is where you get your loader and kernel from. (Well, you could get the kernel from somewhere else perhaps, but not the loader unless you are using PXE or a CD to boot.) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 19:00:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49BAC16A420 for ; Thu, 2 Feb 2006 19:00:47 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C24B43D53 for ; Thu, 2 Feb 2006 19:00:46 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 02 Feb 2006 11:00:46 -0800 Message-ID: <43E256DD.1030504@elischer.org> Date: Thu, 02 Feb 2006 11:00:45 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <1138813174.1358.34.camel@genius.i.cz> <43E0FE09.50804@samsco.org> <1138875351.1807.12.camel@genius.i.cz> <43E203F9.9060307@samsco.org> <1138890130.9192.3.camel@genius.i.cz> <43E2184B.3040606@samsco.org> In-Reply-To: <43E2184B.3040606@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michal Mertl , freebsd-current@freebsd.org Subject: Re: em(4) stops forwarding X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Feb 2006 19:00:47 -0000 Scott Long wrote: > Michal Mertl wrote: > >> Scott Long wrote: >> >>> Michal Mertl wrote: >>> >>>> Scott Long wrote: >>>> >>>> >>>>> Michal Mertl wrote: >>>>> >>>>> >>>>>> Hello, >>>>>> >>>>>> I've been running CURRENT for long time and never experienced >>>>>> problem >>>>>> with the built-in em(4) card before. Recently (I first noticed it >>>>>> on Jan >>>>>> 24) the card has stopped working several times. Nothing gets into >>>>>> the >>>>>> log file. Carrier is still detected properly but no data is >>>>>> exchanged. >>>>>> Ifconfig up/down doesn't help but kldunload/load does. When I run >>>>>> tcpdump I don't see any packet coming in but I see some outgoing. >>>>>> >>>>>> Can someone suggest what to look at when it happens the next time? I >>>>>> have DDB compiled in. I will try to sniff the wire using another >>>>>> machine >>>>>> next time to see if the card sends out anything. >>>>>> >>>>>> The command 'pciconf -lv' says about the card this: >>>>>> em0@pci2:1:0: class=0x020000 card=0x05491014 chip=0x101e8086 >>>>>> rev=0x03 >>>>>> hdr=0x00 >>>>>> vendor = 'Intel Corporation' >>>>>> device = '82540EP Gigabit Ethernet Controller (Mobile)' >>>>>> class = network >>>>>> subclass = ethernet >>>>>> >>>>>> The dmesg: >>>>>> em0: port >>>>>> 0x8000-0x803f mem 0xc0220000-0xc023ffff,0xc0200000-0xc020ffff irq >>>>>> 11 at >>>>>> device 1.0 on pci2 >>>>>> em0: Ethernet address: 00:0d:60:cd:ae:e2 >>>>>> em0: [FAST] >>>>>> >>>>>> The interrupt is shared since the machine is a notebook. I don't >>>>>> know if >>>>>> it was just a coincidence but I think that it happened at the >>>>>> same time >>>>>> as my USB mouse stopped working - the USB controller is on the >>>>>> same irq. >>>>>> >>>>>> Michal >>>>>> >>>>> >>>>> What is sharing the interrupt? >>>> >>>> >>>> >>>> vgapci0, ipw0, ehci0, uhci0-2. I don't think vgapci0 and ipw0 are >>>> really >>>> using the interrupt when I use em0. >>>> >>>> >>> >>> Ouch. For now, edit /sys/dev/em/if_em.c and add the following line >>> to the top of the file: >>> >>> #define NO_EM_FASTINTR >> >> >> >> Do you know the reason of the problem? Wouldn't it be better if I used >> stock driver and got some information for you when it doesn't work? I >> use the machine as my workstation so it isn't such a big problem when it >> looses the network. >> > > The problem is that the drivers that are sharing the interrupt, > particularly the USB ones, can spend a very very long time waiting on > locks to service the interrupt. During that time, the interrupt pin is > masked and the all interrupts from all shared devices don't get > delivered. So even though the if_em driver has a very fast interrupt > handler, it still has to wait on the USB drivers. During that wait, a > burst of network traffic might come into the card, filling its buffers > and triggering an overflow. This would be especially likely to happen > while the kernel is flushing out filesystem i/o. In theory the > interrupt service latency shouldn't be any different whether the if_em > driver is fast or not, but there might be coincidental timing issues > that I don't understand. That's why I'd like you to set the #ifdef in > the driver to revert it back to it's classic behaviour and see if the > problem persists. If it doesn't, then I'll have to rethink some of the > changes that I made to it. > > Scott > >> >>> Also, does your kernel config include the apic device? >> >> >> >> Yes, it does. But I believe that the chipset doesn't have it and neither >> the CPU supports it. >> >> Michal >> the big "workaround" that may save lives would be to have a "storm detection" that detects that an interrupt is not being reset, say, by noticing that the same interrupt has fired 32 times without ever giving the system a chance to even get out of the interrupt handling layer, and then on detection call the interrupt routine sof EVERY DRIVER that is registerred for interrupts. I have done similar to this on one of our machines where the redirected interrupt is being sent to the interrupt used by em4, when em0 gets delayed. My solution for this embedded hardware is to add a hack so that when em4 gets an interrupt and there isn't one, it goes and services all the other em devices as well. (remember this is for a particular hardware config so I can use non-general solutions).. Another way to achieve this would be to have a special driver that you register on the 'target' interrupt, that when run, calls the correct interrupt handlers :-) you could have a kernel module that you compile up with the correct two interrupts in it and on loading it would do the trick.. > > _______________________________________________ > 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 Feb 2 19:10:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 410DA16A420; Thu, 2 Feb 2006 19:10:21 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE1C543D46; Thu, 2 Feb 2006 19:10:20 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 02 Feb 2006 11:10:21 -0800 Message-ID: <43E2591C.6080501@elischer.org> Date: Thu, 02 Feb 2006 11:10:20 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200602011341.k11Dfbq1008941@lurza.secnetix.de> <200602011240.11682.jhb@freebsd.org> <43E117F3.9090400@elischer.org> <200602021337.15761.jhb@freebsd.org> In-Reply-To: <200602021337.15761.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Oliver Fromme Subject: Re: nextboot (was Re: boot block differences between 4.x and 6.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: Thu, 02 Feb 2006 19:10:21 -0000 John Baldwin wrote: >On Wednesday 01 February 2006 15:20, Julian Elischer wrote: > > >>John Baldwin wrote: >> >> >>>On Wednesday 01 February 2006 08:41, Oliver Fromme wrote: >>> >>> >>>>Julian Elischer wrote: >>>> >>>> >>>>>Oliver Fromme wrote: >>>>> >>>>> >>>>>>[...] >>>>>>I think the most visible changes in the boot blocks was >>>>>>UFS2 support and the removal of nextboot(8) support. >>>>>> >>>>>> >>>>>which I hope to put back because we continue to need it. >>>>> >>>>> >>>>I agree that it's needed. It's a very useful feature. >>>> >>>> >>>> >>>>>(The new nextboot being dependent on the root filesystem still being >>>>>ok which is unacceptable to most embedded devices I've worked on, and >>>>>why we still use the old bootblocks on all systems shipped.). >>>>> >>>>> >>>>> >>>>>From my point of view, the biggest problem with the old >>>> >>>>nextboot was the fact that it ignored loader(8) and tried >>>>to load the kernel directly. While that might work under >>>>certain conditions, it's not good in general. >>>> >>>>Therefore I think that a new nextboot implementation >>>>should be implemented in loader itself. Since loader(8) >>>>doesn't (and shouldn't) support writing to UFS2, the >>>>state information should be written to an unused area in >>>>block 2 on the disk, or something similar. In fact, one >>>>byte is sufficient: It can be used as an index into a >>>>table (ASCII text file), e.g. /boot/nextboot.conf. >>>> >>>>Would that be feasible to implement? >>>> >>>> >>>/boot/loader already does nextboot and does it by using UFS writing (which >>>it does implement and use on archs whose disk drivers support writing >>>such as i386) to overwrite (but not extend) /boot/nextboot.conf. >>> >>> >>which is exactly the feature that I wanted to avoid with the original >>nextboot(8). >>Do NOT get any where-to-boot-from info from the possibly suspect >>filesystem. Do NOT write back to the "possibly-suspect-filesystem". >> >>The original nextboot was BIOS specific and not portable which is why >>the new one >>has some good points (portable), but it didn't rely on correctness of the >>bootblock FS code or an intact first FS. >> >> > >You are already presuming something of an FS as that is where you get your >loader and kernel from. (Well, you could get the kernel from somewhere else >perhaps, but not the loader unless you are using PXE or a CD to boot.) > > I'm not presuming anything about a particular slice, if I can specify another one.. From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 19:44:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50FAC16A423 for ; Thu, 2 Feb 2006 19:44:20 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 945B943D68 for ; Thu, 2 Feb 2006 19:44:15 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 7582684 for multiple; Thu, 02 Feb 2006 14:44:43 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k12Ji2PY003692; Thu, 2 Feb 2006 14:44:03 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Julian Elischer Date: Thu, 2 Feb 2006 14:44:55 -0500 User-Agent: KMail/1.9.1 References: <200602011341.k11Dfbq1008941@lurza.secnetix.de> <200602021337.15761.jhb@freebsd.org> <43E2591C.6080501@elischer.org> In-Reply-To: <43E2591C.6080501@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602021444.57395.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1270/Thu Feb 2 07:47:37 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@freebsd.org, Oliver Fromme Subject: Re: nextboot (was Re: boot block differences between 4.x and 6.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: Thu, 02 Feb 2006 19:44:20 -0000 On Thursday 02 February 2006 14:10, Julian Elischer wrote: > John Baldwin wrote: > >On Wednesday 01 February 2006 15:20, Julian Elischer wrote: > >>John Baldwin wrote: > >>>On Wednesday 01 February 2006 08:41, Oliver Fromme wrote: > >>>>Julian Elischer wrote: > >>>>>Oliver Fromme wrote: > >>>>>>[...] > >>>>>>I think the most visible changes in the boot blocks was > >>>>>>UFS2 support and the removal of nextboot(8) support. > >>>>> > >>>>>which I hope to put back because we continue to need it. > >>>> > >>>>I agree that it's needed. It's a very useful feature. > >>>> > >>>>>(The new nextboot being dependent on the root filesystem still being > >>>>>ok which is unacceptable to most embedded devices I've worked on, and > >>>>>why we still use the old bootblocks on all systems shipped.). > >>>>> > >>>>> > >>>>> > >>>>>From my point of view, the biggest problem with the old > >>>> > >>>>nextboot was the fact that it ignored loader(8) and tried > >>>>to load the kernel directly. While that might work under > >>>>certain conditions, it's not good in general. > >>>> > >>>>Therefore I think that a new nextboot implementation > >>>>should be implemented in loader itself. Since loader(8) > >>>>doesn't (and shouldn't) support writing to UFS2, the > >>>>state information should be written to an unused area in > >>>>block 2 on the disk, or something similar. In fact, one > >>>>byte is sufficient: It can be used as an index into a > >>>>table (ASCII text file), e.g. /boot/nextboot.conf. > >>>> > >>>>Would that be feasible to implement? > >>> > >>>/boot/loader already does nextboot and does it by using UFS writing > >>> (which it does implement and use on archs whose disk drivers support > >>> writing such as i386) to overwrite (but not extend) > >>> /boot/nextboot.conf. > >> > >>which is exactly the feature that I wanted to avoid with the original > >>nextboot(8). > >>Do NOT get any where-to-boot-from info from the possibly suspect > >>filesystem. Do NOT write back to the "possibly-suspect-filesystem". > >> > >>The original nextboot was BIOS specific and not portable which is why > >>the new one > >>has some good points (portable), but it didn't rely on correctness of the > >>bootblock FS code or an intact first FS. > > > >You are already presuming something of an FS as that is where you get your > >loader and kernel from. (Well, you could get the kernel from somewhere > > else perhaps, but not the loader unless you are using PXE or a CD to > > boot.) > > I'm not presuming anything about a particular slice, if I can specify > another one.. The current nextboot stuff in the loader requires that /boot/loader is running (duh) and you have to have a place to get /boot/loader from. The same place you get /boot/loader from is the same place you are going to get /boot/nextboot.conf from (due to the way loader works). Thus, if you do it in loader(8) at all, you are assuming some minimal functionality about teh FS /boot/loader resides in, so requiring the same minimum for /boot/nextboot.conf is not really a stretch. The one exception to this is if you PXE boot and are using NFS to download the kernel then it will fetch nextboot.conf over NFS rather than using the tftp the BIOS used to download pxeboot (/boot/loader). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 20:20:50 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BFB316A423; Thu, 2 Feb 2006 20:20:50 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4806A43D6E; Thu, 2 Feb 2006 20:20:45 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id k12KKhkh068277; Thu, 2 Feb 2006 15:20:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id k12KKhHt035761; Thu, 2 Feb 2006 15:20:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BA3027302F; Thu, 2 Feb 2006 15:20:43 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060202202043.BA3027302F@freebsd-current.sentex.ca> Date: Thu, 2 Feb 2006 15:20:43 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 20:20:50 -0000 TB --- 2006-02-02 18:45:48 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-02-02 18:45:48 - starting HEAD tinderbox run for alpha/alpha TB --- 2006-02-02 18:45:48 - cleaning the object tree TB --- 2006-02-02 18:46:21 - checking out the source tree TB --- 2006-02-02 18:46:21 - cd /tinderbox/HEAD/alpha/alpha TB --- 2006-02-02 18:46:21 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-02-02 18:53:20 - building world (CFLAGS=-O2 -pipe) TB --- 2006-02-02 18:53:20 - cd /src TB --- 2006-02-02 18:53:20 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-02-02 19:59:03 - generating LINT kernel config TB --- 2006-02-02 19:59:03 - cd /src/sys/alpha/conf TB --- 2006-02-02 19:59:03 - /usr/bin/make -B LINT TB --- 2006-02-02 19:59:03 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-02-02 19:59:03 - cd /src TB --- 2006-02-02 19:59:03 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 2 19:59:03 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Feb 2 20:19:59 UTC 2006 TB --- 2006-02-02 20:19:59 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-02-02 20:19:59 - cd /src TB --- 2006-02-02 20:19:59 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Feb 2 20:19:59 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding In file included from /src/sys/net/pfil.h:39, from /src/sys/netinet/ip_fastfwd.c:90: /src/sys/sys/rwlock.h:140:2: #error LOCK_DEBUG not defined, include before In file included from /src/sys/net/pfil.h:39, from /src/sys/netinet/ip_input.c:54: /src/sys/sys/rwlock.h:140:2: #error LOCK_DEBUG not defined, include before mkdep: compile failed *** Error code 1 Stop in /obj/alpha/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-02-02 20:20:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-02-02 20:20:43 - ERROR: failed to build GENERIC kernel TB --- 2006-02-02 20:20:43 - tinderbox aborted TB --- 0.96 user 5.12 system 5695.55 real From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 22:21:25 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9FC716A420 for ; Thu, 2 Feb 2006 22:21:25 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4168F43D45 for ; Thu, 2 Feb 2006 22:21:25 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id k12MLOTt008836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Feb 2006 17:21:24 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k12MLI0o070669; Thu, 2 Feb 2006 17:21:18 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17378.34270.630897.473143@grasshopper.cs.duke.edu> Date: Thu, 2 Feb 2006 17:21:18 -0500 (EST) To: freebsd-current@www.freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: Subject: mapping "random" physical memory into kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 22:21:25 -0000 Can somebody please remind me what the supported way to establish a kernel virtual address for a "random" chunk of physical memory is? I'm currently using pmap_mapdev() directly, but that just feels dirty... I need to twiddle the settings of an Nvidia NF4 bridge in extended PCI config space (offset 0x178). These offsets are not accessible via normal pci config space writes, but are doable when you use the 0xe000000 mapping. The problem is that this memory is not really associated with anything, so a normal bus_alloc_resource() allocation doesn't seem like it would work. Thanks, Drew From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 22:33:20 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD28316A420 for ; Thu, 2 Feb 2006 22:33:20 +0000 (GMT) (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 328EF43D49 for ; Thu, 2 Feb 2006 22:33:18 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k12MX9I4043105; Thu, 2 Feb 2006 15:33:10 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43E288B0.6080804@samsco.org> Date: Thu, 02 Feb 2006 15:33:20 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Gallatin References: <17378.34270.630897.473143@grasshopper.cs.duke.edu> In-Reply-To: <17378.34270.630897.473143@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@www.freebsd.org Subject: Re: mapping "random" physical memory into kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 22:33:20 -0000 Andrew Gallatin wrote: > Can somebody please remind me what the supported way to establish a > kernel virtual address for a "random" chunk of physical memory is? > I'm currently using pmap_mapdev() directly, but that just feels > dirty... > > I need to twiddle the settings of an Nvidia NF4 bridge in extended > PCI config space (offset 0x178). These offsets are not accessible > via normal pci config space writes, but are doable when you use the > 0xe000000 mapping. Extended pci config space is supported by default on i386, but I haven't gotten around to figuring out the right strategy for amd64. I'd like to be able to map the entire 256MB range instead of the on-demand approach with i386, but I need to learn more about the various VM maps on amd64 first. > > The problem is that this memory is not really associated with > anything, so a normal bus_alloc_resource() allocation doesn't > seem like it would work. pmap_mapdev is the correct interface for this. Scott From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 22:36:51 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 906A616A420 for ; Thu, 2 Feb 2006 22:36:51 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEB8843D45 for ; Thu, 2 Feb 2006 22:36:50 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id k12Majxd012004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2006 17:36:45 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k12MaeOF070687; Thu, 2 Feb 2006 17:36:40 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17378.35192.656884.935489@grasshopper.cs.duke.edu> Date: Thu, 2 Feb 2006 17:36:40 -0500 (EST) To: Scott Long In-Reply-To: <43E288B0.6080804@samsco.org> References: <17378.34270.630897.473143@grasshopper.cs.duke.edu> <43E288B0.6080804@samsco.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-current@www.freebsd.org Subject: Re: mapping "random" physical memory into kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 22:36:51 -0000 Scott Long writes: > Andrew Gallatin wrote: > > Can somebody please remind me what the supported way to establish a > > kernel virtual address for a "random" chunk of physical memory is? > > I'm currently using pmap_mapdev() directly, but that just feels > > dirty... > > > > I need to twiddle the settings of an Nvidia NF4 bridge in extended > > PCI config space (offset 0x178). These offsets are not accessible > > via normal pci config space writes, but are doable when you use the > > 0xe000000 mapping. > > Extended pci config space is supported by default on i386, but I > haven't gotten around to figuring out the right strategy for > amd64. I'd like to be able to map the entire 256MB range instead > of the on-demand approach with i386, but I need to learn more about > the various VM maps on amd64 first. Cool. It would be great if it worked; I'd love to remove a bunch of grotty code ;) > > > > The problem is that this memory is not really associated with > > anything, so a normal bus_alloc_resource() allocation doesn't > > seem like it would work. > > pmap_mapdev is the correct interface for this. Except it doesn't appear to exist on sparc64. But I doubt we'd ever see an NF4 bridge there, so I suppose I can ifdef it for i386/amd64. Drew From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 22:39:34 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD5CD16A420 for ; Thu, 2 Feb 2006 22:39:34 +0000 (GMT) (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 D90E843D45 for ; Thu, 2 Feb 2006 22:39:33 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k12MdT7k043167; Thu, 2 Feb 2006 15:39:29 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43E28A2C.8000903@samsco.org> Date: Thu, 02 Feb 2006 15:39:40 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Gallatin References: <17378.34270.630897.473143@grasshopper.cs.duke.edu> <43E288B0.6080804@samsco.org> <17378.35192.656884.935489@grasshopper.cs.duke.edu> In-Reply-To: <17378.35192.656884.935489@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@www.freebsd.org Subject: Re: mapping "random" physical memory into kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 22:39:35 -0000 Andrew Gallatin wrote: > Scott Long writes: > > Andrew Gallatin wrote: > > > Can somebody please remind me what the supported way to establish a > > > kernel virtual address for a "random" chunk of physical memory is? > > > I'm currently using pmap_mapdev() directly, but that just feels > > > dirty... > > > > > > I need to twiddle the settings of an Nvidia NF4 bridge in extended > > > PCI config space (offset 0x178). These offsets are not accessible > > > via normal pci config space writes, but are doable when you use the > > > 0xe000000 mapping. > > > > Extended pci config space is supported by default on i386, but I > > haven't gotten around to figuring out the right strategy for > > amd64. I'd like to be able to map the entire 256MB range instead > > of the on-demand approach with i386, but I need to learn more about > > the various VM maps on amd64 first. > > Cool. It would be great if it worked; I'd love to remove > a bunch of grotty code ;) > If you, Peter, Alan, etc, have any suggestions, I'm all ears. > > > > > > The problem is that this memory is not really associated with > > > anything, so a normal bus_alloc_resource() allocation doesn't > > > seem like it would work. > > > > pmap_mapdev is the correct interface for this. > > Except it doesn't appear to exist on sparc64. But I doubt > we'd ever see an NF4 bridge there, so I suppose I can ifdef > it for i386/amd64. > > Drew > That's quite reasonable. Scott From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 23:30:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08DAB16A420 for ; Thu, 2 Feb 2006 23:30:01 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7208043D55 for ; Thu, 2 Feb 2006 23:29:59 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.3/8.13.1) with ESMTP id k12NTrEq019732 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 3 Feb 2006 00:29:58 +0100 (CET) (envelope-from mime@traveller.cz) From: Michal Mertl To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="=-EHgGsY+mVrGMXkzIh+ZU" Date: Fri, 03 Feb 2006 00:29:48 +0100 Message-Id: <1138922988.10456.29.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Subject: buglets with pts - with 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, 02 Feb 2006 23:30:01 -0000 --=-EHgGsY+mVrGMXkzIh+ZU Content-Type: text/plain Content-Transfer-Encoding: 7bit I found a couple of display issues with the new pts type ptys. wall and who - don't check the utmp tty validity (see also PR bin/84041) The attached patch duplicates the check from the w program in who and wall. For some reason closed pts ttys are displayed/printed to when there wasn't a problem with the old pty implementation. ps - the TT column displays garbage (always "pts") The attached patch trims "pts/" from the tty name. The printout doesn't look nice ("10443 pts IWs 0:00,00 bash" changes to "10443 3 IWs 0:00,00 bash") but the field width is 4 which doesn't allow much. The right solution would probably involve removing TT column and always use the longer version TTY with width of 8 (which allows to correctly display "pts/3"). I checked Solaris 10 and it displays the full tty name by default. Regards Michal --=-EHgGsY+mVrGMXkzIh+ZU Content-Disposition: attachment; filename=wall.diff Content-Type: text/x-patch; name=wall.diff; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Index: wall.c =================================================================== RCS file: /home/fcvs/cvs/src/usr.bin/wall/wall.c,v retrieving revision 1.23 diff -u -r1.23 wall.c --- wall.c 21 Feb 2003 08:46:44 -0000 1.23 +++ wall.c 2 Feb 2006 22:49:50 -0000 @@ -82,6 +82,19 @@ char *mbuf; int +ttystat(char *line, int sz) +{ + struct stat sb; + char ttybuf[MAXPATHLEN]; + + (void)snprintf(ttybuf, sizeof(ttybuf), "%s%.*s", _PATH_DEV, sz, line); + if (stat(ttybuf, &sb) == 0) { + return (0); + } else + return (-1); +} + +int main(int argc, char *argv[]) { struct iovec iov; @@ -140,6 +153,8 @@ while (fread((char *)&utmp, sizeof(utmp), 1, fp) == 1) { if (!utmp.ut_name[0]) continue; + if (ttystat(utmp.ut_line, UT_LINESIZE) != 0) + continue; if (grouplist) { ingroup = 0; strlcpy(username, utmp.ut_name, sizeof(utmp.ut_name)); --=-EHgGsY+mVrGMXkzIh+ZU Content-Disposition: attachment; filename=who.diff Content-Type: text/x-patch; name=who.diff; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Index: who.c =================================================================== RCS file: /home/fcvs/cvs/src/usr.bin/who/who.c,v retrieving revision 1.21 diff -u -r1.21 who.c --- who.c 29 May 2005 15:52:48 -0000 1.21 +++ who.c 2 Feb 2006 22:44:29 -0000 @@ -27,6 +27,7 @@ #include __FBSDID("$FreeBSD: src/usr.bin/who/who.c,v 1.21 2005/05/29 15:52:48 charnier Exp $"); +#include #include #include #include @@ -203,14 +204,31 @@ putchar('\n'); } +int +ttystat(char *line, int sz) +{ + struct stat sb; + char ttybuf[MAXPATHLEN]; + + (void)snprintf(ttybuf, sizeof(ttybuf), "%s%.*s", _PATH_DEV, sz, line); + if (stat(ttybuf, &sb) == 0) { + return (0); + } else + return (-1); +} + static void process_utmp(FILE *fp) { struct utmp ut; - while (fread(&ut, sizeof(ut), 1, fp) == 1) - if (*ut.ut_name != '\0') - row(&ut); + while (fread(&ut, sizeof(ut), 1, fp) == 1) { + if (*ut.ut_name == '\0') + continue; + if (ttystat(ut.ut_line, UT_LINESIZE) != 0) + continue; + row(&ut); + } } static void --=-EHgGsY+mVrGMXkzIh+ZU Content-Disposition: attachment; filename=ps.diff Content-Type: text/x-patch; name=ps.diff; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Index: print.c =================================================================== RCS file: /home/fcvs/cvs/src/bin/ps/print.c,v retrieving revision 1.93 diff -u -r1.93 print.c --- print.c 20 Jul 2004 05:52:00 -0000 1.93 +++ print.c 2 Feb 2006 23:05:07 -0000 @@ -366,6 +366,8 @@ if (strncmp(ttname, "tty", 3) == 0 || strncmp(ttname, "cua", 3) == 0) ttname += 3; + if (strncmp(ttname, "pts/", 4) == 0) + ttname += 4; (void)printf("%*.*s%c", v->width - 1, v->width - 1, ttname, k->ki_p->ki_kiflag & KI_CTTY ? ' ' : '-'); } --=-EHgGsY+mVrGMXkzIh+ZU-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 00:07:47 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3F4B16A422; Fri, 3 Feb 2006 00:07:47 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 465C243D49; Fri, 3 Feb 2006 00:07:47 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id k1307kOa031070; Thu, 2 Feb 2006 19:07:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4/8.13.4) with ESMTP id k1307xTU094286; Thu, 2 Feb 2006 19:07:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 064527302F; Thu, 2 Feb 2006 19:07:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060203000745.064527302F@freebsd-current.sentex.ca> Date: Thu, 2 Feb 2006 19:07:45 -0500 (EST) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2006 00:07:48 -0000 TB --- 2006-02-02 22:39:20 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-02-02 22:39:20 - starting HEAD tinderbox run for i386/i386 TB --- 2006-02-02 22:39:20 - cleaning the object tree TB --- 2006-02-02 22:39:53 - checking out the source tree TB --- 2006-02-02 22:39:53 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-02-02 22:39:53 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-02-02 22:46:54 - building world (CFLAGS=-O2 -pipe) TB --- 2006-02-02 22:46:54 - cd /src TB --- 2006-02-02 22:46:54 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-02-02 23:52:45 - generating LINT kernel config TB --- 2006-02-02 23:52:45 - cd /src/sys/i386/conf TB --- 2006-02-02 23:52:45 - /usr/bin/make -B LINT TB --- 2006-02-02 23:52:45 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-02-02 23:52:45 - cd /src TB --- 2006-02-02 23:52:45 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 2 23:52:45 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] isp_target.o(.text+0x16bd): In function `isp_target_notify': : undefined reference to `isp_get_atio2e' isp_target.o(.text+0x16ca): In function `isp_target_notify': : undefined reference to `isp_get_ctio2e' isp_target.o(.text+0x175e): In function `isp_target_notify': : undefined reference to `isp_get_notify_ack' isp_target.o(.text+0x1790): In function `isp_target_notify': : undefined reference to `isp_get_notify' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-02-03 00:07:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-02-03 00:07:45 - ERROR: failed to build lint kernel TB --- 2006-02-03 00:07:45 - tinderbox aborted TB --- 1.25 user 5.54 system 5305.72 real From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 01:01:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D9BC16A420 for ; Fri, 3 Feb 2006 01:01:14 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id A78B843D48 for ; Fri, 3 Feb 2006 01:01:13 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by pproxy.gmail.com with SMTP id i49so111909pye for ; Thu, 02 Feb 2006 17:01:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qhWcMBYopgrKPnaeQ4fH6NxFydMbDPdxQR/M/ZAsE5hsNr9B4HUMdiI9c5LDmJrSmBH/GGBCUFgcyyBFLsE3fSQyjYX1MNS0K4uc7ia0aX1mM37wynib8qQKJvvxadmypWrf+vrL1CgriUqSSuQuD/DhDChMvfNZcJC2IDU/j2s= Received: by 10.35.127.7 with SMTP id e7mr36968pyn; Thu, 02 Feb 2006 17:01:12 -0800 (PST) Received: by 10.35.28.4 with HTTP; Thu, 2 Feb 2006 17:01:12 -0800 (PST) Message-ID: <2a41acea0602021701o20d66381t6c3979d7826d956a@mail.gmail.com> Date: Thu, 2 Feb 2006 17:01:12 -0800 From: Jack Vogel To: Julian Elischer In-Reply-To: <43E256DD.1030504@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1138813174.1358.34.camel@genius.i.cz> <43E0FE09.50804@samsco.org> <1138875351.1807.12.camel@genius.i.cz> <43E203F9.9060307@samsco.org> <1138890130.9192.3.camel@genius.i.cz> <43E2184B.3040606@samsco.org> <43E256DD.1030504@elischer.org> Cc: Michal Mertl , freebsd-current@freebsd.org Subject: Re: em(4) stops forwarding X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Feb 2006 01:01:14 -0000 On 2/2/06, Julian Elischer wrote: > > the big "workaround" that may save lives would be to have a "storm > detection" that detects that > an interrupt is not being reset, say, by noticing that the same > interrupt has fired 32 times without > ever giving the system a chance to even get out of the interrupt > handling layer, > and then on detection call the interrupt routine sof EVERY DRIVER that > is registerred > for interrupts. > > I have done similar to this on one of our machines where the redirected > interrupt is being sent > to the interrupt used by em4, when em0 gets delayed. > > My solution for this embedded hardware is to add a hack so that when em4 > gets an interrupt and there > isn't one, it goes and services all the other em devices as well. > (remember this is for a particular hardware config so I can use > non-general solutions).. > > Another way to achieve this would be to have a special driver that you > register on the 'target' > interrupt, that when run, calls the correct interrupt handlers :-) > you could have a kernel module that you compile up with the correct two > interrupts in it > and on loading it would do the trick.. I have a feeling that the real fix is something down in the bottom half of the kernel where interrupt routing is set up. I think something is wonky down there on some new chip sets, but I'm not sure without more research. Anyone else looking at that perhaps? Jack From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 01:19:42 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55F8D16A420; Fri, 3 Feb 2006 01:19:42 +0000 (GMT) (envelope-from dougb@freebsd.org) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.200.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id C710043D45; Fri, 3 Feb 2006 01:19:41 +0000 (GMT) (envelope-from dougb@freebsd.org) Received: from [192.168.0.3] (c-24-130-213-251.hsd1.ca.comcast.net[24.130.213.251]) by comcast.net (sccrmhc11) with ESMTP id <20060203011934011004jbqbe>; Fri, 3 Feb 2006 01:19:37 +0000 Message-ID: <43E2AFA5.5000205@FreeBSD.org> Date: Thu, 02 Feb 2006 17:19:33 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Robert Watson References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> <43E14C53.3060400@rogers.com> <20060202004044.GA99245@xor.obsecurity.org> <20060202004845.C87763@fledge.watson.org> In-Reply-To: <20060202004845.C87763@fledge.watson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mike Jakubik , K?vesd?n G?bor , current@FreeBSD.org, trustedbsd-audit@TrustedBSD.org, Kris Kennaway Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Feb 2006 01:19:42 -0000 Robert Watson wrote: > > On Wed, 1 Feb 2006, Kris Kennaway wrote: > >>> Personally, i would like to see less "experimental" code in 6.1. >>> Perhaps it would be better to wait until everyone feels the code is >>> ready? >> >> Why do you care if code that is not enabled by default is present in >> the system? :-) > > Well, I think there are some potential risks. The main ones are: > > (1) That the unconditionally compiled bits cause problems. Primarily > this is > the audit support in login, sshd, etc. Apple has been running with > basically the same code for a couple of years now, but there is always > risk in change. > > (2) Risk to users who do try the experimental support and run into bugs, or > run into things that we will change for a 6.2 release as we fix > problems. I was with you right up until that last bit. Given that we are changing the release model to time-based releases as opposed to feature-based, the "danger" that we'll go a long time without users having access to new features is significantly lowered. Therefore, IMO we need to be even more careful about making sure that -stable branches stay stable; including A[BP]I issues. No matter how carefully we label something as "early adopter," etc; users of -stable are still going to complain if something they come to count on changes out from under them, and I have a lot of sympathy for that argument. My vote would be to leave it in HEAD until it's thoroughly cooked, then make the decision to MFC or not based on how close we are to 7-RELEASE. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 01:32:53 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4069B16A420; Fri, 3 Feb 2006 01:32:53 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B218243D46; Fri, 3 Feb 2006 01:32:52 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id k131Wpua001311; Thu, 2 Feb 2006 20:32:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4/8.13.4) with ESMTP id k131X47Z031443; Thu, 2 Feb 2006 20:33:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 705D07302F; Thu, 2 Feb 2006 20:32:51 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060203013251.705D07302F@freebsd-current.sentex.ca> Date: Thu, 2 Feb 2006 20:32:51 -0500 (EST) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2006 01:32:53 -0000 TB --- 2006-02-03 00:07:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-02-03 00:07:46 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-02-03 00:07:46 - cleaning the object tree TB --- 2006-02-03 00:08:14 - checking out the source tree TB --- 2006-02-03 00:08:14 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-02-03 00:08:14 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-02-03 00:14:54 - building world (CFLAGS=-O2 -pipe) TB --- 2006-02-03 00:14:54 - cd /src TB --- 2006-02-03 00:14:54 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-02-03 01:19:44 - generating LINT kernel config TB --- 2006-02-03 01:19:44 - cd /src/sys/pc98/conf TB --- 2006-02-03 01:19:44 - /usr/bin/make -B LINT TB --- 2006-02-03 01:19:45 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-02-03 01:19:45 - cd /src TB --- 2006-02-03 01:19:45 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 3 01:19:45 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] isp_target.o(.text+0x16bd): In function `isp_target_notify': : undefined reference to `isp_get_atio2e' isp_target.o(.text+0x16ca): In function `isp_target_notify': : undefined reference to `isp_get_ctio2e' isp_target.o(.text+0x175e): In function `isp_target_notify': : undefined reference to `isp_get_notify_ack' isp_target.o(.text+0x1790): In function `isp_target_notify': : undefined reference to `isp_get_notify' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-02-03 01:32:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-02-03 01:32:51 - ERROR: failed to build lint kernel TB --- 2006-02-03 01:32:51 - tinderbox aborted TB --- 1.12 user 5.53 system 5105.03 real From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 02:50:37 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35BC216A420 for ; Fri, 3 Feb 2006 02:50:37 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D4E643D48 for ; Fri, 3 Feb 2006 02:50:36 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so364321wxc for ; Thu, 02 Feb 2006 18:50:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=azbkghujGdgS8IUyC4lKbZ6p9SLJffBmm9VdgWBYxdIq5lLfSbCypp7N3Rmg4aM8BIN8bUfp2woVxXDmZCMdHWgHXrj8/m6AZc6YIjeX6QT5IoO8EZzyctuU1pMJo0+pwL8FJXFIvFmuaUUFkiUVwavbFNXBX9zCtB2+H6+aKX0= Received: by 10.70.124.19 with SMTP id w19mr1604214wxc; Thu, 02 Feb 2006 18:50:32 -0800 (PST) Received: by 10.70.105.2 with HTTP; Thu, 2 Feb 2006 18:50:32 -0800 (PST) Message-ID: <84dead720602021850r440cd74bh51f2a8af135defc6@mail.gmail.com> Date: Fri, 3 Feb 2006 08:20:32 +0530 From: Joseph Koshy To: Andrew Gallatin In-Reply-To: <17378.19400.856354.995643@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17378.19400.856354.995643@grasshopper.cs.duke.edu> Cc: freebsd-current@freebsd.org Subject: Re: hwpmc & kernel modules? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Feb 2006 02:50:37 -0000 ag> Is there any way to profile kernel modules with hwpmc? It Not yet. We collect samples and transfer them to the log, but the log->gprof conversion tools do not know how to map the samples falling inside dynamically loaded objects. Supporting kernel modules (and dynamically loaded userland objects) is on my todo list. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 01:05:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0029916A420 for ; Fri, 3 Feb 2006 01:05:09 +0000 (GMT) (envelope-from scottl@pooker.samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F4E543D45 for ; Fri, 3 Feb 2006 01:05:09 +0000 (GMT) (envelope-from scottl@pooker.samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k13153It044033; Thu, 2 Feb 2006 18:05:03 -0700 (MST) (envelope-from scottl@pooker.samsco.org) Date: Thu, 2 Feb 2006 18:05:03 -0700 (MST) From: Scott Long To: Jack Vogel In-Reply-To: <2a41acea0602021701o20d66381t6c3979d7826d956a@mail.gmail.com> Message-ID: <20060202180247.M10747@pooker.samsco.org> References: <1138813174.1358.34.camel@genius.i.cz> <43E0FE09.50804@samsco.org> <1138875351.1807.12.camel@genius.i.cz> <43E203F9.9060307@samsco.org> <1138890130.9192.3.camel@genius.i.cz> <43E2184B.3040606@samsco.org> <43E256DD.1030504@elischer.org> <2a41acea0602021701o20d66381t6c3979d7826d956a@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org X-Mailman-Approved-At: Fri, 03 Feb 2006 05:26:17 +0000 Cc: Michal Mertl , Julian Elischer , freebsd-current@freebsd.org Subject: Re: em(4) stops forwarding X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Feb 2006 01:05:10 -0000 On Thu, 2 Feb 2006, Jack Vogel wrote: > On 2/2/06, Julian Elischer wrote: >> >> the big "workaround" that may save lives would be to have a "storm >> detection" that detects that >> an interrupt is not being reset, say, by noticing that the same >> interrupt has fired 32 times without >> ever giving the system a chance to even get out of the interrupt >> handling layer, >> and then on detection call the interrupt routine sof EVERY DRIVER that >> is registerred >> for interrupts. >> >> I have done similar to this on one of our machines where the redirected >> interrupt is being sent >> to the interrupt used by em4, when em0 gets delayed. >> >> My solution for this embedded hardware is to add a hack so that when em4 >> gets an interrupt and there >> isn't one, it goes and services all the other em devices as well. >> (remember this is for a particular hardware config so I can use >> non-general solutions).. >> >> Another way to achieve this would be to have a special driver that you >> register on the 'target' >> interrupt, that when run, calls the correct interrupt handlers :-) >> you could have a kernel module that you compile up with the correct two >> interrupts in it >> and on loading it would do the trick.. > > I have a feeling that the real fix is something down in the bottom half of > the kernel where interrupt routing is set up. I think something is wonky > down there on some new chip sets, but I'm not sure without more > research. Anyone else looking at that perhaps? > > Jack > It's quite common for laptop motherboard makers to route lots of interrupts onto the same physical line. It saves a small fraction of a penny in costs. My last Dell notebook was that way, regardless of Windows, Linux, or FreeBSD. Scott From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 10:01:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17BFB16A420 for ; Fri, 3 Feb 2006 10:01:48 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32E6E43D53 for ; Fri, 3 Feb 2006 10:01:36 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.3/8.13.1) with ESMTP id k13A1YMt032483 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 3 Feb 2006 11:01:35 +0100 (CET) (envelope-from mime@traveller.cz) From: Michal Mertl To: freebsd-current@freebsd.org In-Reply-To: <1138922988.10456.29.camel@genius.i.cz> References: <1138922988.10456.29.camel@genius.i.cz> Content-Type: text/plain; charset=ISO-8859-2 Date: Fri, 03 Feb 2006 11:01:28 +0100 Message-Id: <1138960889.17667.33.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Subject: Re: buglets with pts - with 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, 03 Feb 2006 10:01:48 -0000 Michal Mertl pí¹e v pá 03. 02. 2006 v 00:29 +0100: > I found a couple of display issues with the new pts type ptys. > > wall and who - don't check the utmp tty validity (see also PR bin/84041) > The attached patch duplicates the check from the w program in who and > wall. For some reason closed pts ttys are displayed/printed to when > there wasn't a problem with the old pty implementation. I forgot to properly describe the bug :-). who and wall displays/prints to already detached pty. E.g. I open an gnome-terminal window and close it. Then when I call who in another window the just closed pty is listed as active. Example: ------ mime@genius /usr/home/mime$ who mime pts/1 1 úno 18:50 (:0.0) mime pts/2 2 úno 01:54 (:0.0) mime pts/3 2 úno 16:06 (:0.0) mime pts/4 2 úno 16:44 (:0.0) mime pts/5 2 úno 23:21 (:0.0) mime :0 1 úno 18:46 ------ mime@genius /usr/home/mime$ wall a Broadcast Message from mime@genius... (/dev/pts/4) at 10:20 CET... a wall: /dev/pts/5: No such file or directory wall: /dev/:0: No such file or directory ---- "w" is correct: ------ mime@genius /usr/home/mime$ w 10:20dp up 1 day, 9:26, 4 users, load averages: 0,98 0,45 0,38 USER TTY FROM LOGIN@ IDLE WHAT mime pts/1 :0.0 st06od 31 bash mime pts/2 :0.0 èt01dp 31 ssh .. mime pts/3 :0.0 èt04od 51 [ssh] mime pts/4 :0.0 èt04od - w ------ I also have just confirmed there is also one more bug - I don't see all the ptys - I probably didn't investigate it enough but it seems that pts/0 is never displayed by w, who or wall. It is correct is last output though and ps also shows the processes running on it. I think that whatever writes to /var/tmp/utmp doesn't write pts/0 lines to it (so w, who and wall don't see it) but they are written correctly to /var/log/wtmp (so last sees it). I see now that the patches I sent out aren't a complete solution too all the issues. I will continue looking into it. > > ps - the TT column displays garbage (always "pts") > The attached patch trims "pts/" from the tty name. The printout doesn't > look nice ("10443 pts IWs 0:00,00 bash" changes to "10443 3 IWs > 0:00,00 bash") but the field width is 4 which doesn't allow much. The > right solution would probably involve removing TT column and always use > the longer version TTY with width of 8 (which allows to correctly > display "pts/3"). I checked Solaris 10 and it displays the full tty name > by default. > > Regards > > Michal From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 10:39:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2393216A420 for ; Fri, 3 Feb 2006 10:39:16 +0000 (GMT) (envelope-from gb@isis.u-strasbg.fr) Received: from chimie.u-strasbg.fr (chimie.u-strasbg.fr [130.79.40.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83A0843D4C for ; Fri, 3 Feb 2006 10:39:14 +0000 (GMT) (envelope-from gb@isis.u-strasbg.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by chimie.u-strasbg.fr (Postfix) with ESMTP id 9B8406DD08 for ; Fri, 3 Feb 2006 11:39:13 +0100 (CET) Received: from chimie.u-strasbg.fr ([127.0.0.1]) by localhost (chimie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16782-06 for ; Fri, 3 Feb 2006 11:39:13 +0100 (CET) Received: from 6nq.u-strasbg.fr (chimie.u-strasbg.fr [130.79.40.6]) by chimie.u-strasbg.fr (Postfix) with ESMTP id BDE376DD0F for ; Fri, 3 Feb 2006 11:37:42 +0100 (CET) Received: by 6nq.u-strasbg.fr (Postfix, from userid 1001) id 3EE486145; Fri, 3 Feb 2006 11:35:54 +0100 (CET) Date: Fri, 3 Feb 2006 11:35:54 +0100 From: Guy Brand To: freebsd-current@freebsd.org Message-ID: <20060203103553.GC1038@chimie.u-strasbg.fr> References: <1b62a7390602011159l6c43827ei31e25e2d315185a3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1b62a7390602011159l6c43827ei31e25e2d315185a3@mail.gmail.com> x-gpg-fingerprint: B423 4924 012E 52F3 BA9E 547F CC8C 0BC5 9C0E B1CA x-gpg-key: 9C0EB1CA User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at chimie.u-strasbg.fr Subject: Re: For the love of God, is it even possible to make the Atheros ath.patch & updated HAL actually work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2006 10:39:16 -0000 On 01 february at 14:59, Ryan R wrote: > I have been racking my brain for DAYS trying to get Sam Leffler's ( > http://people.freebsd.org/~sam ) ath.patch and updated HAL binary to work in > *ANY* version of FreeBSD. > [...] > > Does anybody have even the slightest clue when this code may actually make > it into the kernel sources? Or better yet, does the patch cleanly apply and > compile for ANYBODY? It seems that I could be member of this ANYBODY: FreeBSD 6.1-PRERELEASE #5: Fri Feb 3 09:13:13 CET 2006 ath_hal: 0.9.16.13 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413, DFS) ath0: mem 0xfe710000-0xfe71ffff at device 0.0 on cardbus1 ath0@pci4:0:0: class=0x020000 card=0x6804a727 chip=0x001b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' That's a 3CRPAG175B 3com card and it works for me with Sam's patch adapted for RELENG_6. I can send it to you if you want, but it would be wiser to wait for Sam's new and clean patches. -- gb From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 13:03:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ACF416A423 for ; Fri, 3 Feb 2006 13:03:30 +0000 (GMT) (envelope-from michal.mertl@i.cz) Received: from vidle.i.cz (vidle.i.cz [193.179.36.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF81043D5C for ; Fri, 3 Feb 2006 13:03:29 +0000 (GMT) (envelope-from michal.mertl@i.cz) Received: from ns.i.cz (brana.i.cz [193.179.36.134]) by vidle.i.cz (Postfix) with ESMTP id 906BF2E009 for ; Fri, 3 Feb 2006 14:03:28 +0100 (CET) Received: from localhost (localhost.i.cz [127.0.0.1]) by ns.i.cz (Postfix) with SMTP id 7352E122A03 for ; Fri, 3 Feb 2006 14:03:28 +0100 (CET) X-AV-Checked: Fri Feb 3 14:03:28 2006 ns.i.cz Received: from genius.i.cz (genius.i.cz [192.168.129.68]) by ns.i.cz (Postfix) with ESMTP id 6D773122A02 for ; Fri, 3 Feb 2006 14:03:28 +0100 (CET) From: Michal Mertl To: freebsd-current@freebsd.org In-Reply-To: <1138960889.17667.33.camel@genius.i.cz> References: <1138922988.10456.29.camel@genius.i.cz> <1138960889.17667.33.camel@genius.i.cz> Content-Type: text/plain; charset=ISO-8859-2 Date: Fri, 03 Feb 2006 14:03:21 +0100 Message-Id: <1138971802.18879.5.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 03 Feb 2006 13:06:23 +0000 Subject: Re: buglets with pts - with 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, 03 Feb 2006 13:03:30 -0000 Michal Mertl pí¹e v pá 03. 02. 2006 v 11:01 +0100: > Michal Mertl pí¹e v pá 03. 02. 2006 v 00:29 +0100: > I also have just confirmed there is also one more bug - I don't see all > the ptys - I probably didn't investigate it enough but it seems that > pts/0 is never displayed by w, who or wall. It is correct is last output > though and ps also shows the processes running on it. I think that > whatever writes to /var/tmp/utmp doesn't write pts/0 lines to it (so w, > who and wall don't see it) but they are written correctly > to /var/log/wtmp (so last sees it). I found out that when I login through sshd who displays pts/0 correctly. I also found that even last shows incorrectly whether I am still logged in or not when pty is allocated with gnome-terminal or xterm. Michal From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 15:51:08 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86F1416A420 for ; Fri, 3 Feb 2006 15:51:08 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4100F43D5E for ; Fri, 3 Feb 2006 15:51:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9241A46CAA; Fri, 3 Feb 2006 10:50:53 -0500 (EST) Date: Fri, 3 Feb 2006 15:53:09 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org In-Reply-To: <20060201221213.L87763@fledge.watson.org> Message-ID: <20060203144824.W77426@fledge.watson.org> References: <20060201221213.L87763@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-audit@TrustedBSD.org Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Feb 2006 15:51:08 -0000 On Wed, 1 Feb 2006, Robert Watson wrote: > As Wayne and I are in the process of merging the TrustedBSD audit3 branch > contents into the FreeBSD CVS HEAD (7-CURRENT), there may be periods where > the tree is (hopefully briefly) unbuildable. This integration process will > take a couple of days to complete, due to the scope of the changes. So far, > the kernel audit framework has been committed (src/sys/security/audit), as > has an initial vendor import of OpenBSM for user space > (src/contrib/openbsm). What remains to be committed are the substantial > changes to gather audit data in system calls, the mappings of system calls > to audit events, and integration into the user space build and user space > applications (such as login). These bits are the trickier bits as the > patches are large and touch a lot of parts of the tree. > > I'll send out follow-up e-mail once the worst is past, along with > information on what it all means, and how to try it out (for those not > already on trustedbsd-audit, who have been hearing about this for a while). FYI, the current status is that the merge is continuing. So far we have merged: - OpenBSM library, commands, man pages, include files, etc. - sys/security/audit audit event management framework - etc/rc.d boot script, makefiles - Mapping of FreeBSD native system calls to audit events. To go are: - Mappings of non-native system calls to audit events. - Auditing of system call arguments. - Submission of audit records by user space components. So there are now enough pieces in the tree to configure auditing and see basic ../../../security/audit/audit_bsm_token.c system call traces. More to follow in the next couple of days. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 21:15:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6B6016A420; Fri, 3 Feb 2006 21:15:21 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7692D43D45; Fri, 3 Feb 2006 21:15:19 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id k13LFIJl002278; Fri, 3 Feb 2006 16:15:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4/8.13.4) with ESMTP id k13LFUbv023328; Fri, 3 Feb 2006 16:15:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A834A7302F; Fri, 3 Feb 2006 16:15:17 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060203211517.A834A7302F@freebsd-current.sentex.ca> Date: Fri, 3 Feb 2006 16:15:17 -0500 (EST) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2006 21:15:22 -0000 TB --- 2006-02-03 19:50:24 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-02-03 19:50:24 - starting HEAD tinderbox run for alpha/alpha TB --- 2006-02-03 19:50:24 - cleaning the object tree TB --- 2006-02-03 19:50:54 - checking out the source tree TB --- 2006-02-03 19:50:54 - cd /tinderbox/HEAD/alpha/alpha TB --- 2006-02-03 19:50:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-02-03 19:57:53 - building world (CFLAGS=-O2 -pipe) TB --- 2006-02-03 19:57:53 - cd /src TB --- 2006-02-03 19:57:53 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-02-03 21:03:49 - generating LINT kernel config TB --- 2006-02-03 21:03:49 - cd /src/sys/alpha/conf TB --- 2006-02-03 21:03:49 - /usr/bin/make -B LINT TB --- 2006-02-03 21:03:50 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-02-03 21:03:50 - cd /src TB --- 2006-02-03 21:03:50 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 3 21:03:50 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/posix4/ksched.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/posix4/p1003_1b.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/posix4/posix4_mib.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/rpc/rpcclnt.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/security/audit/audit_arg.c /src/sys/security/audit/audit_arg.c: In function `audit_arg_upath': /src/sys/security/audit/audit_arg.c:676: warning: long long unsigned int format, u_int64_t arg (arg 2) /src/sys/security/audit/audit_arg.c:678: warning: long long unsigned int format, u_int64_t arg (arg 2) *** Error code 1 Stop in /obj/alpha/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-02-03 21:15:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-02-03 21:15:17 - ERROR: failed to build lint kernel TB --- 2006-02-03 21:15:17 - tinderbox aborted TB --- 0.83 user 4.57 system 5093.07 real From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 21:25:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF24716A420 for ; Fri, 3 Feb 2006 21:25:24 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42BA943D5A for ; Fri, 3 Feb 2006 21:25:17 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id E89CC5E48EE; Fri, 3 Feb 2006 13:25:16 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 890435E48E5 for ; Fri, 3 Feb 2006 13:25:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <7A70B364-75C8-4522-9CFC-1448DBFD853E@freebsd.org> References: <7A70B364-75C8-4522-9CFC-1448DBFD853E@freebsd.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9499E90B-39FD-443E-8864-E9034902AFAF@freebsd.org> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Fri, 3 Feb 2006 13:25:14 -0800 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Subject: Re: subdisk6: detached --> Fatal trap 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Feb 2006 21:25:24 -0000 On Feb 1, 2006, at 2:09 PM, Jason Evans wrote: > Initially, installation went fine using snapshot 012 from > ftp.freebsd.org. However, once the system is up and running, > within minutes of loading the filesystem with a cvsup or cvs > checkout, I get errors something like: > > subdisk6: detached > g_vfs_done():ad6s1f[WRITE(offset=10217842688, length=2048)]error = 6 > ad6: detached > Fatal trap 9 [...] > g_vfs_done():[12-15 more messages like the one above.] This turned out to be due to a flaky SATA cable connector. The machine has been totally solid since replacing the cable. Jason From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 22:47:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E6F016A420 for ; Fri, 3 Feb 2006 22:47:41 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7EE943D46 for ; Fri, 3 Feb 2006 22:47:38 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id k13MlbC1025430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Feb 2006 17:47:37 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k13MlW9U077914; Fri, 3 Feb 2006 17:47:32 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17379.56708.421007.613310@grasshopper.cs.duke.edu> Date: Fri, 3 Feb 2006 17:47:32 -0500 (EST) To: freebsd-current@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Subject: machdep.cpu_idle_hlt and SMP perf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Feb 2006 22:47:41 -0000 Why dooes machdep.cpu_idle_hlt=1 drop my 10GbE network rx performance by a considerable amount (7.5Gbs -> 5.5Gbs)? I've (blindly) tried leaving machdep.cpu_idle_hlt=1 enabled and playing with the vast array of kern.sched.ipiwakeup.* sysctls, but receive performance remains limited to ~5.5Gb/sec or less. This is an 'AMD Athlon(tm) 64 X2 Dual Core Processor 3800+' running FreeBSD-current as of about one week ago. The interrupt load is about 22,000 device interrupts/sec (ithreaded). Interestingly, the more I decrease the interrupt load by increasing the interrupt coalescing timer, the worse the machdep.cpu_idle_hlt=1 case does. Is this just a case of the wakeup IPI taking a long time or blocking on some lock? Drew PS: Here is what I mean: rome% ssh venice-my netperf224 -Hrome-my -tTCP_SENDFILE -F /boot/vmlinuz-2.6.9-11.EL -- -S 131072 TCP SENDFILE TEST to rome-my Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 131072 65536 65536 10.00 5460.73 rome% sudo sysctl machdep.cpu_idle_hlt=0 machdep.cpu_idle_hlt: 1 -> 0 rome% ssh venice-my netperf224 -Hrome-my -tTCP_SENDFILE -F /boot/vmlinuz-2.6.9-11.EL -- -S 131072 TCP SENDFILE TEST to rome-my Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 131072 65536 65536 10.00 7842.41 From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 22:51:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96E3016A420 for ; Fri, 3 Feb 2006 22:51:15 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5339E43D46 for ; Fri, 3 Feb 2006 22:51:15 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 304121A3C1F; Fri, 3 Feb 2006 14:51:15 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 75B5454B5F; Fri, 3 Feb 2006 17:51:14 -0500 (EST) Date: Fri, 3 Feb 2006 17:51:14 -0500 From: Kris Kennaway To: Andrew Gallatin Message-ID: <20060203225114.GA9845@xor.obsecurity.org> References: <17379.56708.421007.613310@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <17379.56708.421007.613310@grasshopper.cs.duke.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: machdep.cpu_idle_hlt and SMP perf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Feb 2006 22:51:15 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 03, 2006 at 05:47:32PM -0500, Andrew Gallatin wrote: >=20 > Why dooes machdep.cpu_idle_hlt=3D1 drop my 10GbE network rx > performance by a considerable amount (7.5Gbs -> 5.5Gbs)? I don't know, but I've set this to 0 on my machines because I also noticed a significant performance drop on general workloads with it set to 1. Kris --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD495iWry0BWjoQKURAnuYAKDuYnmj/z5HBk5WoTrI39GjyKOdNQCeMk8X pURIPg/GUVQOdHc3wtetsYo= =YSkR -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 22:53:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C35FD16A420 for ; Fri, 3 Feb 2006 22:53:29 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5165043D45 for ; Fri, 3 Feb 2006 22:53:29 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id k13MrOFK026741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Feb 2006 17:53:24 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k13MrJ9R077926; Fri, 3 Feb 2006 17:53:19 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17379.57055.535149.295156@grasshopper.cs.duke.edu> Date: Fri, 3 Feb 2006 17:53:19 -0500 (EST) To: Kris Kennaway In-Reply-To: <20060203225114.GA9845@xor.obsecurity.org> References: <17379.56708.421007.613310@grasshopper.cs.duke.edu> <20060203225114.GA9845@xor.obsecurity.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-current@freebsd.org Subject: Re: machdep.cpu_idle_hlt and SMP perf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Feb 2006 22:53:29 -0000 Kris Kennaway writes: > On Fri, Feb 03, 2006 at 05:47:32PM -0500, Andrew Gallatin wrote: > > > > Why dooes machdep.cpu_idle_hlt=1 drop my 10GbE network rx > > performance by a considerable amount (7.5Gbs -> 5.5Gbs)? > > I don't know, but I've set this to 0 on my machines because I also > noticed a significant performance drop on general workloads with it > set to 1. I think I'll follow your lead. Good thing there is a cold snap coming ;) Drew From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 23:07:58 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A23616A420; Fri, 3 Feb 2006 23:07:58 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7489243D46; Fri, 3 Feb 2006 23:07:57 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id k13N7uic060225; Fri, 3 Feb 2006 18:07:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id k13N7tUG038402; Fri, 3 Feb 2006 18:07:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B8CA57302F; Fri, 3 Feb 2006 18:07:55 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060203230755.B8CA57302F@freebsd-current.sentex.ca> Date: Fri, 3 Feb 2006 18:07:55 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2006 23:07:58 -0000 TB --- 2006-02-03 21:15:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-02-03 21:15:17 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-02-03 21:15:17 - cleaning the object tree TB --- 2006-02-03 21:15:55 - checking out the source tree TB --- 2006-02-03 21:15:55 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-02-03 21:15:55 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-02-03 21:23:09 - building world (CFLAGS=-O2 -pipe) TB --- 2006-02-03 21:23:09 - cd /src TB --- 2006-02-03 21:23:09 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2006-02-03 22:55:48 - generating LINT kernel config TB --- 2006-02-03 22:55:48 - cd /src/sys/amd64/conf TB --- 2006-02-03 22:55:48 - /usr/bin/make -B LINT TB --- 2006-02-03 22:55:48 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-02-03 22:55:48 - cd /src TB --- 2006-02-03 22:55:48 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 3 22:55:48 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/posix4/ksched.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/posix4/p1003_1b.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/posix4/posix4_mib.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/rpc/rpcclnt.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/security/audit/audit_arg.c /src/sys/security/audit/audit_arg.c: In function `audit_arg_upath': /src/sys/security/audit/audit_arg.c:676: warning: long long unsigned int format, u_int64_t arg (arg 2) /src/sys/security/audit/audit_arg.c:678: warning: long long unsigned int format, u_int64_t arg (arg 2) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-02-03 23:07:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-02-03 23:07:55 - ERROR: failed to build lint kernel TB --- 2006-02-03 23:07:55 - tinderbox aborted TB --- 1.33 user 7.00 system 6757.84 real From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 23:27:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0622C16A423; Fri, 3 Feb 2006 23:27:51 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1378B43D4C; Fri, 3 Feb 2006 23:27:49 +0000 (GMT) (envelope-from max@love2party.net) Received: from [84.163.242.197] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1F5ALE30WQ-0006yH; Sat, 04 Feb 2006 00:27:49 +0100 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Sat, 4 Feb 2006 00:28:41 +0100 User-Agent: KMail/1.9.1 References: <20060203230755.B8CA57302F@freebsd-current.sentex.ca> In-Reply-To: <20060203230755.B8CA57302F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1286987.uLmHBk7in1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200602040028.47826.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Robert N M Watson Subject: Re: [head tinderbox] failure on amd64/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, 03 Feb 2006 23:27:51 -0000 --nextPart1286987.uLmHBk7in1 Content-Type: multipart/mixed; boundary="Boundary-01=_rc+4Do6Z1GZsyoy" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_rc+4Do6Z1GZsyoy Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 04 February 2006 00:07, FreeBSD Tinderbox wrote: > -finstrument-functions -Wno-inline /src/sys/security/audit/audit_arg.c > /src/sys/security/audit/audit_arg.c: In function `audit_arg_upath': > /src/sys/security/audit/audit_arg.c:676: warning: long long unsigned int > format, u_int64_t arg (arg 2) /src/sys/security/audit/audit_arg.c:678: > warning: long long unsigned int format, u_int64_t arg (arg 2) *** Error > code 1 Once again, fixed by - for example - the attached patch. Alternatively: .. "%ju", (uintmax_t)arg .. // we are so C99 I take this a chance to rant if we could remove this stupid 64bit=20 unportability. It should be possible to have a CASSERT somewhere that shut= s=20 this up if "sizeof(u_int64_t) =3D=3D sizeof(unsigned long long)" or the lik= e. I=20 hope somebody has more insight and how/where to fix it properly. Otherwise= =20 we will run into this portability issue over and over again. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_rc+4Do6Z1GZsyoy Content-Type: text/x-diff; charset="iso-8859-6"; name="longlongahrg.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="longlongahrg.diff" Index: audit_arg.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/security/audit/audit_arg.c,v retrieving revision 1.1 diff -u -r1.1 audit_arg.c =2D-- audit_arg.c 1 Feb 2006 20:01:18 -0000 1.1 +++ audit_arg.c 3 Feb 2006 23:19:26 -0000 @@ -674,9 +674,9 @@ * XXXAUDIT: Witness warning for possible sleep here? */ KASSERT((flag =3D=3D ARG_UPATH1) || (flag =3D=3D ARG_UPATH2), =2D ("audit_arg_upath: flag %llu", flag)); + ("audit_arg_upath: flag %llu", (unsigned long long)flag)); KASSERT((flag !=3D ARG_UPATH1) || (flag !=3D ARG_UPATH2), =2D ("audit_arg_upath: flag %llu", flag)); + ("audit_arg_upath: flag %llu", (unsigned long long)flag)); =20 ar =3D currecord(); if (ar =3D=3D NULL) --Boundary-01=_rc+4Do6Z1GZsyoy-- --nextPart1286987.uLmHBk7in1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD4+cvXyyEoT62BG0RArbgAJ93TBqmmhr2a/QXUAcoVd2jgYXShQCbBv0X jcIpDstGefIQ2JGPGPbhY6U= =O6G0 -----END PGP SIGNATURE----- --nextPart1286987.uLmHBk7in1-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 23:51:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A5E916A422 for ; Fri, 3 Feb 2006 23:51:26 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F23E43D48 for ; Fri, 3 Feb 2006 23:51:25 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 207AA46CAE; Fri, 3 Feb 2006 18:51:16 -0500 (EST) Date: Fri, 3 Feb 2006 23:53:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200602040028.47826.max@love2party.net> Message-ID: <20060203235235.T1100@fledge.watson.org> References: <20060203230755.B8CA57302F@freebsd-current.sentex.ca> <200602040028.47826.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/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, 03 Feb 2006 23:51:26 -0000 On Sat, 4 Feb 2006, Max Laier wrote: > On Saturday 04 February 2006 00:07, FreeBSD Tinderbox wrote: >> -finstrument-functions -Wno-inline /src/sys/security/audit/audit_arg.c >> /src/sys/security/audit/audit_arg.c: In function `audit_arg_upath': >> /src/sys/security/audit/audit_arg.c:676: warning: long long unsigned int >> format, u_int64_t arg (arg 2) /src/sys/security/audit/audit_arg.c:678: >> warning: long long unsigned int format, u_int64_t arg (arg 2) *** Error >> code 1 > > Once again, fixed by - for example - the attached patch. Alternatively: > .. "%ju", (uintmax_t)arg .. // we are so C99 > > I take this a chance to rant if we could remove this stupid 64bit > unportability. It should be possible to have a CASSERT somewhere that shuts > this up if "sizeof(u_int64_t) == sizeof(unsigned long long)" or the like. > I hope somebody has more insight and how/where to fix it properly. > Otherwise we will run into this portability issue over and over again. Thanks. I just realized I did my amd64 test builds without INVARIANTS compiled in. Patch committed. No opinion on the format string thing, except that I keep shooting the feet of myself and others. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 23:58:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 93AF916A425; Fri, 3 Feb 2006 23:58:37 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <43E3EE2D.10001@freebsd.org> Date: Sat, 04 Feb 2006 07:58:37 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060117 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Gallatin References: <17379.56708.421007.613310@grasshopper.cs.duke.edu> In-Reply-To: <17379.56708.421007.613310@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: machdep.cpu_idle_hlt and SMP perf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Feb 2006 23:58:38 -0000 Andrew Gallatin wrote: >Why dooes machdep.cpu_idle_hlt=1 drop my 10GbE network rx >performance by a considerable amount (7.5Gbs -> 5.5Gbs)? > >I've (blindly) tried leaving machdep.cpu_idle_hlt=1 enabled >and playing with the vast array of kern.sched.ipiwakeup.* sysctls, >but receive performance remains limited to ~5.5Gb/sec or less. > >This is an 'AMD Athlon(tm) 64 X2 Dual Core Processor 3800+' running >FreeBSD-current as of about one week ago. The interrupt load is >about 22,000 device interrupts/sec (ithreaded). Interestingly, >the more I decrease the interrupt load by increasing the interrupt >coalescing timer, the worse the machdep.cpu_idle_hlt=1 case does. > >Is this just a case of the wakeup IPI taking a long time or blocking >on some lock? > >Drew > >PS: Here is what I mean: > > I am thinking if we can rewrite cpu idle code by using mwait instruction on pentium4, it should reduce latency, I don't know if Athlon 64 supports this instruction yet. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 01:06:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0AD216A420; Sat, 4 Feb 2006 01:06:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87D3E43D45; Sat, 4 Feb 2006 01:06:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id k14168Sx067716; Fri, 3 Feb 2006 20:06:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4/8.13.4) with ESMTP id k1416LPj035653; Fri, 3 Feb 2006 20:06:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 550217302F; Fri, 3 Feb 2006 20:06:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060204010608.550217302F@freebsd-current.sentex.ca> Date: Fri, 3 Feb 2006 20:06:08 -0500 (EST) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2006 01:06:10 -0000 TB --- 2006-02-03 23:07:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-02-03 23:07:55 - starting HEAD tinderbox run for i386/i386 TB --- 2006-02-03 23:07:55 - cleaning the object tree TB --- 2006-02-03 23:08:22 - checking out the source tree TB --- 2006-02-03 23:08:22 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-02-03 23:08:22 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-02-03 23:15:06 - building world (CFLAGS=-O2 -pipe) TB --- 2006-02-03 23:15:06 - cd /src TB --- 2006-02-03 23:15:06 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-02-04 00:20:31 - generating LINT kernel config TB --- 2006-02-04 00:20:31 - cd /src/sys/i386/conf TB --- 2006-02-04 00:20:31 - /usr/bin/make -B LINT TB --- 2006-02-04 00:20:31 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-02-04 00:20:31 - cd /src TB --- 2006-02-04 00:20:31 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 4 00:20:31 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Feb 4 00:44:57 UTC 2006 TB --- 2006-02-04 00:44:57 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-02-04 00:44:57 - cd /src TB --- 2006-02-04 00:44:57 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Feb 4 00:44:57 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Feb 4 01:04:00 UTC 2006 TB --- 2006-02-04 01:04:00 - building PAE kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-02-04 01:04:00 - cd /src TB --- 2006-02-04 01:04:00 - /usr/bin/make buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Feb 4 01:04:01 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ips/ips_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ips/ips_pci.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/isp/isp.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/isp/isp_freebsd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/isp/isp_library.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/isp/isp_pci.c /src/sys/dev/isp/isp_pci.c: In function `isp_pci_mbxdma': /src/sys/dev/isp/isp_pci.c:1144: warning: large integer implicitly truncated to unsigned type *** Error code 1 Stop in /obj/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-02-04 01:06:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-02-04 01:06:08 - ERROR: failed to build PAE kernel TB --- 2006-02-04 01:06:08 - tinderbox aborted TB --- 0.87 user 4.09 system 7092.27 real From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 06:45:10 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCC4D16A420 for ; Sat, 4 Feb 2006 06:45:10 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C62E43D6A for ; Sat, 4 Feb 2006 06:44:58 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 3B6711A3C1E for ; Fri, 3 Feb 2006 22:44:58 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 756CD5155A; Sat, 4 Feb 2006 01:44:57 -0500 (EST) Date: Sat, 4 Feb 2006 01:44:57 -0500 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20060204064457.GA20820@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: jail leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 06:45:11 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I changed the package build scripts to build in jails instead of chroots, but I am seeing what look like leaks in the list of jails: dosirak# jls JID IP Address Hostname Path 271 10.0.225.48 jail-57648 /c/pkgbuild/6/chroot/57648 112 10.0.119.181 jail-30645 /c/pkgbuild/6/chroot/30645 dosirak# pgrep -lfj 112 dosirak# jls JID IP Address Hostname Path 112 10.0.119.181 jail-30645 /c/pkgbuild/6/chroot/30645 i.e. jail 112 has nothing running inside it, but it is still hanging around. Is there a good reason for this, or is it in fact a leak? Kris --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD5E1oWry0BWjoQKURAqD/AKDeo/LuWno5R29+uRAK5Jw4VuhV4gCbByVM jAk/dVhm/JC++JEDe/Xxj3o= =Pymd -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 07:13:50 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3B8216A420 for ; Sat, 4 Feb 2006 07:13:50 +0000 (GMT) (envelope-from chad@shire.net) Received: from hobbiton.shire.net (mail.shire.net [166.70.252.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 861D043D6A for ; Sat, 4 Feb 2006 07:13:47 +0000 (GMT) (envelope-from chad@shire.net) Received: from [67.161.222.227] (helo=[192.168.99.68]) by hobbiton.shire.net with esmtpa (Exim 4.51) id 1F5Hc9-000NjD-5O; Sat, 04 Feb 2006 00:13:46 -0700 In-Reply-To: <20060204064457.GA20820@xor.obsecurity.org> References: <20060204064457.GA20820@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Chad Leigh -- Shire.Net LLC" Date: Sat, 4 Feb 2006 00:13:44 -0700 To: Kris Kennaway X-Mailer: Apple Mail (2.746.2) X-SA-Exim-Connect-IP: 67.161.222.227 X-SA-Exim-Mail-From: chad@shire.net X-SA-Exim-Scanned: No (on hobbiton.shire.net); SAEximRunCond expanded to false Cc: current@FreeBSD.org Subject: Re: jail leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 07:13:51 -0000 On Feb 3, 2006, at 11:44 PM, Kris Kennaway wrote: > I changed the package build scripts to build in jails instead of > chroots, but I am seeing what look like leaks in the list of jails: > > dosirak# jls > JID IP Address Hostname Path > 271 10.0.225.48 jail-57648 /c/pkgbuild/6/ > chroot/57648 > 112 10.0.119.181 jail-30645 /c/pkgbuild/6/ > chroot/30645 > dosirak# pgrep -lfj 112 > dosirak# jls > JID IP Address Hostname Path > 112 10.0.119.181 jail-30645 /c/pkgbuild/6/ > chroot/30645 > > i.e. jail 112 has nothing running inside it, but it is still hanging > around. Is there a good reason for this, or is it in fact a leak? I cannot describe exactly how I have seen similar but I have seen similar "phantom" jails and it is always when I have done something wrong (like set up a jail on a non existent IP or had some mounts in the jail space that had problems etc). Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 07:16:47 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45DCD16A425 for ; Sat, 4 Feb 2006 07:16:47 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA87143D48 for ; Sat, 4 Feb 2006 07:16:46 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id AD9CC1A3C1E; Fri, 3 Feb 2006 23:16:46 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 103755155A; Sat, 4 Feb 2006 02:16:46 -0500 (EST) Date: Sat, 4 Feb 2006 02:16:45 -0500 From: Kris Kennaway To: "Chad Leigh -- Shire.Net LLC" Message-ID: <20060204071645.GA21934@xor.obsecurity.org> References: <20060204064457.GA20820@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: current@FreeBSD.org, Kris Kennaway Subject: Re: jail leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 07:16:47 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 04, 2006 at 12:13:44AM -0700, Chad Leigh -- Shire.Net LLC wrote: >=20 > On Feb 3, 2006, at 11:44 PM, Kris Kennaway wrote: >=20 > >I changed the package build scripts to build in jails instead of > >chroots, but I am seeing what look like leaks in the list of jails: > > > >dosirak# jls > > JID IP Address Hostname Path > > 271 10.0.225.48 jail-57648 /c/pkgbuild/6/=20 > >chroot/57648 > > 112 10.0.119.181 jail-30645 /c/pkgbuild/6/=20 > >chroot/30645 > >dosirak# pgrep -lfj 112 > >dosirak# jls > > JID IP Address Hostname Path > > 112 10.0.119.181 jail-30645 /c/pkgbuild/6/=20 > >chroot/30645 > > > >i.e. jail 112 has nothing running inside it, but it is still hanging > >around. Is there a good reason for this, or is it in fact a leak? >=20 > I cannot describe exactly how I have seen similar but I have seen =20 > similar "phantom" jails and it is always when I have done something =20 > wrong (like set up a jail on a non existent IP or had some mounts in =20 > the jail space that had problems etc). Well, AFAICT these jails all ran successfully. Kris --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD5FTdWry0BWjoQKURAn21AJ0YaFsZlEIw8GYdXdBCJ2W/xgZkQACgoPD9 WDcjRF/VGWxP6Sj1ZlR6Lf0= =Trj7 -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 07:47:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E38716A422 for ; Sat, 4 Feb 2006 07:47:31 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B853443D48 for ; Sat, 4 Feb 2006 07:47:30 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id k147lGFx004254; Sat, 4 Feb 2006 08:47:16 +0100 (MET) Message-ID: <43E45BD8.7070708@fer.hr> Date: Sat, 04 Feb 2006 08:46:32 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Gallatin References: <17379.56708.421007.613310@grasshopper.cs.duke.edu> In-Reply-To: <17379.56708.421007.613310@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: machdep.cpu_idle_hlt and SMP perf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 07:47:31 -0000 Andrew Gallatin wrote: > Why dooes machdep.cpu_idle_hlt=1 drop my 10GbE network rx > performance by a considerable amount (7.5Gbs -> 5.5Gbs)? For what it's worth, here are results of unixbench's "context1" benchmark on an old P3 SMP with and without cpu_idle_hlt (6-stable): x hlt=0 + hlt=1 +--------------------------------------------------------------------------+ | + ++ + + x xx x x| ||_______M___A____________| |____M__A_______| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 346203 355234 347787 349229.8 3549.1559 + 5 322710 337269 325631 327663.8 5622.9044 Difference at 95.0% confidence -21566 +/- 6857.28 -6.1753% +/- 1.96354% (Student's t, pooled s = 4701.78) From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 11:05:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2BC216A420 for ; Sat, 4 Feb 2006 11:05:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2248843D49 for ; Sat, 4 Feb 2006 11:05:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id E02051FFE92; Sat, 4 Feb 2006 12:05:08 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 145E61FFDE8; Sat, 4 Feb 2006 12:05:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id DBBD344487E; Sat, 4 Feb 2006 11:01:32 +0000 (UTC) Date: Sat, 4 Feb 2006 11:01:32 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Kris Kennaway In-Reply-To: <20060204064457.GA20820@xor.obsecurity.org> Message-ID: <20060204110016.V21148@maildrop.int.zabbadoz.net> References: <20060204064457.GA20820@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: FreeBSD current mailing list Subject: Re: jail leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 11:05:12 -0000 On Sat, 4 Feb 2006, Kris Kennaway wrote: > I changed the package build scripts to build in jails instead of > chroots, but I am seeing what look like leaks in the list of jails: ... > i.e. jail 112 has nothing running inside it, but it is still hanging > around. Is there a good reason for this, or is it in fact a leak? It's a leak with devfs/?ty code that keeps an ucred around. And it already has a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 11:07:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB43E16A420 for ; Sat, 4 Feb 2006 11:07:01 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38C2943D53 for ; Sat, 4 Feb 2006 11:07:00 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [127.0.0.1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id k14B6uK8029288; Sat, 4 Feb 2006 12:06:56 +0100 (CET) (envelope-from stb@lassitu.de) In-Reply-To: <20060204064457.GA20820@xor.obsecurity.org> References: <20060204064457.GA20820@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A2A8D5B-9AE5-46E0-B5EB-1824E331E776@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Sat, 4 Feb 2006 12:06:10 +0100 To: Kris Kennaway X-Mailer: Apple Mail (2.746.2) Cc: current@freebsd.org Subject: Re: jail leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 11:07:01 -0000 Am 04.02.2006 um 07:44 schrieb Kris Kennaway: > I changed the package build scripts to build in jails instead of > chroots, but I am seeing what look like leaks in the list of jails: > > dosirak# jls > JID IP Address Hostname Path > 271 10.0.225.48 jail-57648 /c/pkgbuild/6/ > chroot/57648 > 112 10.0.119.181 jail-30645 /c/pkgbuild/6/ > chroot/30645 > dosirak# pgrep -lfj 112 > dosirak# jls > JID IP Address Hostname Path > 112 10.0.119.181 jail-30645 /c/pkgbuild/6/ > chroot/30645 > > i.e. jail 112 has nothing running inside it, but it is still hanging > around. Is there a good reason for this, or is it in fact a leak? This question has come up a number of times before. It appears the jail will only go away after all resources associated with that jail are returned. Unfortunatly, there doesn't seem to be an easy way to identify which resources are still allocated to it... We're running one 5-stable box with 7 jails, and so far, those phantoms have all disappeared eventually. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 11:16:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A17FC16A420 for ; Sat, 4 Feb 2006 11:16:40 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.net (mail.yazzy.net [217.8.140.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0997B43D45 for ; Sat, 4 Feb 2006 11:16:39 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from lapdance.yazzy.net (unknown [192.168.99.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yazzy.net (Postfix) with ESMTP id 5A24D39835; Sat, 4 Feb 2006 12:17:33 +0100 (CET) Date: Sat, 4 Feb 2006 11:15:35 +0000 From: Marcin Jessa To: Kris Kennaway Message-Id: <20060204111535.31e42861.lists@yazzy.org> In-Reply-To: <20060203225114.GA9845@xor.obsecurity.org> References: <17379.56708.421007.613310@grasshopper.cs.duke.edu> <20060203225114.GA9845@xor.obsecurity.org> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: machdep.cpu_idle_hlt and SMP perf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 11:16:40 -0000 On Fri, 3 Feb 2006 17:51:14 -0500 Kris Kennaway wrote: > On Fri, Feb 03, 2006 at 05:47:32PM -0500, Andrew Gallatin wrote: > > > > Why dooes machdep.cpu_idle_hlt=1 drop my 10GbE network rx > > performance by a considerable amount (7.5Gbs -> 5.5Gbs)? > > I don't know, but I've set this to 0 on my machines because I also > noticed a significant performance drop on general workloads with it > set to 1. On a 32 or 64-bits CPU? From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 16:10:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB89E16A420 for ; Sat, 4 Feb 2006 16:10:21 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id A64DB4464A for ; Sat, 4 Feb 2006 16:10:20 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 71966 invoked by uid 399); 1 Feb 2006 07:10:18 -0000 Received: from localhost (HELO ?192.168.1.101?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 1 Feb 2006 07:10:18 -0000 Message-ID: <43E05ED9.9000900@FreeBSD.org> Date: Tue, 31 Jan 2006 23:10:17 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Sean McNeil References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Robert Watson , current@freebsd.org Subject: Re: MFC of bump in libcom_err.so another mistake? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 16:10:21 -0000 Sean McNeil wrote: > This is EXACTLY what I am saying. I am not a -current user, I am a > -stable user and this happened about a week ago or so. It was > libcom_err.so.2.1 until just recently. I don't see how it could be libanything.so.2.1 on a FreeBSD system, given that we dropped minor revision numbers on shared libs back at the elf conversion. Also: ls /usr/lib/*.[0-9].[0-9] /lib/*.[0-9].[0-9] ls: /lib/*.[0-9].[0-9]: No such file or directory ls: /usr/lib/*.[0-9].[0-9]: No such file or directory I don't know where you got libcom_err.so.2.1, but I don't think it's from a FreeBSD system. Also, to make things clear, if you are using 7-current, this is the right list to continue asking for help on. If you're using 6.0, you should ask for help on freebsd-stable@freebsd.org. Before doing so however, if I were you I'd take the following steps: 1. cvsup the latest sources for RELENG_6 (6-stable). 2. cd /usr/src ; make cleanworld 3. make buildworld ; make kernel 4. Follow the upgrading instructions in src/UPDATING 5. Go into /lib and /usr/lib, and do 'ls -lr', then mv any old libraries out of those directories. 6. cd /etc/ ; mv libmap.conf libmap.conf.bak (it's ok if this file doesn't exist) 7. reboot 8. Rebuild any ports that don't work, even if that means all of them. Then I'd say you're in pretty good shape to start asking for help again, presumably on freebsd-stable@. Good luck, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 16:21:16 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90A7616A445 for ; Sat, 4 Feb 2006 16:21:16 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80CAB44583 for ; Sat, 4 Feb 2006 16:00:33 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k14FxEN6012900; Sat, 4 Feb 2006 08:59:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 04 Feb 2006 08:59:17 -0700 (MST) Message-Id: <20060204.085917.129781502.imp@bsdimp.com> To: ivoras@fer.hr From: "M. Warner Losh" In-Reply-To: <43E45BD8.7070708@fer.hr> References: <17379.56708.421007.613310@grasshopper.cs.duke.edu> <43E45BD8.7070708@fer.hr> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 04 Feb 2006 08:59:14 -0700 (MST) Cc: gallatin@cs.duke.edu, current@freebsd.org Subject: Re: machdep.cpu_idle_hlt and SMP perf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 16:21:20 -0000 In message: <43E45BD8.7070708@fer.hr> Ivan Voras writes: : Andrew Gallatin wrote: : > Why dooes machdep.cpu_idle_hlt=1 drop my 10GbE network rx : > performance by a considerable amount (7.5Gbs -> 5.5Gbs)? : : For what it's worth, here are results of unixbench's "context1" : benchmark on an old P3 SMP with and without cpu_idle_hlt (6-stable): When ACPI CPU states were coming into the tree, there was discussion that they had been invented to provide a lower energy idle as well as a faster transition from the idle state to something else. I think that these benchmarks show this effect rather dramatically. Warner From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 19:35:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC01B16A420 for ; Sat, 4 Feb 2006 19:35:12 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8208A43D4C for ; Sat, 4 Feb 2006 19:35:12 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 57CE11A3C27; Sat, 4 Feb 2006 11:35:12 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1D4A1515FD; Sat, 4 Feb 2006 14:35:11 -0500 (EST) Date: Sat, 4 Feb 2006 14:35:10 -0500 From: Kris Kennaway To: Marcin Jessa Message-ID: <20060204193510.GA58074@xor.obsecurity.org> References: <17379.56708.421007.613310@grasshopper.cs.duke.edu> <20060203225114.GA9845@xor.obsecurity.org> <20060204111535.31e42861.lists@yazzy.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <20060204111535.31e42861.lists@yazzy.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, gallatin@cs.duke.edu, Kris Kennaway Subject: Re: machdep.cpu_idle_hlt and SMP perf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 19:35:13 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 04, 2006 at 11:15:35AM +0000, Marcin Jessa wrote: > On Fri, 3 Feb 2006 17:51:14 -0500 > Kris Kennaway wrote: >=20 > > On Fri, Feb 03, 2006 at 05:47:32PM -0500, Andrew Gallatin wrote: > > >=20 > > > Why dooes machdep.cpu_idle_hlt=3D1 drop my 10GbE network rx > > > performance by a considerable amount (7.5Gbs -> 5.5Gbs)? > >=20 > > I don't know, but I've set this to 0 on my machines because I also > > noticed a significant performance drop on general workloads with it > > set to 1. >=20 > On a 32 or 64-bits CPU? I only measured on i386. Kris --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD5QHuWry0BWjoQKURAtEyAJ4tj3xryNgdbGoPJ8lZ72Lag4+55gCfYQoI qkQob7/G6d9X/gAhMhRzB8g= =v+5Y -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 20:07:49 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E46A16A423; Sat, 4 Feb 2006 20:07:49 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F37B43D46; Sat, 4 Feb 2006 20:07:47 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id k14K7fqg041955; Sat, 4 Feb 2006 22:07:41 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ip.net.ua [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 82175-12-6; Sat, 4 Feb 2006 22:07:40 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id k14K6hsi041695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Feb 2006 22:06:43 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id k14K6lQH007731; Sat, 4 Feb 2006 22:06:47 +0200 (EET) (envelope-from ru) Date: Sat, 4 Feb 2006 22:06:46 +0200 From: Ruslan Ermilov To: Jeff Roberson Message-ID: <20060204200646.GA7604@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: current@FreeBSD.org Subject: panic: Giant not owned in vfs_subr.c:2029 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 20:07:49 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jeff, Your last commit to vfs_subr.c (rev. 1.657) causes an immediate panic when doing ls(1) over CD9660 or NFS mounted file system, on amd64 (I am sure that arch doesn't really matter). Reverting this revision fixes the issue. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD5QlWqRfpzJluFF4RAtYNAJ4n8xOH1bjCKxzhJuXmMEP5nAdQ4wCfSmdX H+xVLJhtr7bJIkZiH2iO1xI= =MQnA -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 4 23:22:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F125D16A420 for ; Sat, 4 Feb 2006 23:22:12 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86BD143D46 for ; Sat, 4 Feb 2006 23:22:12 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.104) by pne-smtpout2-sn1.fre.skanova.net (7.2.069.1) id 43E2EBED0007904C for freebsd-current@freebsd.org; Sun, 5 Feb 2006 00:22:11 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sun, 5 Feb 2006 00:22:11 +0100 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A605F58C@royal64.emp.zapto.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: machdep.cpu_idle_hlt and SMP perf? Thread-Index: AcYpgO2ghbRT9vAOQVivMK43pmHBlwAXoqQg From: "Daniel Eriksson" To: Subject: RE: machdep.cpu_idle_hlt and SMP perf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Feb 2006 23:22:13 -0000 I just finished running 6 sets of (make clean + buildworld + buildkernel), toggling machdep.cpu_idle_hlt between enabled and disabled each time (3 of each). Hardware: 2 x Athlon MP 2600+ on a Tyan Tiger 2466 mobo with 768MB memory Disks: 4 x 36GB 10k rpm in RAID-5 config on a SmartArray 6302/64 controller (ciss) Software: RELENG_6 from yesterday machdep.cpu_idle_hlt=3D1 45.01 46.12 45.30 machdep.cpu_idle_hlt=3D0 43.47 43.09 43.29 Looks like machdep.cpu_idle_hlt=3D0 shaves ~2 min off the build-time on = my server. /Daniel