From owner-freebsd-current@FreeBSD.ORG Sun Jul 11 09:45:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A80D1106566B for ; Sun, 11 Jul 2010 09:45:31 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 135788FC13 for ; Sun, 11 Jul 2010 09:45:30 +0000 (UTC) Received: by wwe15 with SMTP id 15so946859wwe.31 for ; Sun, 11 Jul 2010 02:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=41svjyQVtYivCABCA5v/xb03JIig/oPp7coLvJiG2RU=; b=Hh0FB4K5qbZ3A8gSGmsvP/TPA6C2SRW/JBvC3TCzZghJlf37cl8fLj3MJvt6IoSGK9 4wt7jcYGiaAFDCV6+z7WRqF8RcXa55Py9h6ec+wW1L1EXFwyb00FKhfZA2kpHso6Z8lW XeoMPDyQc1xRk3VonVOg2rbNWJYaFM6JmgVHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gcK11F55tiUJvUCkM96zxh/KvUY0mv76S/hQZQf2fbai7wMZ+M8jCmvTPuetI2cOG7 92TzuVvqurCeORDNcLhub2Hjvt40hkOqHLjtnXbe4VoLWUErRFvndiZ4xfg8mjp82vKk IuJZ5eI2RToGn3+az5PErK0oXL+qx/rFhRq24= MIME-Version: 1.0 Received: by 10.216.231.25 with SMTP id k25mr2071709weq.2.1278841528576; Sun, 11 Jul 2010 02:45:28 -0700 (PDT) Received: by 10.216.11.145 with HTTP; Sun, 11 Jul 2010 02:45:28 -0700 (PDT) In-Reply-To: <20100709232210.GA1973@server.vk2pj.dyndns.org> References: <4C31C71C.2010606@FreeBSD.org> <20100708200446.GA33822@server.vk2pj.dyndns.org> <4C364379.6020608@FreeBSD.org> <20100709232210.GA1973@server.vk2pj.dyndns.org> Date: Sun, 11 Jul 2010 11:45:28 +0200 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Martin Matuska Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2010 09:45:31 -0000 patch works fine here on 8-STABLE. my deadlock probleme seams to be corrected (after 6h of zfs receive + find | wc -l + many small reads). 2010/7/10 Peter Jeremy : > On 2010-Jul-08 23:30:33 +0200, Martin Matuska wrote: >>> Looking at the patchset, the most critical issue (IMHO) that doesn't >>> appear to have been addressed is the interaction between ZFS ARC and >>> the VM cache used by UFS/NFS: arc_memory_throttle() is still making >>> decisions solely on the amount of "free" memory, without considering >>> "inactive" or "cache". =A0I am running a slight variant of a patch by > ... >>Regarding ARC, you might want to try the revision 209227 from head that >>is scheduled for MFC on 18.7.2010: >>http://people.freebsd.org/~mm/patches/zfs/head-12636.patch > > That patch appears to address issues with unreasonable arc sizing but > doesn't alter the throttling algorithm: FreeBSD's "traditional" VM > management algorithm (used by everything except ZFS) minimises space > marked as "free" by preferentially keeping cached data in the "cache" > or "inactive" queues. =A0ZFS uses its own caching which solely uses the > "free" list to determine memory availability. =A0This means ZFS can't > apply any pressure to the FreeBSD VM system and runs in a virtually > permanent state of memory starvation. > > In any case, I have applied that patch as it appears useful. > > -- > Peter Jeremy > From owner-freebsd-current@FreeBSD.ORG Sun Jul 11 10:29:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFC1B106564A; Sun, 11 Jul 2010 10:29:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 119278FC22; Sun, 11 Jul 2010 10:29:30 +0000 (UTC) Received: by fxm13 with SMTP id 13so2014331fxm.13 for ; Sun, 11 Jul 2010 03:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=OgZeBVkNxEWmLYaBTxBbUI0qPPU/P5qLxfIfmYaGC+Y=; b=cqqnBpQJ4/GwTUoF7+4DJIxKxpPryjKjdNm7Rw/xtBFbnPUGzDt06oypYZjwAzkliR v/kMq1YDTa/HkO8h+XYwA8FsjnL4jDI23XUzNGq2WqbG+DnO9FJ+DsyRmOhR0NBi7CgN AkH2lEDHOU77PxU03+HayWPVOIO7iMVnCJExY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=fQhRLjchA/yGjn7qlzyC6QxjXhSNDacUd2Z53h3jqLn2h8ZW9ExJh2YT4Z5qglaz3t isMmvS7NU0NVRKI7yzPEYULG07Z1KK9K5YcoQ2njQXXkfqMO8ljSQ4dFJlnXN+EFXazW QTODxztsRBCAnIo0nPh25vCSOxokYdbOKncms= Received: by 10.223.112.75 with SMTP id v11mr10190556fap.106.1278844169882; Sun, 11 Jul 2010 03:29:29 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id c3sm6453740fay.38.2010.07.11.03.29.27 (version=SSLv3 cipher=RC4-MD5); Sun, 11 Jul 2010 03:29:28 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C399CD2.7010804@FreeBSD.org> Date: Sun, 11 Jul 2010 13:28:34 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Doug Barton References: <20100710074455.4E516818130@smtp3-g21.free.fr> <4C38B7F4.8040109@FreeBSD.org> In-Reply-To: <4C38B7F4.8040109@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------020909050304040708050602" Cc: raoul , freebsd-current@freebsd.org Subject: Re: panic on dell laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2010 10:29:31 -0000 This is a multi-part message in MIME format. --------------020909050304040708050602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Doug Barton wrote: > Try backing up to svn r209633 and see if you can boot. What you're > describing is identical to a panic I had starting with the next > revision, also on a Dell laptop. Please try attached patch against HEAD. -- Alexander Motin --------------020909050304040708050602 Content-Type: text/plain; name="timers.res.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="timers.res.patch" diff -ruNp isa.prev/atrtc.c isa/atrtc.c --- isa.prev/atrtc.c 2010-07-11 11:43:18.000000000 +0300 +++ isa/atrtc.c 2010-07-11 12:33:49.000000000 +0300 @@ -244,6 +244,7 @@ static int atrtc_attach(device_t dev) { struct atrtc_softc *sc; + u_long s; int i, diag; sc = device_get_softc(dev); @@ -260,7 +261,9 @@ atrtc_attach(device_t dev) (resource_int_value(device_get_name(dev), device_get_unit(dev), "clock", &i) != 0 || i != 0)) { sc->intr_rid = 0; - bus_delete_resource(dev, SYS_RES_IRQ, sc->intr_rid); + while (bus_get_resource(dev, SYS_RES_IRQ, sc->intr_rid, + &s, NULL) == 0 && s != 8) + sc->intr_rid++; if (!(sc->intr_res = bus_alloc_resource(dev, SYS_RES_IRQ, &sc->intr_rid, 8, 8, 1, RF_ACTIVE))) { device_printf(dev,"Can't map interrupt.\n"); diff -ruNp isa.prev/clock.c isa/clock.c --- isa.prev/clock.c 2010-07-11 11:43:24.000000000 +0300 +++ isa/clock.c 2010-07-11 13:25:45.000000000 +0300 @@ -94,7 +94,8 @@ static int i8254_ticked; struct attimer_softc { int intr_en; - int intr_rid; + int port_rid, intr_rid; + struct resource *port_res; struct resource *intr_res; void *intr_handler; struct timecounter tc; @@ -523,10 +524,14 @@ static int attimer_attach(device_t dev) { struct attimer_softc *sc; + u_long s; int i; attimer_sc = sc = device_get_softc(dev); bzero(sc, sizeof(struct attimer_softc)); + if (!(sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, + &sc->port_rid, IO_TIMER1, IO_TIMER1 + 3, 4, RF_ACTIVE))) + device_printf(dev,"Warning: Couldn't map I/O.\n"); i8254_intsrc = intr_lookup_source(0); if (i8254_intsrc != NULL) i8254_pending = i8254_intsrc->is_pic->pic_source_pending; @@ -541,7 +546,9 @@ attimer_attach(device_t dev) if (resource_int_value(device_get_name(dev), device_get_unit(dev), "clock", &i) != 0 || i != 0) { sc->intr_rid = 0; - bus_delete_resource(dev, SYS_RES_IRQ, sc->intr_rid); + while (bus_get_resource(dev, SYS_RES_IRQ, sc->intr_rid, + &s, NULL) == 0 && s != 0) + sc->intr_rid++; if (!(sc->intr_res = bus_alloc_resource(dev, SYS_RES_IRQ, &sc->intr_rid, 0, 0, 1, RF_ACTIVE))) { device_printf(dev,"Can't map interrupt.\n"); --------------020909050304040708050602-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 11 15:43:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A08DF1065673; Sun, 11 Jul 2010 15:43:57 +0000 (UTC) (envelope-from rmgls@free.fr) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by mx1.freebsd.org (Postfix) with ESMTP id 113A18FC15; Sun, 11 Jul 2010 15:43:54 +0000 (UTC) Received: from free.fr (unknown [88.172.40.194]) by smtp3-g21.free.fr (Postfix) with ESMTP id 87D38818139; Sun, 11 Jul 2010 17:43:49 +0200 (CEST) To: Alexander Motin From: raoul Date: Sun, 11 Jul 2010 17:43:48 +0200 Sender: rmgls@free.fr Message-Id: <20100711154349.87D38818139@smtp3-g21.free.fr> Cc: Doug Barton , freebsd-current@freebsd.org Subject: Re: panic on dell laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2010 15:43:57 -0000 On Sun, 11 Jul 2010 13:28:34 +0300 Alexander Motin wrote: >> Doug Barton wrote: >> Try backing up to svn r209633 and see if you can boot. What you're >> describing is identical to a panic I had starting with the next >> revision, also on a Dell laptop. > Please try attached patch against HEAD. -- >Alexander Motin ----------------------------- >diff -ruNp isa.prev/atrtc.c isa/atrtc.c >--- isa.prev/atrtc.c 2010-07-11 11:43:18.000000000 +0300 >+++ isa/atrtc.c 2010-07-11 12:33:49.000000000 +0300 @@ -244,6 +244,7 @@ static int > atrtc_attach(device_t dev) > { > struct atrtc_softc *sc; >+ u_long s; > int i, diag; > sc = device_get_softc(dev); @ -260,7 +261,9 @@ atrtc_attach(device_t dev) > (resource_int_value(device_get_name(dev), device_get_unit(dev), > "clock", &i) != 0 || i != 0)) { > sc->intr_rid = 0; >- bus_delete_resource(dev, SYS_RES_IRQ, sc->intr_rid); >+ while (bus_get_resource(dev, SYS_RES_IRQ, sc->intr_rid, >+ &s, NULL) == 0 && s != 8) >+ sc->intr_rid++; > if (!(sc->intr_res = bus_alloc_resource(dev, SYS_RES_IRQ, > &sc->intr_rid, 8, 8, 1, RF_ACTIVE))) { > device_printf(dev,"Can't map interrupt.\n"); >diff -ruNp isa.prev/clock.c isa/clock.c >--- isa.prev/clock.c 2010-07-11 11:43:24.000000000 +0300 >+++ isa/clock.c 2010-07-11 13:25:45.000000000 +0300 @ -94,7 +94,8 @@ static int i8254_ticked; > > struct attimer_softc { > int intr_en; >- int intr_rid; >+ int port_rid, intr_rid; >+ struct resource *port_res; > struct resource *intr_res; > void *intr_handler; > struct timecounter tc; @@ -523,10 +524,14 @@ static int > attimer_attach(device_t dev) > { > struct attimer_softc *sc; >+ u_long s; > int i; > attimer_sc = sc = device_get_softc(dev); > bzero(sc, sizeof(struct attimer_softc)); >+ if (!(sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, >+ &sc->port_rid, IO_TIMER1, IO_TIMER1 + 3, 4, RF_ACTIVE))) >+ device_printf(dev,"Warning: Couldn't map I/O.\n"); > i8254_intsrc = intr_lookup_source(0); > if (i8254_intsrc != NULL) > i8254_pending = i8254_intsrc->is_pic->pic_source_pending; @@ -541,7 +546,9 @@ attimer_attach(device_t dev) > if (resource_int_value(device_get_name(dev), device_get_unit(dev), > "clock", &i) != 0 || i != 0) { > sc->intr_rid = 0; >- bus_delete_resource(dev, SYS_RES_IRQ, sc->intr_rid); >+ while (bus_get_resource(dev, SYS_RES_IRQ, sc->intr_rid, >+ &s, NULL) == 0 && s != 0) >+ sc->intr_rid++; > if (!(sc->intr_res = bus_alloc_resource(dev, SYS_RES_IRQ, > &sc->intr_rid, 0, 0, 1, RF_ACTIVE))) { > device_printf(dev,"Can't map interrupt.\n"); Hi Alexander, your patch worked fine for me. Many Thanks Perhaps it would be a good thing to commit it? Bests Raoul rmgls@free.fr From owner-freebsd-current@FreeBSD.ORG Sun Jul 11 17:02:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A02C8106564A for ; Sun, 11 Jul 2010 17:02:13 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from klausdieter0815.dyndns.org (e180217098.adsl.alicedsl.de [85.180.217.98]) by mx1.freebsd.org (Postfix) with ESMTP id 23A458FC0C for ; Sun, 11 Jul 2010 17:02:12 +0000 (UTC) Received: from klausdieter0815.dyndns.org (localhost [127.0.0.1]) by klausdieter0815.dyndns.org (8.14.4/8.14.4) with ESMTP id o6BH2BN9058157 for ; Sun, 11 Jul 2010 17:02:11 GMT (envelope-from christof.schulze@gmx.com) Received: (from erika@localhost) by klausdieter0815.dyndns.org (8.14.4/8.14.4/Submit) id o6BH2BEK058156 for freebsd-current@freebsd.org; Sun, 11 Jul 2010 19:02:11 +0200 (CEST) (envelope-from christof.schulze@gmx.com) X-Authentication-Warning: klausdieter0815.dyndns.org: erika set sender to christof.schulze@gmx.com using -f From: Christof Schulze To: freebsd-current@freebsd.org Date: Sun, 11 Jul 2010 17:02:06 +0000 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RC1; KDE/4.4.5; amd64; ; ) References: <4C23BA5B.2020709@FreeBSD.org> In-Reply-To: <4C23BA5B.2020709@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11384906.a98DIrmLuE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007111702.10808.christof.schulze@gmx.com> Subject: Re: [CFT] ZFS v16 with stat() speedup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2010 17:02:13 -0000 --nextPart11384906.a98DIrmLuE Content-Type: Text/Plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hello, Am Thursday 24 June 2010 20:04:43 schrieb Martin Matuska: > As I have imported some more improvements to the ZFS v15 patch that also > target speed, > I am now calling for testing of v16 with mainly the following important > (post-v16) enhancement (and some related bugfixes): Thank you very much for your hard work. Yesterday I set up my system using = the=20 instructions below and I have had no problems so far. This is an amd64 system with 8GB ram. I am willing to do additional testing= if=20 wanted but I'd need further instructions on that one. Regards Christof >=20 > OpenSolaris Bug ID: 6775100 stat() performance on files on zfs should be > improved > This significantly improves stat() performance of ZFS and has a very > positive effect on e.g webservers using PHP > (I benchmarked a ~20% speed increase of PHP webserving) >=20 > The patch is available here: > http://people.freebsd.org/~mm/patches/zfs/v16/head-v16-extended.patch >=20 > List of all changes (compared to current head and v15-patch): > http://people.freebsd.org/~mm/patches/zfs/v16/head-v16.txt >=20 > And again some ISOs (patched 8.1rc1) for testing: > http://mfsbsd.vx.sk/iso/8.1rc1-zfsv16.iso (without symbols, 98.7MB) > http://mfsbsd.vx.sk/iso/8.1rc1-zfsv16-debug.iso (with kernel symbols, > 187.6MB) >=20 > Login/password: root/mfsroot >=20 > You can test these ISO's in Virtualbox, other emulation software or > real-world systems. > They contain a full installable distribution, here is a zfsinstall > command example on an ad4 disk, with ZFS version 16, 4GB extra swap > partition, lzjb compression and fletcher4 checksum: >=20 > 1. Login as root (root:mfsroot) > 2. mount_cd9660 /dev/acd0 /cdrom > 3. zfsinstall -V 16 -t /cdrom/8.1-RC1-amd64.tar.xz -s 4G -c -4 -d ad4 >=20 > When mfsbsd (not the installed system) is booted, there is a python and > py-zfs package in /packages. You can copy and install these to your > installed system for full pyzfs functionality (zfs userspace, zfs > groupspace, zfs allow, zfs unallow). >=20 > Thanks for testing, > mm > _______________________________________________ > 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" =2D-=20 () ascii ribbon campaign - against html e-mail=20 /\ www.asciiribbon.org - against proprietary attachments --nextPart11384906.a98DIrmLuE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEABECAAYFAkw5+RIACgkQpZfyPAmdZJm8aACfVDWGValOUeoSS/6ZmLEDVRKq 7mEAniVwDh4hogXjl+POK53ElG+0ZE0n =/Gbz -----END PGP SIGNATURE----- --nextPart11384906.a98DIrmLuE-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 11 17:52:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B05BE1065674 for ; Sun, 11 Jul 2010 17:52:14 +0000 (UTC) (envelope-from pali.gabor@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 352258FC12 for ; Sun, 11 Jul 2010 17:52:13 +0000 (UTC) Received: by bwz12 with SMTP id 12so2431412bwz.13 for ; Sun, 11 Jul 2010 10:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=MNY5zUQXEbUxcV3+lDRPGTdCXBIHZz/mecMok46sui0=; b=QV7fvMBY8PuDxFZbtzjcGEJQiD8gSCfBMZZ+74Nns6X47Tx3tKvytK00yv/JB856ZH qWk/ZFXjhT1qrHfY1R2mSxDUeutMkNTFs6ZVbZgqhP9XQr3rjlSj9W2ZRNiD7yKW4nWU DxVbCaqvsjeGmD5WBXiFC1ZBMgGmfUQZukfG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=LXLlFLKNPSwEvwIg/Ofjvy3T8gdplcUNS4SLcJ62+vc4A/R7/nbUlB/S8+aOrMXXEi GqIjX9MHkkXBPKnEOLYNXnasbMcGK3erhDu60TC3gXvm6Z97XTBlqFUK3kWEvvD5iau2 /2t4GJLGirAC0Mje02WWjqw9SYRkO9MIJz1Lk= Received: by 10.204.81.100 with SMTP id w36mr9494782bkk.22.1278868949182; Sun, 11 Jul 2010 10:22:29 -0700 (PDT) Received: from [129.16.199.244] (dhcp-199-244.nomad.chalmers.se [129.16.199.244]) by mx.google.com with ESMTPS id 24sm14371656bkr.19.2010.07.11.10.22.28 (version=SSLv3 cipher=RC4-MD5); Sun, 11 Jul 2010 10:22:28 -0700 (PDT) Sender: =?UTF-8?B?UMOBTEkgR8OhYm9yIErDoW5vcw==?= Message-ID: <4C39FE1B.3010304@FreeBSD.org> Date: Sun, 11 Jul 2010 19:23:39 +0200 From: Gabor PALI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Call for testers: wireless module for bsnmpd(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2010 17:52:14 -0000 On 07/10/10 13:27, Shteryana Shopova wrote: > All feedback is wellcome - bug reports, requests for features to be > included in future versions of the module, code style and bug fix > patches. > A few comments: - I think there should be bsnmpd(1) instead of bsnmpd(8) in the NAME section of snmp_wlan(3). - It creates an "/usr/lib/snmp_wlan.so." file which seems a bit strange for me. - It produces the following on my machine: snmpd[3871]: SNMP wlan loaded wlan_wlan_acl module snmpd[3871]: send: Connection refused snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument I have the following card configured for wlan0: wpi0: mem 0xf0200000-0xf0200fff irq 18 at device 0.0 on pci4 wpi0: Driver Revision 20071127 wpi0: Hardware Revision (0x1) It is a FreeBSD/amd64 8-STABLE, from around beginning of April. :g From owner-freebsd-current@FreeBSD.ORG Sun Jul 11 19:04:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 076E6106564A for ; Sun, 11 Jul 2010 19:04:05 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BB1B98FC19 for ; Sun, 11 Jul 2010 19:04:04 +0000 (UTC) Received: by iwn35 with SMTP id 35so4915424iwn.13 for ; Sun, 11 Jul 2010 12:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=91i81G95vlYYQaR5HbuyoXG7fHEy5sYWU89bDvJhTTo=; b=IxNfJqCQwkYVU9kipwJHckRBASAXyxuubIt2i98SRtAEETT5SpyWWADwGwj23Hy3aU BilzlKKuHWQ/8P78gKfevawZaVVbo2Yk+bn57jgSmrHGtL3CylFRJjs7Yr8vmv0qm3uz uecJy0+lShlbfjGguaYtnJOeJUAjSUT2N1kd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ZxnPl6B2QyLw4Jo09aaZOEN6/OBBSZ7QvdA8HfameD6uodO9QIC7jeJuXlioOZ16km MOGVnhhZVfdHYIqqULcfJVlrR03GF3g/HzsxdsqI6VRr0H8TrDFfmBlaLkq9k83U8GR+ l++bGHQGALgqwkdvrkXTCBHVUxB5Be7NiCCS8= Received: by 10.231.171.18 with SMTP id f18mr8845265ibz.9.1278875044028; Sun, 11 Jul 2010 12:04:04 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id r3sm15644765ibk.1.2010.07.11.12.04.02 (version=SSLv3 cipher=RC4-MD5); Sun, 11 Jul 2010 12:04:02 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C3A15A2.2040309@dataix.net> Date: Sun, 11 Jul 2010 15:04:02 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: Christof Schulze References: <4C23BA5B.2020709@FreeBSD.org> <201007111702.10808.christof.schulze@gmx.com> In-Reply-To: <201007111702.10808.christof.schulze@gmx.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [CFT] ZFS v16 with stat() speedup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2010 19:04:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/11/2010 13:02, Christof Schulze wrote: > Hello, > > > Am Thursday 24 June 2010 20:04:43 schrieb Martin Matuska: >> As I have imported some more improvements to the ZFS v15 patch that also >> target speed, >> I am now calling for testing of v16 with mainly the following important >> (post-v16) enhancement (and some related bugfixes): > Thank you very much for your hard work. Yesterday I set up my system using the > instructions below and I have had no problems so far. > > This is an amd64 system with 8GB ram. I am willing to do additional testing if > wanted but I'd need further instructions on that one. > > Regards > > Christof > > FYI: This thread is outdated by the [CFT] ZFS v15 thread. ZFS v16 will not be committed and v15 is now the preferred testing thread. If you need a copy of the new [CFT] ZFS v15 message let me know and I will forward it to you happily. Regards, - -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBAgAGBQJMOhWiAAoJEJBXh4mJ2FR+WqgH/iBRatZMwLu7C6ADSUd3OeiD RE6E+7VOQf/LeXlJ2T4D2x48IdFvoG/newxDdWvmgfxkuZ/w5oJMKwrCT5Gn0N1r noKR3SUxOOdTNq96Zh4sOvHJQvkDnUGTCLI/GDRJVLSZjeVXrtJwX4E3sq0LUMKP WZ1yzgXKa4++KXB1TcidaXx/sTbJSei/ZMRZ104+kXzhtxUtG1R1+NhRHDxzTFK5 cnu7cK0XQ9XmNSFIGTiBpiR6CZgjMV3xr1BlE16tytO2SkMfjwk7lsPtm66RrL8G wwRSILtnlWZ8B/NPhD0ppjgONxtD+ar7t8xCXdHMQkPIshckirCgGxkYZPNXRSU= =I1ga -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jul 11 19:06:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A57410656D3 for ; Sun, 11 Jul 2010 19:06:02 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 392448FC12 for ; Sun, 11 Jul 2010 19:06:02 +0000 (UTC) Received: by iwn35 with SMTP id 35so4916486iwn.13 for ; Sun, 11 Jul 2010 12:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=khTd4a/I21nidOUk/x0Oua4nY+sWvaEeQN2njDjH+IU=; b=sijzSPB4IApBdZEst/zilPQdcidNgJs7RrLI59zSbVBw48CvDjPQfhv1D+ACGHaxsB euKGzdsW00qffOaZ6iad7YPx5NAfJHxSULaUY5uG9kZ+9+vorimNFTOK7KSuD+Z7Kg4S AcGBM3qsehKHOq+fMEYRZxcycOwSbZcNdrsXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=kzOkOUCTnHhqAmPslCFd9Y+IzyokpgKpetlIHOU8L5nPd2JJL3TMNkfxBFTjUAhxVz cOt9evyDw5xpJtigF+6O1n4nTfsyv8iBx/u5uhQzFxs/wzbt1SEzG+XQNzvhFhgT9Lsd YVPCYx8SNVUgky2owzglXghnqE/OpETtPcDHM= Received: by 10.231.32.134 with SMTP id c6mr12817825ibd.156.1278875161663; Sun, 11 Jul 2010 12:06:01 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id e8sm15629013ibb.14.2010.07.11.12.06.00 (version=SSLv3 cipher=RC4-MD5); Sun, 11 Jul 2010 12:06:00 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C3A1619.5040500@dataix.net> Date: Sun, 11 Jul 2010 15:06:01 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: Christof Schulze References: <4C23BA5B.2020709@FreeBSD.org> <201007111702.10808.christof.schulze@gmx.com> <4C3A15A2.2040309@dataix.net> In-Reply-To: <4C3A15A2.2040309@dataix.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [CFT] ZFS v16 with stat() speedup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2010 19:06:02 -0000 On 07/11/2010 15:04, jhell wrote: > On 07/11/2010 13:02, Christof Schulze wrote: >> Hello, > > >> Am Thursday 24 June 2010 20:04:43 schrieb Martin Matuska: >>> As I have imported some more improvements to the ZFS v15 patch that also >>> target speed, >>> I am now calling for testing of v16 with mainly the following important >>> (post-v16) enhancement (and some related bugfixes): >> Thank you very much for your hard work. Yesterday I set up my system using the >> instructions below and I have had no problems so far. > >> This is an amd64 system with 8GB ram. I am willing to do additional testing if >> wanted but I'd need further instructions on that one. > >> Regards > >> Christof > > > > FYI: This thread is outdated by the [CFT] ZFS v15 thread. ZFS v16 will > not be committed and v15 is now the preferred testing thread. If you > need a copy of the new [CFT] ZFS v15 message let me know and I will > forward it to you happily. > > > Regards, > Located here: http://bit.ly/99A8Fp Regards, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ From owner-freebsd-current@FreeBSD.ORG Sun Jul 11 20:14:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C957F106567B for ; Sun, 11 Jul 2010 20:14:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0ED8FC14 for ; Sun, 11 Jul 2010 20:14:49 +0000 (UTC) Received: (qmail 23270 invoked by uid 399); 11 Jul 2010 20:14:46 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 11 Jul 2010 20:14:46 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C3A2634.5050003@FreeBSD.org> Date: Sun, 11 Jul 2010 13:14:44 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100701 Thunderbird/3.0.5 MIME-Version: 1.0 To: Rene Ladan References: <201007021146.46542.naylor.b.david@gmail.com> <201007021855.42103.naylor.b.david@gmail.com> <201007080826.32764.jhb@freebsd.org> <4C36488A.6030203@freebsd.org> In-Reply-To: <4C36488A.6030203@freebsd.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------040401050506090804000701" Cc: danfe@FreeBSD.org, Christian Zander , David Naylor , Yuri Pankov , freebsd-current@freebsd.org Subject: Re: nvidia-driver crashing kernel on head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2010 20:14:49 -0000 This is a multi-part message in MIME format. --------------040401050506090804000701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/08/10 14:52, Rene Ladan wrote: > On 08-07-2010 22:09, Doug Barton wrote: >> On Thu, 8 Jul 2010, John Baldwin wrote: >> >>> These freezes and panics are due to the driver using a spin mutex >>> instead of a >>> regular mutex for the per-file descriptor event_mtx. If you patch the >>> driver >>> to change it to be a regular mutex I think that should fix the problems. >> >> Can you give an example? :) I don't mind creating a patch for all of >> them if you can illustrate what needs to be changed. >> > See the attached patch In order to use 195.36.15 it was necessary to use the patch Rene sent, the suggestion from jhb previously to remove some locks, plus a bit more. The patch that got it working on HEAD for me (specifically r209633) is attached. With that patch I could start X, and run it for a while, but performance was very poor, even in comparison with the stock nv driver, and it crashed a couple times (although not nearly as bad as previously). So based on other suggestions I tried the newest release version at nvidia, 256.35. Some of the same locking stuff was needed to patch it, a patch for the port which includes the locking patch is also attached. If you are running an amd64 system you'll have to type 'make makesum' after applying this patch to the port. I'm not sure this patch is complete, or what Alexey might want to do with the update, but it does create an accurate plist which means you can cleanly deinstall/pkg_delete when you're done. With 256.35 performance and stability have both been quite good, comparable even to before the the drama started. The only concern I have at this point is that I'm periodically getting a strange sort of "flash" popping up on my screen that I didn't get while I was running the nv driver recently. It looks sort of like the default X background (the tiny gray crosshatch) is popping through for just a split second. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ --------------040401050506090804000701 Content-Type: text/plain; name="nvidia-port-locking-256-35.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="nvidia-port-locking-256-35.diff" Index: Makefile =================================================================== RCS file: /home/pcvs/ports/x11/nvidia-driver/Makefile,v retrieving revision 1.98 diff -u -r1.98 Makefile --- Makefile 24 May 2010 03:01:56 -0000 1.98 +++ Makefile 11 Jul 2010 20:02:47 -0000 @@ -6,7 +6,7 @@ # PORTNAME= nvidia-driver -DISTVERSION?= 195.36.15 +DISTVERSION?= 256.35 PORTREVISION?= 0 # As a reminder it can be overridden CATEGORIES= x11 kld MASTER_SITES= ${MASTER_SITE_NVIDIA} @@ -143,9 +143,6 @@ .endif .if ${NVVERSION} < 1802900 @${REINPLACE_CMD} '/vdpau/d' ${TMPPLIST} -.else - @${MKDIR} ${PREFIX}/include/vdpau - @${LN} -sf ${DOCSDIR}/vdpau*.h ${PREFIX}/include/vdpau .endif .if ${NVVERSION} < 1851829 @${REINPLACE_CMD} '/libcuda/d' ${TMPPLIST} Index: distinfo =================================================================== RCS file: /home/pcvs/ports/x11/nvidia-driver/distinfo,v retrieving revision 1.36 diff -u -r1.36 distinfo --- distinfo 10 Apr 2010 13:40:07 -0000 1.36 +++ distinfo 11 Jul 2010 20:02:47 -0000 @@ -1,15 +1,3 @@ -MD5 (NVIDIA-FreeBSD-x86-195.36.15.tar.gz) = 2537ca726240344c7eaa44857e2b134e -SHA256 (NVIDIA-FreeBSD-x86-195.36.15.tar.gz) = 21fc89fa59e2cc96e560af856a3fa583ce4bfb7975465c71170c64962201e7a1 -SIZE (NVIDIA-FreeBSD-x86-195.36.15.tar.gz) = 25614326 -MD5 (NVIDIA-FreeBSD-x86_64-195.36.15.tar.gz) = 95af03aedc818a3dfd8ae9f289746ba4 -SHA256 (NVIDIA-FreeBSD-x86_64-195.36.15.tar.gz) = d64c664398cb4dade24af6b108e03607614f1f7584c71449230c646c313d0e7e -SIZE (NVIDIA-FreeBSD-x86_64-195.36.15.tar.gz) = 26449559 -MD5 (NVIDIA-FreeBSD-x86-173.14.25.tar.gz) = 1eca3916a9ae86b953f54405e1881774 -SHA256 (NVIDIA-FreeBSD-x86-173.14.25.tar.gz) = c432ed94ce71e297b2d9304d9f34f906b58e2c7c4bc13d8dbac264ed52fd6261 -SIZE (NVIDIA-FreeBSD-x86-173.14.25.tar.gz) = 16682722 -MD5 (NVIDIA-FreeBSD-x86-96.43.16.tar.gz) = 3fc5c2bb537d4a7664d84a7a0df09c7c -SHA256 (NVIDIA-FreeBSD-x86-96.43.16.tar.gz) = 38bf334284dc600d92d8436333c98d5577e34d69456ed71f1cccc75caa6dffcd -SIZE (NVIDIA-FreeBSD-x86-96.43.16.tar.gz) = 11842453 -MD5 (NVIDIA-FreeBSD-x86-71.86.13.tar.gz) = 19000b906225ebd39ca3edc1b0c3c7a5 -SHA256 (NVIDIA-FreeBSD-x86-71.86.13.tar.gz) = 27ae01cd6fe050871f7785c2146b18e74ea882f6262e46dc965bf26061238447 -SIZE (NVIDIA-FreeBSD-x86-71.86.13.tar.gz) = 8066159 +MD5 (NVIDIA-FreeBSD-x86-256.35.tar.gz) = 599908c9ffd8999ab0333cab34ea15a0 +SHA256 (NVIDIA-FreeBSD-x86-256.35.tar.gz) = 897c711acdca188da26868aec510c732d34f415ae621c35e5556ed8de493f26e +SIZE (NVIDIA-FreeBSD-x86-256.35.tar.gz) = 26047458 Index: pkg-plist =================================================================== RCS file: /home/pcvs/ports/x11/nvidia-driver/pkg-plist,v retrieving revision 1.27 diff -u -r1.27 pkg-plist --- pkg-plist 10 Apr 2010 13:40:07 -0000 1.27 +++ pkg-plist 11 Jul 2010 20:02:47 -0000 @@ -10,15 +10,13 @@ @unexec mv -f %D/%%MODULESDIR%%/extensions/XXX-libglx.so.%%%%.%%XSERVVERSION%% %D/%%MODULESDIR%%/extensions/libglx.so @exec mv -f %D/lib/libGL.so.1 %D/lib/XXX-libGL.so.1.%%%%.%%LIBGLVERSION%% @unexec mv -f %D/lib/XXX-libGL.so.1.%%%%.%%LIBGLVERSION%% %D/lib/libGL.so.1 -include/vdpau/vdpau.h -include/vdpau/vdpau_x11.h -@dirrm include/vdpau +lib/libGL.so +lib/libnvidia-glcore.so.1 +lib/libnvidia-glcore.so lib/libnvidia-tls.so.1 lib/libnvidia-tls.so lib/libnvidia-cfg.so.1 lib/libnvidia-cfg.so -lib/libGLcore.so.1 -lib/libGLcore.so lib/libvdpau.so.1 lib/libvdpau.so lib/vdpau/libvdpau_nvidia.so.1 @@ -41,12 +39,10 @@ %%LINUX%%@cwd %%LINUXBASE%% %%LINUX%%usr/lib/libGL.so.%%SHLIB_VERSION%% %%LINUX%%usr/lib/libGL.so.1 -%%LINUX%%usr/lib/libGLcore.so.%%SHLIB_VERSION%% -%%LINUX%%usr/lib/libGLcore.so.1 %%LINUX%%usr/lib/libcuda.so.%%SHLIB_VERSION%% %%LINUX%%usr/lib/libcuda.so.1 +%%LINUX%%usr/lib/libnvidia-glcore.so.%%SHLIB_VERSION%% %%LINUX%%usr/lib/libnvidia-tls.so.%%SHLIB_VERSION%% -%%LINUX%%usr/lib/libnvidia-tls.so.1 %%LINUX%%usr/lib/libvdpau.so.%%SHLIB_VERSION%% %%LINUX%%usr/lib/libvdpau.so.1 %%LINUX%%usr/lib/libvdpau_nvidia.so Index: files/patch-nvidia-locking-256-35 =================================================================== RCS file: files/patch-nvidia-locking-256-35 diff -N files/patch-nvidia-locking-256-35 --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ files/patch-nvidia-locking-256-35 11 Jul 2010 20:02:47 -0000 @@ -0,0 +1,100 @@ +diff -ur NVIDIA-FreeBSD-x86-256.35-port-patched/src/nvidia_ctl.c src/nvidia_ctl.c +--- NVIDIA-FreeBSD-x86-256.35-port-patched/src/nvidia_ctl.c 2010-06-16 18:36:40.000000000 -0700 ++++ src/nvidia_ctl.c 2010-07-11 01:22:55.000000000 -0700 +@@ -53,7 +53,7 @@ + } + + filep->nv = nv; +- mtx_init(&filep->event_mtx, "event_mtx", NULL, (MTX_SPIN | MTX_RECURSE)); ++ mtx_init(&filep->event_mtx, "event_mtx", NULL, (MTX_DEF | MTX_RECURSE)); + STAILQ_INIT(&filep->event_queue); + + nv_lock_api(nv); +@@ -123,7 +123,7 @@ + if (status != 0) + return status; + +- mtx_lock_spin(&filep->event_mtx); ++ mtx_lock(&filep->event_mtx); + et = STAILQ_FIRST(&filep->event_queue); + + if (et == NULL) +@@ -131,7 +131,7 @@ + else + mask = (events & (POLLIN | POLLPRI | POLLRDNORM)); + +- mtx_unlock_spin(&filep->event_mtx); ++ mtx_unlock(&filep->event_mtx); + + return mask; + } +diff -ur NVIDIA-FreeBSD-x86-256.35-port-patched/src/nvidia_dev.c src/nvidia_dev.c +--- NVIDIA-FreeBSD-x86-256.35-port-patched/src/nvidia_dev.c 2010-06-16 18:36:40.000000000 -0700 ++++ src/nvidia_dev.c 2010-07-11 01:22:55.000000000 -0700 +@@ -52,7 +52,7 @@ + } + + filep->nv = nv; +- mtx_init(&filep->event_mtx, "event_mtx", NULL, (MTX_SPIN | MTX_RECURSE)); ++ mtx_init(&filep->event_mtx, "event_mtx", NULL, (MTX_DEF | MTX_RECURSE)); + STAILQ_INIT(&filep->event_queue); + + nv_lock_api(nv); +@@ -123,7 +123,7 @@ + if (status != 0) + return status; + +- mtx_lock_spin(&filep->event_mtx); ++ mtx_lock(&filep->event_mtx); + et = STAILQ_FIRST(&filep->event_queue); + + if (et == NULL) +@@ -131,7 +131,7 @@ + else + mask = (events & (POLLIN | POLLPRI | POLLRDNORM)); + +- mtx_unlock_spin(&filep->event_mtx); ++ mtx_unlock(&filep->event_mtx); + + return mask; + } +diff -ur NVIDIA-FreeBSD-x86-256.35-port-patched/src/nvidia_subr.c src/nvidia_subr.c +--- NVIDIA-FreeBSD-x86-256.35-port-patched/src/nvidia_subr.c 2010-06-16 18:36:40.000000000 -0700 ++++ src/nvidia_subr.c 2010-07-11 01:22:55.000000000 -0700 +@@ -987,9 +987,9 @@ + et->event.hObject = hObject; + et->event.index = index; + +- mtx_lock_spin(&filep->event_mtx); ++ mtx_lock(&filep->event_mtx); + STAILQ_INSERT_TAIL(&filep->event_queue, et, queue); +- mtx_unlock_spin(&filep->event_mtx); ++ mtx_unlock(&filep->event_mtx); + + selwakeup(&filep->event_rsel); + } +@@ -1004,7 +1004,7 @@ + struct nvidia_filep *filep = file; + struct nvidia_event *et; + +- mtx_lock_spin(&filep->event_mtx); ++ mtx_lock(&filep->event_mtx); + et = STAILQ_FIRST(&filep->event_queue); + + if (et != NULL) { +@@ -1013,13 +1013,13 @@ + STAILQ_REMOVE(&filep->event_queue, et, nvidia_event, queue); + *pending = !STAILQ_EMPTY(&filep->event_queue); + +- mtx_unlock_spin(&filep->event_mtx); ++ mtx_unlock(&filep->event_mtx); + free(et, M_NVIDIA); + + return RM_OK; + } + +- mtx_unlock_spin(&filep->event_mtx); ++ mtx_unlock(&filep->event_mtx); + return RM_ERROR; + } + --------------040401050506090804000701 Content-Type: text/plain; name="patch-nvidia-locking-195-36-15" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-nvidia-locking-195-36-15" diff -ur NVIDIA-FreeBSD-x86-195.36.15-port-patched/src/nvidia_ctl.c src/nvidia_ctl.c --- NVIDIA-FreeBSD-x86-195.36.15-port-patched/src/nvidia_ctl.c 2010-03-12 09:21:51.000000000 -0800 +++ src/nvidia_ctl.c 2010-07-10 16:36:49.000000000 -0700 @@ -54,7 +54,7 @@ } filep->nv = nv; - mtx_init(&filep->event_mtx, "event_mtx", NULL, (MTX_SPIN | MTX_RECURSE)); + mtx_init(&filep->event_mtx, "event_mtx", NULL, (MTX_DEF | MTX_RECURSE)); STAILQ_INIT(&filep->event_queue); nv_lock_api(nv); @@ -126,7 +126,7 @@ if (status != 0) return status; - mtx_lock_spin(&filep->event_mtx); + mtx_lock(&filep->event_mtx); et = STAILQ_FIRST(&filep->event_queue); if (et == NULL) @@ -134,7 +134,7 @@ else mask = (events & (POLLIN | POLLPRI | POLLRDNORM)); - mtx_unlock_spin(&filep->event_mtx); + mtx_unlock(&filep->event_mtx); return mask; } diff -ur NVIDIA-FreeBSD-x86-195.36.15-port-patched/src/nvidia_dev.c src/nvidia_dev.c --- NVIDIA-FreeBSD-x86-195.36.15-port-patched/src/nvidia_dev.c 2010-03-12 09:21:51.000000000 -0800 +++ src/nvidia_dev.c 2010-07-10 16:36:49.000000000 -0700 @@ -52,7 +52,7 @@ } filep->nv = nv; - mtx_init(&filep->event_mtx, "event_mtx", NULL, (MTX_SPIN | MTX_RECURSE)); + mtx_init(&filep->event_mtx, "event_mtx", NULL, (MTX_DEF | MTX_RECURSE)); STAILQ_INIT(&filep->event_queue); nv_lock_api(nv); @@ -125,7 +125,7 @@ if (status != 0) return status; - mtx_lock_spin(&filep->event_mtx); + mtx_lock(&filep->event_mtx); et = STAILQ_FIRST(&filep->event_queue); if (et == NULL) @@ -133,7 +133,7 @@ else mask = (events & (POLLIN | POLLPRI | POLLRDNORM)); - mtx_unlock_spin(&filep->event_mtx); + mtx_unlock(&filep->event_mtx); return mask; } diff -ur NVIDIA-FreeBSD-x86-195.36.15-port-patched/src/nvidia_subr.c src/nvidia_subr.c --- NVIDIA-FreeBSD-x86-195.36.15-port-patched/src/nvidia_subr.c 2010-03-12 09:21:52.000000000 -0800 +++ src/nvidia_subr.c 2010-07-10 16:37:43.000000000 -0700 @@ -967,9 +967,9 @@ et->event.hObject = hObject; et->event.index = index; - mtx_lock_spin(&filep->event_mtx); + mtx_lock(&filep->event_mtx); STAILQ_INSERT_TAIL(&filep->event_queue, et, queue); - mtx_unlock_spin(&filep->event_mtx); + mtx_unlock(&filep->event_mtx); selwakeup(&filep->event_rsel); } @@ -984,7 +984,7 @@ struct nvidia_filep *filep = file; struct nvidia_event *et; - mtx_lock_spin(&filep->event_mtx); + mtx_lock(&filep->event_mtx); et = STAILQ_FIRST(&filep->event_queue); if (et != NULL) { @@ -993,13 +993,13 @@ STAILQ_REMOVE(&filep->event_queue, et, nvidia_event, queue); *pending = !STAILQ_EMPTY(&filep->event_queue); - mtx_unlock_spin(&filep->event_mtx); + mtx_unlock(&filep->event_mtx); free(et, M_NVIDIA); return RM_OK; } - mtx_unlock_spin(&filep->event_mtx); + mtx_unlock(&filep->event_mtx); return RM_ERROR; } @@ -1301,9 +1301,6 @@ for (i = 0; i < count; i++) { pte_array[i] = at->pte_array[i].physical_address; - vm_page_lock_queues(); - vm_page_wire(PHYS_TO_VM_PAGE(pte_array[i])); - vm_page_unlock_queues(); sglist_append_phys(at->sg_list, pte_array[i], PAGE_SIZE); } @@ -1365,9 +1362,6 @@ os_flush_cpu_cache(); for (i = 0; i < count; i++) { - vm_page_lock_queues(); - vm_page_unwire(PHYS_TO_VM_PAGE(at->pte_array[i].physical_address), 0); - vm_page_unlock_queues(); kmem_free(kernel_map, at->pte_array[i].virtual_address, PAGE_SIZE); malloc_type_freed(M_NVIDIA, PAGE_SIZE); --------------040401050506090804000701-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 00:07:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A422106566C; Mon, 12 Jul 2010 00:07:56 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 075B68FC08; Mon, 12 Jul 2010 00:07:55 +0000 (UTC) Received: by gyd8 with SMTP id 8so2825012gyd.13 for ; Sun, 11 Jul 2010 17:07:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.44.9 with SMTP id r9mr14233367anr.152.1278893275124; Sun, 11 Jul 2010 17:07:55 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.100.110.6 with HTTP; Sun, 11 Jul 2010 17:07:55 -0700 (PDT) In-Reply-To: <201007072113.16320.hselasky@c2i.net> References: <201007072113.16320.hselasky@c2i.net> Date: Mon, 12 Jul 2010 12:07:55 +1200 X-Google-Sender-Auth: UH_NqquzGXOopjgtBV_kVmyCbls Message-ID: From: Andrew Thompson To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: Sam Leffler , PseudoCylon , freebsd-usb@freebsd.org, freebsd-current@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 00:07:56 -0000 On 8 July 2010 07:13, Hans Petter Selasky wrote: > Hi, > > When supplying wpa_supplicant.conf with incorrect passwords, but a valid SSID, > I have seen kernel panics several times when using USB based WLAN dongles. > When only supplying a valid password, no panic has been seen. > > How to reproduce: > > 1) configure invalid password > 2) wpa_cli: reconfigure > 3) configure valid password > 4) wpa_cli: reconfigure > 5) goto 1 > > The USB commands which are executed inside the newstate callback usually take > very little time, but still not as little time as PCI read/writes. I've forced > slower operation in the newstate callback, and can reproduce warning printouts > from the IEEE802.11 layer in FreeBSD. Try to apply the following patch to your > USB code: > > http://p4web.freebsd.org/@@180604?ac=10 > > In my opinion the deferring of all states to a single task is wrong. There > should be at least one task per possible state, and the queuing mechanism > should follow the last-queued is last executed rule. This is not the case with > the task-queue mechanism in the kernel. This turned out to be refcounting of the ieee80211_node struct which was causing this panic. vap->iv_bss can be freed at any time so all users of it need to bump the refcount to use it safely. This patch should fix the panic in the rum driver. http://people.freebsd.org/~thompsa/rum_node_refcnt.diff There are other places where it is still an issue such as the ieee80211_tx_mgt_timeout callout which havnt been addressed yet, and of course all other ieee80211 drivers. Andrew From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 05:23:42 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBC8A106564A for ; Mon, 12 Jul 2010 05:23:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5025F8FC17 for ; Mon, 12 Jul 2010 05:23:41 +0000 (UTC) Received: (qmail 10758 invoked by uid 399); 12 Jul 2010 05:23:40 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Jul 2010 05:23:40 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C3AA6D7.7070904@FreeBSD.org> Date: Sun, 11 Jul 2010 22:23:35 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100701 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Interactivity problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 05:23:42 -0000 Howdy, I use -current on my laptop as my regular X platform, and for the last few months I've been noticing that interactivity problems have been getting a lot worse, by which I mean that if I have something running in the background that is either disk or cpu intensive, anything else I try to do on the system suffers. The most usual symptom is painfully slow refresh times on windows, skipping audio, jumpy mouse, etc. These problems persist even if I nice the hungry process. My kernel conf is a typical GENERIC minus stuff I don't have. You can see the diff to GENERIC at http://people.freebsd.org/~dougb/kernel-conf.diff My loader.conf: umass_load="yes" coretemp_load="yes" linux_load="YES" nvidia_load="YES" if_wpi_load="YES" /etc/sysctl.conf debug.debugger_on_panic=0 kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules No malloc.conf or libmap.conf. The only diff in my src tree is a patch from mav vs. his latest timer update. All in all this is a very GENERIC system, pardon the pun. :) Is anyone else seeing this problem? Does anyone have suggestions? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 05:26:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE2291065673 for ; Mon, 12 Jul 2010 05:26:12 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF3D8FC13 for ; Mon, 12 Jul 2010 05:26:12 +0000 (UTC) Received: (qmail 13782 invoked by uid 399); 12 Jul 2010 05:26:11 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Jul 2010 05:26:11 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C3AA768.3070605@FreeBSD.org> Date: Sun, 11 Jul 2010 22:26:00 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100701 Thunderbird/3.0.5 MIME-Version: 1.0 To: Alexander Motin References: <20100710074455.4E516818130@smtp3-g21.free.fr> <4C38B7F4.8040109@FreeBSD.org> <4C399CD2.7010804@FreeBSD.org> In-Reply-To: <4C399CD2.7010804@FreeBSD.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: raoul , freebsd-current@freebsd.org Subject: Re: panic on dell laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 05:26:12 -0000 On 07/11/10 03:28, Alexander Motin wrote: > Doug Barton wrote: >> Try backing up to svn r209633 and see if you can boot. What you're >> describing is identical to a panic I had starting with the next >> revision, also on a Dell laptop. > > Please try attached patch against HEAD. This worked for me, thanks. :) I updated to r209914 first, then applied your patch. Up for a little more than an hour now, no problems. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 05:52:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FE79106566C; Mon, 12 Jul 2010 05:52:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 58A4A8FC1C; Mon, 12 Jul 2010 05:52:00 +0000 (UTC) Received: by iwn35 with SMTP id 35so5345329iwn.13 for ; Sun, 11 Jul 2010 22:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=k9ynMaNZ5JFw1SJbLubQb9RAV2YlW9we6i0H597D/bc=; b=dOTWaRj6QjHZKjU+hDqKhysZaRSdMW8qPCU/BkOEvr6/kovwlwQ8XyBeoWYbEiOdOG WbY0q1jAS/5O+E4CTUofYC+f4rTvQIqeU5UTqruGdmS1O7bKkkoiaB8N0uFdu0WWd/HI MhPlTlkn7iVK0DP99DogXY4IVej48UfRx01Hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=f5ADWW5d+X3imiMnZY8jJ6SOfeTMCosIkI7wUKoqxtM4AEFd1t2UdJusQQih2LN3ts vM7tTENGv1+Laz0Ph8aexQz724eVWbEamE9jtcemLgJi+vcp+NW92fbOlMzjaPitgy6S yJeUrXh2ZVl+2Om3mlw0IDzZmhF3cW3ymzR4c= MIME-Version: 1.0 Received: by 10.231.39.134 with SMTP id g6mr13754061ibe.8.1278913918392; Sun, 11 Jul 2010 22:51:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.152.3 with HTTP; Sun, 11 Jul 2010 22:51:58 -0700 (PDT) Date: Mon, 12 Jul 2010 13:51:58 +0800 X-Google-Sender-Auth: Y0h4Adjyn3-pqb4ZQiQQ0Zu71hc Message-ID: From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net Subject: Atheros AR9160 users: step up please! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 05:52:02 -0000 Hi, Are there any AR9160 users out there? Please let me know if you are and you're willing to help me test/debug issues. Thanks! Adrian From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 06:15:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6382810656BD; Mon, 12 Jul 2010 06:15:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 5C3158FC2A; Mon, 12 Jul 2010 06:15:08 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=HRj3ij7MtkgA:10 a=UBIxAjGgU1YA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=5Wr784wakqxuFxy-StwA:9 a=Dv-sdMSPG1GpADYkqOE7o0VGqmIA:4 a=wPNLvfGTeEIA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1373861581; Mon, 12 Jul 2010 08:15:06 +0200 From: Hans Petter Selasky To: Andrew Thompson Date: Mon, 12 Jul 2010 08:12:11 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.1-PRERELEASE; KDE/4.3.4; amd64; ; ) References: <201007072113.16320.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007120812.11225.hselasky@c2i.net> Cc: Sam Leffler , PseudoCylon , freebsd-usb@freebsd.org, freebsd-current@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 06:15:09 -0000 On Monday 12 July 2010 02:07:55 Andrew Thompson wrote: > This turned out to be refcounting of the ieee80211_node struct which > was causing this panic. vap->iv_bss can be freed at any time so all > users of it need to bump the refcount to use it safely. > > This patch should fix the panic in the rum driver. > http://people.freebsd.org/~thompsa/rum_node_refcnt.diff > > There are other places where it is still an issue such as the > ieee80211_tx_mgt_timeout callout which havnt been addressed yet, and > of course all other ieee80211 drivers. > I will give your patch a try later today. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 06:17:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03D831065670; Mon, 12 Jul 2010 06:17:02 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id C086E8FC12; Mon, 12 Jul 2010 06:17:01 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o6C6H1cw043675; Sun, 11 Jul 2010 23:17:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o6C6H1oI043674; Sun, 11 Jul 2010 23:17:01 -0700 (PDT) (envelope-from sgk) Date: Sun, 11 Jul 2010 23:17:01 -0700 From: Steve Kargl To: Doug Barton Message-ID: <20100712061701.GA43659@troutmask.apl.washington.edu> References: <4C3AA6D7.7070904@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C3AA6D7.7070904@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Interactivity problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 06:17:02 -0000 On Sun, Jul 11, 2010 at 10:23:35PM -0700, Doug Barton wrote: > > Is anyone else seeing this problem? Does anyone have suggestions? > option SCHED_4BSD -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 06:27:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D93D1065670 for ; Mon, 12 Jul 2010 06:27:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id A33898FC15 for ; Mon, 12 Jul 2010 06:27:46 +0000 (UTC) Received: (qmail 1712 invoked by uid 399); 12 Jul 2010 06:27:45 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Jul 2010 06:27:45 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C3AB5DD.9060909@FreeBSD.org> Date: Sun, 11 Jul 2010 23:27:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100701 Thunderbird/3.0.5 MIME-Version: 1.0 To: Alexander Motin References: <20100710074455.4E516818130@smtp3-g21.free.fr> <4C38B7F4.8040109@FreeBSD.org> <4C399CD2.7010804@FreeBSD.org> <4C3AA768.3070605@FreeBSD.org> In-Reply-To: <4C3AA768.3070605@FreeBSD.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: raoul , freebsd-current@freebsd.org Subject: Re: panic on dell laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 06:27:47 -0000 On 07/11/10 22:26, Doug Barton wrote: > On 07/11/10 03:28, Alexander Motin wrote: >> Doug Barton wrote: >>> Try backing up to svn r209633 and see if you can boot. What you're >>> describing is identical to a panic I had starting with the next >>> revision, also on a Dell laptop. >> >> Please try attached patch against HEAD. > > This worked for me, thanks. :) I updated to r209914 first, then applied > your patch. Up for a little more than an hour now, no problems. Blah, spoke too soon. After having been up for a few hours the system froze. I hard-booted it, fsck'ed, then it froze again during boot. The nvidia driver seems to have something to do with it, even though I recompiled it against the new kernel sources. I've gone back to r209633, which I ran all day yesterday and left running through last evening without any problems, even with the new nvidia driver. Can't say for sure that your change is what's causing the problem though ... Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 06:30:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 788F6106564A; Mon, 12 Jul 2010 06:30:24 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D01FA8FC0A; Mon, 12 Jul 2010 06:30:23 +0000 (UTC) Received: by fxm13 with SMTP id 13so2263546fxm.13 for ; Sun, 11 Jul 2010 23:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=URgskkAmIVmtmGiBCQfEIrT/M0D/s3ty5wLmbIPFYWs=; b=J8tVOpBqFUOV74XSl1SHhmBbt5UukK6+rSGYBBNcowv/tAqVN63G2ZJJOly8Mnagex a/v0ExpS7ZLoWAa2UU4cczCgXrKQIH9VqYEXHgsbtdhpGgQjCeEuLaV49N1dqGaeZBFO d6Z640wCx160ZhbkMv+4xrCbcBGlBkgeyWQtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ZEWECLpD8BnYimsXq0PRRp6Sxz88z+6An82clIp7YuxR70SXHSf8RC8KTSd1hyzeXo AcKdfgrn/Qk/ku6WtkEqjN+JIruYxqt2ltDKKy8Wcm2uwl15k17wMhoQJcb5Kffj+6K+ PWAko4sZYM4cuvq1n7X/HdIwx0u4nHLK6cPcI= Received: by 10.86.72.4 with SMTP id u4mr3530501fga.23.1278916222887; Sun, 11 Jul 2010 23:30:22 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id w16sm8498035fao.46.2010.07.11.23.30.21 (version=SSLv3 cipher=RC4-MD5); Sun, 11 Jul 2010 23:30:22 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C3AB648.7060107@FreeBSD.org> Date: Mon, 12 Jul 2010 09:29:28 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Doug Barton References: <20100710074455.4E516818130@smtp3-g21.free.fr> <4C38B7F4.8040109@FreeBSD.org> <4C399CD2.7010804@FreeBSD.org> <4C3AA768.3070605@FreeBSD.org> <4C3AB5DD.9060909@FreeBSD.org> In-Reply-To: <4C3AB5DD.9060909@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: raoul , freebsd-current@freebsd.org Subject: Re: panic on dell laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 06:30:24 -0000 Doug Barton wrote: > On 07/11/10 22:26, Doug Barton wrote: >> On 07/11/10 03:28, Alexander Motin wrote: >>> Doug Barton wrote: >>>> Try backing up to svn r209633 and see if you can boot. What you're >>>> describing is identical to a panic I had starting with the next >>>> revision, also on a Dell laptop. >>> Please try attached patch against HEAD. >> This worked for me, thanks. :) I updated to r209914 first, then applied >> your patch. Up for a little more than an hour now, no problems. > > Blah, spoke too soon. After having been up for a few hours the system > froze. I hard-booted it, fsck'ed, then it froze again during boot. The > nvidia driver seems to have something to do with it, even though I > recompiled it against the new kernel sources. I've gone back to r209633, > which I ran all day yesterday and left running through last evening > without any problems, even with the new nvidia driver. > > Can't say for sure that your change is what's causing the problem though ... I also have doubts it is related. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 06:33:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C94471065674 for ; Mon, 12 Jul 2010 06:33:32 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6F23C8FC19 for ; Mon, 12 Jul 2010 06:33:32 +0000 (UTC) Received: (qmail 11227 invoked by uid 399); 12 Jul 2010 06:33:31 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Jul 2010 06:33:31 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C3AB737.30201@FreeBSD.org> Date: Sun, 11 Jul 2010 23:33:27 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100701 Thunderbird/3.0.5 MIME-Version: 1.0 To: Alexander Motin References: <20100710074455.4E516818130@smtp3-g21.free.fr> <4C38B7F4.8040109@FreeBSD.org> <4C399CD2.7010804@FreeBSD.org> <4C3AA768.3070605@FreeBSD.org> <4C3AB5DD.9060909@FreeBSD.org> <4C3AB648.7060107@FreeBSD.org> In-Reply-To: <4C3AB648.7060107@FreeBSD.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: raoul , freebsd-current@freebsd.org Subject: Re: panic on dell laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 06:33:32 -0000 On 07/11/10 23:29, Alexander Motin wrote: > Doug Barton wrote: >> On 07/11/10 22:26, Doug Barton wrote: >>> On 07/11/10 03:28, Alexander Motin wrote: >>>> Doug Barton wrote: >>>>> Try backing up to svn r209633 and see if you can boot. What you're >>>>> describing is identical to a panic I had starting with the next >>>>> revision, also on a Dell laptop. >>>> Please try attached patch against HEAD. >>> This worked for me, thanks. :) I updated to r209914 first, then applied >>> your patch. Up for a little more than an hour now, no problems. >> >> Blah, spoke too soon. After having been up for a few hours the system >> froze. I hard-booted it, fsck'ed, then it froze again during boot. The >> nvidia driver seems to have something to do with it, even though I >> recompiled it against the new kernel sources. I've gone back to r209633, >> which I ran all day yesterday and left running through last evening >> without any problems, even with the new nvidia driver. >> >> Can't say for sure that your change is what's causing the problem though ... > > I also have doubts it is related. I'll try a binary search to narrow it down, it's just kind of difficult given that the problem doesn't manifest till after the system has been up for a while. Thanks, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 06:40:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FD44106572A for ; Mon, 12 Jul 2010 06:40:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 05CEB8FC31 for ; Mon, 12 Jul 2010 06:40:10 +0000 (UTC) Received: (qmail 21842 invoked by uid 399); 12 Jul 2010 06:40:09 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Jul 2010 06:40:09 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C3AB8C3.8030401@FreeBSD.org> Date: Sun, 11 Jul 2010 23:40:03 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100701 Thunderbird/3.0.5 MIME-Version: 1.0 To: Steve Kargl References: <4C3AA6D7.7070904@FreeBSD.org> <20100712061701.GA43659@troutmask.apl.washington.edu> In-Reply-To: <20100712061701.GA43659@troutmask.apl.washington.edu> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Interactivity problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 06:40:11 -0000 On 07/11/10 23:17, Steve Kargl wrote: > On Sun, Jul 11, 2010 at 10:23:35PM -0700, Doug Barton wrote: >> >> Is anyone else seeing this problem? Does anyone have suggestions? >> > > option SCHED_4BSD I'll give that a try, thanks. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 08:40:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8B3D106566B for ; Mon, 12 Jul 2010 08:40:00 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1148FC0C for ; Mon, 12 Jul 2010 08:40:00 +0000 (UTC) Received: by fxm13 with SMTP id 13so2318216fxm.13 for ; Mon, 12 Jul 2010 01:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type; bh=sLe4khpjrkuGz0T9BZD3lC/qBvM/hZDereOcKpD0GMU=; b=XQN34CVLx4aB6Gr3981XMKVj7h/r4GZlK5DOroq5IRPCqk7IxK8IAFeubrNjxoF8lP V8rfIqh7yVy1CAvPEmGcGAWP0y1URuK4WrU+VQlITF0VgOpiDZBBW0oH9L4hxe9jsEHo aJB6P4RQxLfmy0cqGEiMh1eHr/Bve8ltenz3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; b=rbHd0x8Eme0dr1kAYoC3Iyv1XMtPp8DOBEnntMwV6XI/5KHonVY7d5K2j1TJPOYHBD 3eDOQY+fznRux9pZluAHlzxhMxW9HhtFopbYVRWoRFx4aGTRK6BSZjDWeb7Fp1/sWz8F jx4bj6rQFxFUO//lxvr8WU0cxpIFO2o6dVD2o= Received: by 10.223.110.73 with SMTP id m9mr11054098fap.39.1278923999311; Mon, 12 Jul 2010 01:39:59 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id b36sm3414618faq.39.2010.07.12.01.39.57 (version=SSLv3 cipher=RC4-MD5); Mon, 12 Jul 2010 01:39:58 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C3AD4A8.602@FreeBSD.org> Date: Mon, 12 Jul 2010 11:39:04 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: FreeBSD-Current X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------030508080806000401030205" Subject: [patch] Clocks on PC98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 08:40:01 -0000 This is a multi-part message in MIME format. --------------030508080806000401030205 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Hi. I've made a patch to unify PC98 event timer code with the rest of x86. Could somebody test it on that hardware, as all I can say now is that it builds. I have no idea about ISA PNP on PC98, so if it doesn't report timer presence, it may be needed to add to device.hints lines like: hint.attimer.0.at="isa" hint.attimer.0.port="0x71" hint.attimer.0.irq="0" -- Alexander Motin --------------030508080806000401030205 Content-Type: text/plain; name="clock.pc98.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="clock.pc98.patch" diff -ruNp --exclude .svn --exclude compile /storage/head/sys/conf/files.pc98 sys/conf/files.pc98 --- /storage/head/sys/conf/files.pc98 2010-06-09 08:33:25.000000000 +0300 +++ sys/conf/files.pc98 2010-07-12 11:02:29.000000000 +0300 @@ -227,7 +227,6 @@ libkern/udivdi3.c standard libkern/umoddi3.c standard pc98/apm/apm_bioscall.S optional apm pc98/cbus/cbus_dma.c optional isa -pc98/cbus/clock.c standard pc98/cbus/fdc.c optional fdc pc98/cbus/fdc_cbus.c optional fdc isa pc98/cbus/gdc.c optional gdc @@ -253,8 +252,11 @@ pc98/pc98/pc98_machdep.c standard # x86 shared code between IA32, AMD64 and PC98 architectures # x86/isa/atpic.c optional atpic +x86/isa/clock.c standard x86/isa/isa.c optional isa x86/x86/io_apic.c optional apic x86/x86/local_apic.c optional apic x86/x86/mca.c standard x86/x86/msi.c optional apic pci +x86/x86/timeevents.c standard + diff -ruNp --exclude .svn --exclude compile /storage/head/sys/x86/isa/clock.c sys/x86/isa/clock.c --- /storage/head/sys/x86/isa/clock.c 2010-07-12 09:46:16.000000000 +0300 +++ sys/x86/isa/clock.c 2010-07-12 11:16:37.000000000 +0300 @@ -66,9 +66,17 @@ __FBSDID("$FreeBSD: head/sys/x86/isa/clo #include #include +#ifdef PC98 +#include +#else #include +#endif #ifdef DEV_ISA +#ifdef PC98 +#include +#else #include +#endif #include #endif @@ -78,8 +86,12 @@ __FBSDID("$FreeBSD: head/sys/x86/isa/clo int clkintr_pending; #ifndef TIMER_FREQ +#ifdef PC98 +#define TIMER_FREQ 2457600 +#else #define TIMER_FREQ 1193182 #endif +#endif u_int i8254_freq = TIMER_FREQ; TUNABLE_INT("hw.i8254.freq", &i8254_freq); int i8254_max_count; @@ -150,8 +162,11 @@ timer_spkr_acquire(void) { int mode; +#ifdef PC98 + mode = TIMER_SEL1 | TIMER_SQWAVE | TIMER_16BIT; +#else mode = TIMER_SEL2 | TIMER_SQWAVE | TIMER_16BIT; - +#endif if (timer2_state != RELEASED) return (-1); timer2_state = ACQUIRED; @@ -163,7 +178,11 @@ timer_spkr_acquire(void) * and this is probably good enough for timer2, so we aren't as * careful with it as with timer0. */ +#ifdef PC98 + outb(TIMER_MODE, TIMER_SEL1 | (mode & 0x3f)); +#else outb(TIMER_MODE, TIMER_SEL2 | (mode & 0x3f)); +#endif ppi_spkr_on(); /* enable counter2 output to speaker */ return (0); } @@ -175,7 +194,11 @@ timer_spkr_release(void) if (timer2_state != ACQUIRED) return (-1); timer2_state = RELEASED; +#ifdef PC98 + outb(TIMER_MODE, TIMER_SEL1 | TIMER_SQWAVE | TIMER_16BIT); +#else outb(TIMER_MODE, TIMER_SEL2 | TIMER_SQWAVE | TIMER_16BIT); +#endif ppi_spkr_off(); /* disable counter2 output to speaker */ return (0); } @@ -293,7 +316,11 @@ DELAY(int n) while (ticks_left > 0) { #ifdef KDB if (kdb_active) { +#ifdef PC98 + outb(0x5f, 0); +#else inb(0x84); +#endif tick = prev_tick - 1; if (tick <= 0) tick = i8254_max_count; @@ -377,7 +404,9 @@ timer_restore(void) { i8254_restore(); /* restore i8254_freq and hz */ +#ifndef PC98 atrtc_restore(); /* reenable RTC interrupts */ +#endif } #endif @@ -387,6 +416,10 @@ i8254_init(void) { mtx_init(&clock_lock, "clk", NULL, MTX_SPIN | MTX_NOPROFILE); +#ifdef PC98 + if (pc98_machine_type & M_8M) + i8254_freq = 1996800L; /* 1.9968 MHz */ +#endif set_i8254_freq(i8254_freq, 0); } --------------030508080806000401030205-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 10:00:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 756C41065670; Mon, 12 Jul 2010 10:00:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0CC8FC13; Mon, 12 Jul 2010 10:00:04 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o6C9xudB097008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2010 12:59:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o6C9xuJK036884; Mon, 12 Jul 2010 12:59:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6C9xucM036883; Mon, 12 Jul 2010 12:59:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Jul 2010 12:59:56 +0300 From: Kostik Belousov To: mav@freebsd.org Message-ID: <20100712095956.GB2381@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_40, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org Subject: ATA-related LORs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 10:00:06 -0000 --H1spWtNR+x+ondvy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, on the HEAD r209908, I see a lot of LORs at the boot. It seems that mutex called "ATA state lock" is held over the large period of kernel initialization. After the system booted, it seems to operate properly. atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 1.1 on pci0 ata0: on atapci0 lock order reversal: (sleepable after non-sleepable) 1st 0xc1447374 ATA state lock (ATA state lock) @ /usr/home/kostik/build/bsd/DEV/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c:188 2nd 0xc0ad6a10 ACPI root bus (ACPI root bus) @ /usr/home/kostik/build/bsd/DEV/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:1169 KDB: stack backtrace: db_trace_self_wrapper(c06fd4c5,c0c206c8,c050d3b5,c04fc5eb,c07009a2,...) at 0xc043e016 = db_trace_self_wrapper+0x26 kdb_backtrace(c04fc5eb,c07009a2,c142add8,c1429920,c0c20724,...) at 0xc04f8489 = kdb_backtrace+0x29 _witness_debugger(c07009a2,c0ad6a10,c0acf717,c1429920,c0aceb11,...) at 0xc050d3b5 = _witness_debugger+0x25 witness_checkorder(c0ad6a10,9,c0aceb11,491,0,...) at 0xc050e5fb = witness_checkorder+0x82b _sx_xlock(c0ad6a10,0,c0aceb11,491,c0d7c888,...) at 0xc04ce773 = _sx_xlock+0x83 acpi_alloc_resource(c1476680,c147d700,1,c0c20920,e,e,1,6) at 0xc0aaddc4 = acpi_alloc_resource+0x74 bus_generic_alloc_resource(c147dc80,c147d700,1,c0c20920,e,...) at 0xc04f46be = bus_generic_alloc_resource+0x7e pci_alloc_resource(c14b8a80,c147d700,1,c0c20920,e,...) at 0xc044c447 = pci_alloc_resource+0x97 ata_pci_alloc_resource(c14b8c00,c147d700,1,c0c20920,0,ffffffff,1,6) at 0xc0a03883 = ata_pci_alloc_resource+0x153 bus_alloc_resource(c147d700,1,c0c20920,0,ffffffff,...) at 0xc04f437c = bus_alloc_resource+0x7c ata_attach(c147d700,c147f85c,c0732108,c06fcbf3,80000000,...) at 0xc09f5f16 = ata_attach+0x226 device_attach(c147d700,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d700,2,c0c209d4,c0a046a4,c14b8c00,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8c00,1,1,0,ffffffff,...) at 0xc04f3f88 = bus_generic_attach+0x28 ata_pci_attach(c14b8c00,c148485c,c0732108,c06fcbf3,80000000,...) at 0xc0a046a4 = ata_pci_attach+0x174 device_attach(c14b8c00,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8c00,c147dc80,c0c20a78,c0ab178b,c14b8a80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8a80,c1448900,1,c0ab11e0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pci_attach(c14b8a80,c149505c,c0732108,c06fcbf3,80000000,...) at 0xc0ab178b = acpi_pci_attach+0x17b device_attach(c14b8a80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8a80,c1476680,c0c20b14,c0ab1b06,c147dc80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147dc80,c0acfd29,0,c0c20b04,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pcib_attach(c147dc80,c14b91f4,0,c0c20b34,2,...) at 0xc0ab1b06 = acpi_pcib_attach+0x1b6 acpi_pcib_acpi_attach(c147dc80,c149305c,c0732108,c06fcbf3,80000000,...) at 0xc0ab2781 = acpi_pcib_acpi_attach+0x221 device_attach(c147dc80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147dc80,1,c0c20c34,c0aaf13a,c1476680,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c1476680,c1476680,c0731f98,c0aaf6f0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_attach(c1476680,c149705c,c0732108,c06fcbf3,80000000,...) at 0xc0aaf13a = acpi_attach+0xb1a device_attach(c1476680,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c1476680,c14203c5,c0c20ce8,c04f3357,c147d080,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147d080,c14b105c,c0732108,c06fcbf3,80000000,...) at 0xc04f3f88 = bus_generic_attach+0x28 device_attach(c147d080,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d080,c1463880,c1463880,c14075a0,c1463880,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_new_pass(c1463880,c1444800,c0732038,c14409f0,fffffff,...) at 0xc04f4255 = bus_generic_new_pass+0xd5 bus_set_pass(7fffffff,c0c20d5c,c069b93c,fffffff,c0c20d78,...) at 0xc04f2011 = bus_set_pass+0x81 root_bus_configure(fffffff,c0c20d78,c047b7a6,0,c1ec00,...) at 0xc04f2062 = root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc069b93c = configure+0xc mi_startup() at 0xc047b7a6 = mi_startup+0xa6 begin() at 0xc04385b5 = begin+0x2c uma_zalloc_arg: zone "64" with the following non-sleepable locks held: exclusive sleep mutex ATA state lock (ATA state lock) r = 0 (0xc1447374) locked @ /usr/home/kostik/build/bsd/DEV/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c:188 KDB: stack backtrace: db_trace_self_wrapper(c06fd4c5,c0c20650,c050d3b5,bc,1,...) at 0xc043e016 = db_trace_self_wrapper+0x26 kdb_backtrace(bc,1,ffffffff,c08b85ac,c0c20688,...) at 0xc04f8489 = kdb_backtrace+0x29 _witness_debugger(c06fff4e,c0c2069c,4,1,0,...) at 0xc050d3b5 = _witness_debugger+0x25 witness_warn(5,0,c0718d1b,c07019ae,c07762d0,...) at 0xc050e901 = witness_warn+0x201 uma_zalloc_arg(c0d7ba00,0,102,2,602,...) at 0xc066a87b = uma_zalloc_arg+0x8b malloc(3c,c0737c84,102,c06fdf22,c1448ce0,...) at 0xc04b0b96 = malloc+0xe6 intr_event_add_handler(c1476000,c14c5c60,0,c09f6040,c1447200,...) at 0xc049b29f = intr_event_add_handler+0x4f intr_add_handler(c14c5c60,e,0,c09f6040,c1447200,...) at 0xc06a6abd = intr_add_handler+0x6d nexus_setup_intr(c147d080,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc06ae0dd = nexus_setup_intr+0x8d bus_generic_setup_intr(c1476680,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c147dc80,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c14b8a80,c147d700,c14c8540,602,0,...) at 0xc04f0a9e = bus_generic_setup_intr+0x7e pci_setup_intr(c14b8a80,c147d700,c14c8540,602,0,...) at 0xc04498fb = pci_setup_intr+0x4b bus_setup_intr(c147d700,c14c8540,602,0,c09f6040,...) at 0xc04f3561 = bus_setup_intr+0x81 ata_attach(c147d700,c147f85c,c0732108,c06fcbf3,80000000,...) at 0xc09f5f97 = ata_attach+0x2a7 device_attach(c147d700,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d700,2,c0c209d4,c0a046a4,c14b8c00,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8c00,1,1,0,ffffffff,...) at 0xc04f3f88 = bus_generic_attach+0x28 ata_pci_attach(c14b8c00,c148485c,c0732108,c06fcbf3,80000000,...) at 0xc0a046a4 = ata_pci_attach+0x174 device_attach(c14b8c00,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8c00,c147dc80,c0c20a78,c0ab178b,c14b8a80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8a80,c1448900,1,c0ab11e0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pci_attach(c14b8a80,c149505c,c0732108,c06fcbf3,80000000,...) at 0xc0ab178b = acpi_pci_attach+0x17b device_attach(c14b8a80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8a80,c1476680,c0c20b14,c0ab1b06,c147dc80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147dc80,c0acfd29,0,c0c20b04,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pcib_attach(c147dc80,c14b91f4,0,c0c20b34,2,...) at 0xc0ab1b06 = acpi_pcib_attach+0x1b6 acpi_pcib_acpi_attach(c147dc80,c149305c,c0732108,c06fcbf3,80000000,...) at 0xc0ab2781 = acpi_pcib_acpi_attach+0x221 device_attach(c147dc80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147dc80,1,c0c20c34,c0aaf13a,c1476680,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c1476680,c1476680,c0731f98,c0aaf6f0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_attach(c1476680,c149705c,c0732108,c06fcbf3,80000000,...) at 0xc0aaf13a = acpi_attach+0xb1a device_attach(c1476680,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c1476680,c14203c5,c0c20ce8,c04f3357,c147d080,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147d080,c14b105c,c0732108,c06fcbf3,80000000,...) at 0xc04f3f88 = bus_generic_attach+0x28 device_attach(c147d080,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d080,c1463880,c1463880,c14075a0,c1463880,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_new_pass(c1463880,c1444800,c0732038,c14409f0,fffffff,...) at 0xc04f4255 = bus_generic_new_pass+0xd5 bus_set_pass(7fffffff,c0c20d5c,c069b93c,fffffff,c0c20d78,...) at 0xc04f2011 = bus_set_pass+0x81 root_bus_configure(fffffff,c0c20d78,c047b7a6,0,c1ec00,...) at 0xc04f2062 = root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc069b93c = configure+0xc mi_startup() at 0xc047b7a6 = mi_startup+0xa6 begin() at 0xc04385b5 = begin+0x2c uma_zalloc_arg: zone "16" with the following non-sleepable locks held: exclusive sleep mutex ATA state lock (ATA state lock) r = 0 (0xc1447374) locked @ /usr/home/kostik/build/bsd/DEV/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c:188 KDB: stack backtrace: db_trace_self_wrapper(c06fd4c5,c0c20650,c050d3b5,bc,1,...) at 0xc043e016 = db_trace_self_wrapper+0x26 kdb_backtrace(bc,1,ffffffff,c08b85ac,c0c20688,...) at 0xc04f8489 = kdb_backtrace+0x29 _witness_debugger(c06fff4e,c0c2069c,4,1,0,...) at 0xc050d3b5 = _witness_debugger+0x25 witness_warn(5,0,c0718d1b,c07022ea,c07762d0,...) at 0xc050e901 = witness_warn+0x201 uma_zalloc_arg(c0d7b8c0,0,102,2,602,...) at 0xc066a87b = uma_zalloc_arg+0x8b malloc(10,c0737c84,102,235,c1448ce0,...) at 0xc04b0b96 = malloc+0xe6 intr_event_add_handler(c1476000,c14c5c60,0,c09f6040,c1447200,...) at 0xc049b478 = intr_event_add_handler+0x228 intr_add_handler(c14c5c60,e,0,c09f6040,c1447200,...) at 0xc06a6abd = intr_add_handler+0x6d nexus_setup_intr(c147d080,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc06ae0dd = nexus_setup_intr+0x8d bus_generic_setup_intr(c1476680,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c147dc80,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c14b8a80,c147d700,c14c8540,602,0,...) at 0xc04f0a9e = bus_generic_setup_intr+0x7e pci_setup_intr(c14b8a80,c147d700,c14c8540,602,0,...) at 0xc04498fb = pci_setup_intr+0x4b bus_setup_intr(c147d700,c14c8540,602,0,c09f6040,...) at 0xc04f3561 = bus_setup_intr+0x81 ata_attach(c147d700,c147f85c,c0732108,c06fcbf3,80000000,...) at 0xc09f5f97 = ata_attach+0x2a7 device_attach(c147d700,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d700,2,c0c209d4,c0a046a4,c14b8c00,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8c00,1,1,0,ffffffff,...) at 0xc04f3f88 = bus_generic_attach+0x28 ata_pci_attach(c14b8c00,c148485c,c0732108,c06fcbf3,80000000,...) at 0xc0a046a4 = ata_pci_attach+0x174 device_attach(c14b8c00,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8c00,c147dc80,c0c20a78,c0ab178b,c14b8a80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8a80,c1448900,1,c0ab11e0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pci_attach(c14b8a80,c149505c,c0732108,c06fcbf3,80000000,...) at 0xc0ab178b = acpi_pci_attach+0x17b device_attach(c14b8a80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8a80,c1476680,c0c20b14,c0ab1b06,c147dc80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147dc80,c0acfd29,0,c0c20b04,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pcib_attach(c147dc80,c14b91f4,0,c0c20b34,2,...) at 0xc0ab1b06 = acpi_pcib_attach+0x1b6 acpi_pcib_acpi_attach(c147dc80,c149305c,c0732108,c06fcbf3,80000000,...) at 0xc0ab2781 = acpi_pcib_acpi_attach+0x221 device_attach(c147dc80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147dc80,1,c0c20c34,c0aaf13a,c1476680,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c1476680,c1476680,c0731f98,c0aaf6f0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_attach(c1476680,c149705c,c0732108,c06fcbf3,80000000,...) at 0xc0aaf13a = acpi_attach+0xb1a device_attach(c1476680,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c1476680,c14203c5,c0c20ce8,c04f3357,c147d080,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147d080,c14b105c,c0732108,c06fcbf3,80000000,...) at 0xc04f3f88 = bus_generic_attach+0x28 device_attach(c147d080,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d080,c1463880,c1463880,c14075a0,c1463880,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_new_pass(c1463880,c1444800,c0732038,c14409f0,fffffff,...) at 0xc04f4255 = bus_generic_new_pass+0xd5 bus_set_pass(7fffffff,c0c20d5c,c069b93c,fffffff,c0c20d78,...) at 0xc04f2011 = bus_set_pass+0x81 root_bus_configure(fffffff,c0c20d78,c047b7a6,0,c1ec00,...) at 0xc04f2062 = root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc069b93c = configure+0xc mi_startup() at 0xc047b7a6 = mi_startup+0xa6 begin() at 0xc04385b5 = begin+0x2c uma_zalloc_arg: zone "THREAD" with the following non-sleepable locks held: exclusive sleep mutex ATA state lock (ATA state lock) r = 0 (0xc1447374) locked @ /usr/home/kostik/build/bsd/DEV/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c:188 KDB: stack backtrace: db_trace_self_wrapper(c06fd4c5,c0c20584,c050d3b5,bc,1,...) at 0xc043e016 = db_trace_self_wrapper+0x26 kdb_backtrace(bc,1,ffffffff,c08b85ac,c0c205bc,...) at 0xc04f8489 = kdb_backtrace+0x29 _witness_debugger(c06fff4e,c0c205d0,4,1,0,...) at 0xc050d3b5 = _witness_debugger+0x25 witness_warn(5,0,c0718d1b,c06f4104,c07762d0,...) at 0xc050e901 = witness_warn+0x201 uma_zalloc_arg(c0d71280,0,2,c14b35e0,c0c20678,...) at 0xc066a87b = uma_zalloc_arg+0x8b thread_alloc(0,c04fc49b,c06ec14b,c04faf10,c0c20670,...) at 0xc04d5aa9 = thread_alloc+0x29 kthread_add(c049b6a0,c14c5940,c1464aa0,c0c20764,60000,...) at 0xc04a410f = kthread_add+0x3f kproc_kthread_add(c049b6a0,c14c5940,c0776a28,c0c20764,60000,...) at 0xc04a476e = kproc_kthread_add+0x10e intr_event_add_handler(c1476000,c14c5c60,0,c09f6040,c1447200,...) at 0xc049b4c1 = intr_event_add_handler+0x271 intr_add_handler(c14c5c60,e,0,c09f6040,c1447200,...) at 0xc06a6abd = intr_add_handler+0x6d nexus_setup_intr(c147d080,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc06ae0dd = nexus_setup_intr+0x8d bus_generic_setup_intr(c1476680,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c147dc80,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c14b8a80,c147d700,c14c8540,602,0,...) at 0xc04f0a9e = bus_generic_setup_intr+0x7e pci_setup_intr(c14b8a80,c147d700,c14c8540,602,0,...) at 0xc04498fb = pci_setup_intr+0x4b bus_setup_intr(c147d700,c14c8540,602,0,c09f6040,...) at 0xc04f3561 = bus_setup_intr+0x81 ata_attach(c147d700,c147f85c,c0732108,c06fcbf3,80000000,...) at 0xc09f5f97 = ata_attach+0x2a7 device_attach(c147d700,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d700,2,c0c209d4,c0a046a4,c14b8c00,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8c00,1,1,0,ffffffff,...) at 0xc04f3f88 = bus_generic_attach+0x28 ata_pci_attach(c14b8c00,c148485c,c0732108,c06fcbf3,80000000,...) at 0xc0a046a4 = ata_pci_attach+0x174 device_attach(c14b8c00,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8c00,c147dc80,c0c20a78,c0ab178b,c14b8a80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8a80,c1448900,1,c0ab11e0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pci_attach(c14b8a80,c149505c,c0732108,c06fcbf3,80000000,...) at 0xc0ab178b = acpi_pci_attach+0x17b device_attach(c14b8a80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8a80,c1476680,c0c20b14,c0ab1b06,c147dc80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147dc80,c0acfd29,0,c0c20b04,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pcib_attach(c147dc80,c14b91f4,0,c0c20b34,2,...) at 0xc0ab1b06 = acpi_pcib_attach+0x1b6 acpi_pcib_acpi_attach(c147dc80,c149305c,c0732108,c06fcbf3,80000000,...) at 0xc0ab2781 = acpi_pcib_acpi_attach+0x221 device_attach(c147dc80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147dc80,1,c0c20c34,c0aaf13a,c1476680,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c1476680,c1476680,c0731f98,c0aaf6f0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_attach(c1476680,c149705c,c0732108,c06fcbf3,80000000,...) at 0xc0aaf13a = acpi_attach+0xb1a device_attach(c1476680,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c1476680,c14203c5,c0c20ce8,c04f3357,c147d080,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147d080,c14b105c,c0732108,c06fcbf3,80000000,...) at 0xc04f3f88 = bus_generic_attach+0x28 device_attach(c147d080,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d080,c1463880,c1463880,c14075a0,c1463880,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_new_pass(c1463880,c1444800,c0732038,c14409f0,fffffff,...) at 0xc04f4255 = bus_generic_new_pass+0xd5 bus_set_pass(7fffffff,c0c20d5c,c069b93c,fffffff,c0c20d78,...) at 0xc04f2011 = bus_set_pass+0x81 root_bus_configure(fffffff,c0c20d78,c047b7a6,0,c1ec00,...) at 0xc04f2062 = root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc069b93c = configure+0xc mi_startup() at 0xc047b7a6 = mi_startup+0xa6 begin() at 0xc04385b5 = begin+0x2c uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks held: exclusive sleep mutex ATA state lock (ATA state lock) r = 0 (0xc1447374) locked @ /usr/home/kostik/build/bsd/DEV/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c:188 KDB: stack backtrace: db_trace_self_wrapper(c06fd4c5,c0c204b8,c050d3b5,bc,1,...) at 0xc043e016 = db_trace_self_wrapper+0x26 kdb_backtrace(bc,1,ffffffff,c08b85ac,c0c204f0,...) at 0xc04f8489 = kdb_backtrace+0x29 _witness_debugger(c06fff4e,c0c20504,4,1,0,...) at 0xc050d3b5 = _witness_debugger+0x25 witness_warn(5,0,c0718d1b,c071a60d,c07762d0,...) at 0xc050e901 = witness_warn+0x201 uma_zalloc_arg(c0d7b460,0,2,0,4b32f0,...) at 0xc066a87b = uma_zalloc_arg+0x8b vm_object_allocate(0,2,0,16d,c0d7ce88,...) at 0xc067ad5b = vm_object_allocate+0x2b vm_thread_new(c14b32f0,2,2,c14b35e0,c0c20678,...) at 0xc066f5a8 = vm_thread_new+0xf8 thread_alloc(0,c04fc49b,c06ec14b,c04faf10,c0c20670,...) at 0xc04d5acf = thread_alloc+0x4f kthread_add(c049b6a0,c14c5940,c1464aa0,c0c20764,60000,...) at 0xc04a410f = kthread_add+0x3f kproc_kthread_add(c049b6a0,c14c5940,c0776a28,c0c20764,60000,...) at 0xc04a476e = kproc_kthread_add+0x10e intr_event_add_handler(c1476000,c14c5c60,0,c09f6040,c1447200,...) at 0xc049b4c1 = intr_event_add_handler+0x271 intr_add_handler(c14c5c60,e,0,c09f6040,c1447200,...) at 0xc06a6abd = intr_add_handler+0x6d nexus_setup_intr(c147d080,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc06ae0dd = nexus_setup_intr+0x8d bus_generic_setup_intr(c1476680,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c147dc80,c147d700,c14c8540,602,0,c09f6040,c1447200,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c14b8a80,c147d700,c14c8540,602,0,...) at 0xc04f0a9e = bus_generic_setup_intr+0x7e pci_setup_intr(c14b8a80,c147d700,c14c8540,602,0,...) at 0xc04498fb = pci_setup_intr+0x4b bus_setup_intr(c147d700,c14c8540,602,0,c09f6040,...) at 0xc04f3561 = bus_setup_intr+0x81 ata_attach(c147d700,c147f85c,c0732108,c06fcbf3,80000000,...) at 0xc09f5f97 = ata_attach+0x2a7 device_attach(c147d700,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d700,2,c0c209d4,c0a046a4,c14b8c00,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8c00,1,1,0,ffffffff,...) at 0xc04f3f88 = bus_generic_attach+0x28 ata_pci_attach(c14b8c00,c148485c,c0732108,c06fcbf3,80000000,...) at 0xc0a046a4 = ata_pci_attach+0x174 device_attach(c14b8c00,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8c00,c147dc80,c0c20a78,c0ab178b,c14b8a80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8a80,c1448900,1,c0ab11e0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pci_attach(c14b8a80,c149505c,c0732108,c06fcbf3,80000000,...) at 0xc0ab178b = acpi_pci_attach+0x17b device_attach(c14b8a80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8a80,c1476680,c0c20b14,c0ab1b06,c147dc80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147dc80,c0acfd29,0,c0c20b04,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pcib_attach(c147dc80,c14b91f4,0,c0c20b34,2,...) at 0xc0ab1b06 = acpi_pcib_attach+0x1b6 acpi_pcib_acpi_attach(c147dc80,c149305c,c0732108,c06fcbf3,80000000,...) at 0xc0ab2781 = acpi_pcib_acpi_attach+0x221 device_attach(c147dc80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147dc80,1,c0c20c34,c0aaf13a,c1476680,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c1476680,c1476680,c0731f98,c0aaf6f0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_attach(c1476680,c149705c,c0732108,c06fcbf3,80000000,...) at 0xc0aaf13a = acpi_attach+0xb1a device_attach(c1476680,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c1476680,c14203c5,c0c20ce8,c04f3357,c147d080,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147d080,c14b105c,c0732108,c06fcbf3,80000000,...) at 0xc04f3f88 = bus_generic_attach+0x28 device_attach(c147d080,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d080,c1463880,c1463880,c14075a0,c1463880,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_new_pass(c1463880,c1444800,c0732038,c14409f0,fffffff,...) at 0xc04f4255 = bus_generic_new_pass+0xd5 bus_set_pass(7fffffff,c0c20d5c,c069b93c,fffffff,c0c20d78,...) at 0xc04f2011 = bus_set_pass+0x81 root_bus_configure(fffffff,c0c20d78,c047b7a6,0,c1ec00,...) at 0xc04f2062 = root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc069b93c = configure+0xc mi_startup() at 0xc047b7a6 = mi_startup+0xa6 begin() at 0xc04385b5 = begin+0x2c ata0: [ITHREAD] ata1: on atapci0 uma_zalloc_arg: zone "64" with the following non-sleepable locks held: exclusive sleep mutex ATA state lock (ATA state lock) r = 0 (0xc1447574) locked @ /usr/home/kostik/build/bsd/DEV/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c:188 KDB: stack backtrace: db_trace_self_wrapper(c06fd4c5,c0c20650,c050d3b5,bc,1,...) at 0xc043e016 = db_trace_self_wrapper+0x26 kdb_backtrace(bc,1,ffffffff,c08b85ac,c0c20688,...) at 0xc04f8489 = kdb_backtrace+0x29 _witness_debugger(c06fff4e,c0c2069c,4,1,0,...) at 0xc050d3b5 = _witness_debugger+0x25 witness_warn(5,0,c0718d1b,c07019ae,c07762d0,...) at 0xc050e901 = witness_warn+0x201 uma_zalloc_arg(c0d7ba00,0,102,2,602,...) at 0xc066a87b = uma_zalloc_arg+0x8b malloc(3c,c0737c84,102,c06fdf22,c1448ce0,...) at 0xc04b0b96 = malloc+0xe6 intr_event_add_handler(c1463e80,c14c5c40,0,c09f6040,c1447400,...) at 0xc049b29f = intr_event_add_handler+0x4f intr_add_handler(c14c5c40,f,0,c09f6040,c1447400,...) at 0xc06a6abd = intr_add_handler+0x6d nexus_setup_intr(c147d080,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc06ae0dd = nexus_setup_intr+0x8d bus_generic_setup_intr(c1476680,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c147dc80,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c14b8a80,c14c2700,c14c8280,602,0,...) at 0xc04f0a9e = bus_generic_setup_intr+0x7e pci_setup_intr(c14b8a80,c14c2700,c14c8280,602,0,...) at 0xc04498fb = pci_setup_intr+0x4b bus_setup_intr(c14c2700,c14c8280,602,0,c09f6040,...) at 0xc04f3561 = bus_setup_intr+0x81 ata_attach(c14c2700,c14c2700,ffffffff,c06fcbf3,80000000,...) at 0xc09f5f97 = ata_attach+0x2a7 device_attach(c14c2700,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14c2700,2,c0c209d4,c0a046a4,c14b8c00,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8c00,1,1,0,ffffffff,...) at 0xc04f3f88 = bus_generic_attach+0x28 ata_pci_attach(c14b8c00,c148485c,c0732108,c06fcbf3,80000000,...) at 0xc0a046a4 = ata_pci_attach+0x174 device_attach(c14b8c00,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8c00,c147dc80,c0c20a78,c0ab178b,c14b8a80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8a80,c1448900,1,c0ab11e0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pci_attach(c14b8a80,c149505c,c0732108,c06fcbf3,80000000,...) at 0xc0ab178b = acpi_pci_attach+0x17b device_attach(c14b8a80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8a80,c1476680,c0c20b14,c0ab1b06,c147dc80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147dc80,c0acfd29,0,c0c20b04,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pcib_attach(c147dc80,c14b91f4,0,c0c20b34,2,...) at 0xc0ab1b06 = acpi_pcib_attach+0x1b6 acpi_pcib_acpi_attach(c147dc80,c149305c,c0732108,c06fcbf3,80000000,...) at 0xc0ab2781 = acpi_pcib_acpi_attach+0x221 device_attach(c147dc80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147dc80,1,c0c20c34,c0aaf13a,c1476680,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c1476680,c1476680,c0731f98,c0aaf6f0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_attach(c1476680,c149705c,c0732108,c06fcbf3,80000000,...) at 0xc0aaf13a = acpi_attach+0xb1a device_attach(c1476680,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c1476680,c14203c5,c0c20ce8,c04f3357,c147d080,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147d080,c14b105c,c0732108,c06fcbf3,80000000,...) at 0xc04f3f88 = bus_generic_attach+0x28 device_attach(c147d080,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d080,c1463880,c1463880,c14075a0,c1463880,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_new_pass(c1463880,c1444800,c0732038,c14409f0,fffffff,...) at 0xc04f4255 = bus_generic_new_pass+0xd5 bus_set_pass(7fffffff,c0c20d5c,c069b93c,fffffff,c0c20d78,...) at 0xc04f2011 = bus_set_pass+0x81 root_bus_configure(fffffff,c0c20d78,c047b7a6,0,c1ec00,...) at 0xc04f2062 = root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc069b93c = configure+0xc mi_startup() at 0xc047b7a6 = mi_startup+0xa6 begin() at 0xc04385b5 = begin+0x2c uma_zalloc_arg: zone "16" with the following non-sleepable locks held: exclusive sleep mutex ATA state lock (ATA state lock) r = 0 (0xc1447574) locked @ /usr/home/kostik/build/bsd/DEV/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c:188 KDB: stack backtrace: db_trace_self_wrapper(c06fd4c5,c0c20650,c050d3b5,bc,1,...) at 0xc043e016 = db_trace_self_wrapper+0x26 kdb_backtrace(bc,1,ffffffff,c08b85ac,c0c20688,...) at 0xc04f8489 = kdb_backtrace+0x29 _witness_debugger(c06fff4e,c0c2069c,4,1,0,...) at 0xc050d3b5 = _witness_debugger+0x25 witness_warn(5,0,c0718d1b,c07022ea,c07762d0,...) at 0xc050e901 = witness_warn+0x201 uma_zalloc_arg(c0d7b8c0,0,102,2,602,...) at 0xc066a87b = uma_zalloc_arg+0x8b malloc(10,c0737c84,102,235,c1448ce0,...) at 0xc04b0b96 = malloc+0xe6 intr_event_add_handler(c1463e80,c14c5c40,0,c09f6040,c1447400,...) at 0xc049b478 = intr_event_add_handler+0x228 intr_add_handler(c14c5c40,f,0,c09f6040,c1447400,...) at 0xc06a6abd = intr_add_handler+0x6d nexus_setup_intr(c147d080,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc06ae0dd = nexus_setup_intr+0x8d bus_generic_setup_intr(c1476680,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c147dc80,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c14b8a80,c14c2700,c14c8280,602,0,...) at 0xc04f0a9e = bus_generic_setup_intr+0x7e pci_setup_intr(c14b8a80,c14c2700,c14c8280,602,0,...) at 0xc04498fb = pci_setup_intr+0x4b bus_setup_intr(c14c2700,c14c8280,602,0,c09f6040,...) at 0xc04f3561 = bus_setup_intr+0x81 ata_attach(c14c2700,c14c2700,ffffffff,c06fcbf3,80000000,...) at 0xc09f5f97 = ata_attach+0x2a7 device_attach(c14c2700,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14c2700,2,c0c209d4,c0a046a4,c14b8c00,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8c00,1,1,0,ffffffff,...) at 0xc04f3f88 = bus_generic_attach+0x28 ata_pci_attach(c14b8c00,c148485c,c0732108,c06fcbf3,80000000,...) at 0xc0a046a4 = ata_pci_attach+0x174 device_attach(c14b8c00,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8c00,c147dc80,c0c20a78,c0ab178b,c14b8a80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8a80,c1448900,1,c0ab11e0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pci_attach(c14b8a80,c149505c,c0732108,c06fcbf3,80000000,...) at 0xc0ab178b = acpi_pci_attach+0x17b device_attach(c14b8a80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8a80,c1476680,c0c20b14,c0ab1b06,c147dc80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147dc80,c0acfd29,0,c0c20b04,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pcib_attach(c147dc80,c14b91f4,0,c0c20b34,2,...) at 0xc0ab1b06 = acpi_pcib_attach+0x1b6 acpi_pcib_acpi_attach(c147dc80,c149305c,c0732108,c06fcbf3,80000000,...) at 0xc0ab2781 = acpi_pcib_acpi_attach+0x221 device_attach(c147dc80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147dc80,1,c0c20c34,c0aaf13a,c1476680,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c1476680,c1476680,c0731f98,c0aaf6f0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_attach(c1476680,c149705c,c0732108,c06fcbf3,80000000,...) at 0xc0aaf13a = acpi_attach+0xb1a device_attach(c1476680,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c1476680,c14203c5,c0c20ce8,c04f3357,c147d080,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147d080,c14b105c,c0732108,c06fcbf3,80000000,...) at 0xc04f3f88 = bus_generic_attach+0x28 device_attach(c147d080,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d080,c1463880,c1463880,c14075a0,c1463880,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_new_pass(c1463880,c1444800,c0732038,c14409f0,fffffff,...) at 0xc04f4255 = bus_generic_new_pass+0xd5 bus_set_pass(7fffffff,c0c20d5c,c069b93c,fffffff,c0c20d78,...) at 0xc04f2011 = bus_set_pass+0x81 root_bus_configure(fffffff,c0c20d78,c047b7a6,0,c1ec00,...) at 0xc04f2062 = root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc069b93c = configure+0xc mi_startup() at 0xc047b7a6 = mi_startup+0xa6 begin() at 0xc04385b5 = begin+0x2c uma_zalloc_arg: zone "THREAD" with the following non-sleepable locks held: exclusive sleep mutex ATA state lock (ATA state lock) r = 0 (0xc1447574) locked @ /usr/home/kostik/build/bsd/DEV/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c:188 KDB: stack backtrace: db_trace_self_wrapper(c06fd4c5,c0c20584,c050d3b5,bc,1,...) at 0xc043e016 = db_trace_self_wrapper+0x26 kdb_backtrace(bc,1,ffffffff,c08b85ac,c0c205bc,...) at 0xc04f8489 = kdb_backtrace+0x29 _witness_debugger(c06fff4e,c0c205d0,4,1,0,...) at 0xc050d3b5 = _witness_debugger+0x25 witness_warn(5,0,c0718d1b,c06f4104,c07762d0,...) at 0xc050e901 = witness_warn+0x201 uma_zalloc_arg(c0d71280,0,2,c14b32f0,c0c20678,...) at 0xc066a87b = uma_zalloc_arg+0x8b thread_alloc(0,c04fc49b,c06ec14b,c04faf10,c0c20670,...) at 0xc04d5aa9 = thread_alloc+0x29 kthread_add(c049b6a0,c14c57f0,c1464aa0,c0c20764,60000,...) at 0xc04a410f = kthread_add+0x3f kproc_kthread_add(c049b6a0,c14c57f0,c0776a28,c0c20764,60000,...) at 0xc04a476e = kproc_kthread_add+0x10e intr_event_add_handler(c1463e80,c14c5c40,0,c09f6040,c1447400,...) at 0xc049b4c1 = intr_event_add_handler+0x271 intr_add_handler(c14c5c40,f,0,c09f6040,c1447400,...) at 0xc06a6abd = intr_add_handler+0x6d nexus_setup_intr(c147d080,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc06ae0dd = nexus_setup_intr+0x8d bus_generic_setup_intr(c1476680,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c147dc80,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c14b8a80,c14c2700,c14c8280,602,0,...) at 0xc04f0a9e = bus_generic_setup_intr+0x7e pci_setup_intr(c14b8a80,c14c2700,c14c8280,602,0,...) at 0xc04498fb = pci_setup_intr+0x4b bus_setup_intr(c14c2700,c14c8280,602,0,c09f6040,...) at 0xc04f3561 = bus_setup_intr+0x81 ata_attach(c14c2700,c14c2700,ffffffff,c06fcbf3,80000000,...) at 0xc09f5f97 = ata_attach+0x2a7 device_attach(c14c2700,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14c2700,2,c0c209d4,c0a046a4,c14b8c00,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8c00,1,1,0,ffffffff,...) at 0xc04f3f88 = bus_generic_attach+0x28 ata_pci_attach(c14b8c00,c148485c,c0732108,c06fcbf3,80000000,...) at 0xc0a046a4 = ata_pci_attach+0x174 device_attach(c14b8c00,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8c00,c147dc80,c0c20a78,c0ab178b,c14b8a80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8a80,c1448900,1,c0ab11e0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pci_attach(c14b8a80,c149505c,c0732108,c06fcbf3,80000000,...) at 0xc0ab178b = acpi_pci_attach+0x17b device_attach(c14b8a80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8a80,c1476680,c0c20b14,c0ab1b06,c147dc80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147dc80,c0acfd29,0,c0c20b04,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pcib_attach(c147dc80,c14b91f4,0,c0c20b34,2,...) at 0xc0ab1b06 = acpi_pcib_attach+0x1b6 acpi_pcib_acpi_attach(c147dc80,c149305c,c0732108,c06fcbf3,80000000,...) at 0xc0ab2781 = acpi_pcib_acpi_attach+0x221 device_attach(c147dc80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147dc80,1,c0c20c34,c0aaf13a,c1476680,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c1476680,c1476680,c0731f98,c0aaf6f0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_attach(c1476680,c149705c,c0732108,c06fcbf3,80000000,...) at 0xc0aaf13a = acpi_attach+0xb1a device_attach(c1476680,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c1476680,c14203c5,c0c20ce8,c04f3357,c147d080,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147d080,c14b105c,c0732108,c06fcbf3,80000000,...) at 0xc04f3f88 = bus_generic_attach+0x28 device_attach(c147d080,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d080,c1463880,c1463880,c14075a0,c1463880,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_new_pass(c1463880,c1444800,c0732038,c14409f0,fffffff,...) at 0xc04f4255 = bus_generic_new_pass+0xd5 bus_set_pass(7fffffff,c0c20d5c,c069b93c,fffffff,c0c20d78,...) at 0xc04f2011 = bus_set_pass+0x81 root_bus_configure(fffffff,c0c20d78,c047b7a6,0,c1ec00,...) at 0xc04f2062 = root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc069b93c = configure+0xc mi_startup() at 0xc047b7a6 = mi_startup+0xa6 begin() at 0xc04385b5 = begin+0x2c uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks held: exclusive sleep mutex ATA state lock (ATA state lock) r = 0 (0xc1447574) locked @ /usr/home/kostik/build/bsd/DEV/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c:188 KDB: stack backtrace: db_trace_self_wrapper(c06fd4c5,c0c204b8,c050d3b5,bc,1,...) at 0xc043e016 = db_trace_self_wrapper+0x26 kdb_backtrace(bc,1,ffffffff,c08b85ac,c0c204f0,...) at 0xc04f8489 = kdb_backtrace+0x29 _witness_debugger(c06fff4e,c0c20504,4,1,0,...) at 0xc050d3b5 = _witness_debugger+0x25 witness_warn(5,0,c0718d1b,c071a60d,c07762d0,...) at 0xc050e901 = witness_warn+0x201 uma_zalloc_arg(c0d7b460,0,2,0,4b3000,...) at 0xc066a87b = uma_zalloc_arg+0x8b vm_object_allocate(0,2,0,16d,c0d7ce88,...) at 0xc067ad5b = vm_object_allocate+0x2b vm_thread_new(c14b3000,2,2,c14b32f0,c0c20678,...) at 0xc066f5a8 = vm_thread_new+0xf8 thread_alloc(0,c04fc49b,c06ec14b,c04faf10,c0c20670,...) at 0xc04d5acf = thread_alloc+0x4f kthread_add(c049b6a0,c14c57f0,c1464aa0,c0c20764,60000,...) at 0xc04a410f = kthread_add+0x3f kproc_kthread_add(c049b6a0,c14c57f0,c0776a28,c0c20764,60000,...) at 0xc04a476e = kproc_kthread_add+0x10e intr_event_add_handler(c1463e80,c14c5c40,0,c09f6040,c1447400,...) at 0xc049b4c1 = intr_event_add_handler+0x271 intr_add_handler(c14c5c40,f,0,c09f6040,c1447400,...) at 0xc06a6abd = intr_add_handler+0x6d nexus_setup_intr(c147d080,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc06ae0dd = nexus_setup_intr+0x8d bus_generic_setup_intr(c1476680,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c147dc80,c14c2700,c14c8280,602,0,c09f6040,c1447400,c0c208b0) at 0xc04f0a9e = bus_generic_setup_intr+0x7e bus_generic_setup_intr(c14b8a80,c14c2700,c14c8280,602,0,...) at 0xc04f0a9e = bus_generic_setup_intr+0x7e pci_setup_intr(c14b8a80,c14c2700,c14c8280,602,0,...) at 0xc04498fb = pci_setup_intr+0x4b bus_setup_intr(c14c2700,c14c8280,602,0,c09f6040,...) at 0xc04f3561 = bus_setup_intr+0x81 ata_attach(c14c2700,c14c2700,ffffffff,c06fcbf3,80000000,...) at 0xc09f5f97 = ata_attach+0x2a7 device_attach(c14c2700,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14c2700,2,c0c209d4,c0a046a4,c14b8c00,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8c00,1,1,0,ffffffff,...) at 0xc04f3f88 = bus_generic_attach+0x28 ata_pci_attach(c14b8c00,c148485c,c0732108,c06fcbf3,80000000,...) at 0xc0a046a4 = ata_pci_attach+0x174 device_attach(c14b8c00,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8c00,c147dc80,c0c20a78,c0ab178b,c14b8a80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c14b8a80,c1448900,1,c0ab11e0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pci_attach(c14b8a80,c149505c,c0732108,c06fcbf3,80000000,...) at 0xc0ab178b = acpi_pci_attach+0x17b device_attach(c14b8a80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c14b8a80,c1476680,c0c20b14,c0ab1b06,c147dc80,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147dc80,c0acfd29,0,c0c20b04,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_pcib_attach(c147dc80,c14b91f4,0,c0c20b34,2,...) at 0xc0ab1b06 = acpi_pcib_attach+0x1b6 acpi_pcib_acpi_attach(c147dc80,c149305c,c0732108,c06fcbf3,80000000,...) at 0xc0ab2781 = acpi_pcib_acpi_attach+0x221 device_attach(c147dc80,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147dc80,1,c0c20c34,c0aaf13a,c1476680,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c1476680,c1476680,c0731f98,c0aaf6f0,0,...) at 0xc04f3f88 = bus_generic_attach+0x28 acpi_attach(c1476680,c149705c,c0732108,c06fcbf3,80000000,...) at 0xc0aaf13a = acpi_attach+0xb1a device_attach(c1476680,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c1476680,c14203c5,c0c20ce8,c04f3357,c147d080,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_attach(c147d080,c14b105c,c0732108,c06fcbf3,80000000,...) at 0xc04f3f88 = bus_generic_attach+0x28 device_attach(c147d080,4,c06fcaa5,a47) at 0xc04f3357 = device_attach+0x387 device_probe_and_attach(c147d080,c1463880,c1463880,c14075a0,c1463880,...) at 0xc04f3f4e = device_probe_and_attach+0x4e bus_generic_new_pass(c1463880,c1444800,c0732038,c14409f0,fffffff,...) at 0xc04f4255 = bus_generic_new_pass+0xd5 bus_set_pass(7fffffff,c0c20d5c,c069b93c,fffffff,c0c20d78,...) at 0xc04f2011 = bus_set_pass+0x81 root_bus_configure(fffffff,c0c20d78,c047b7a6,0,c1ec00,...) at 0xc04f2062 = root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc069b93c = configure+0xc mi_startup() at 0xc047b7a6 = mi_startup+0xa6 begin() at 0xc04385b5 = begin+0x2c ata1: [ITHREAD] --H1spWtNR+x+ondvy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw655sACgkQC3+MBN1Mb4iT+ACgxF8gtallxpcerHoUKpGO3HTK 3Y8An1g+cHI7XR693Gca4PNlUDqv7JCl =GbWD -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 10:43:09 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BC8A1065673; Mon, 12 Jul 2010 10:43:09 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0ECDE8FC08; Mon, 12 Jul 2010 10:43:08 +0000 (UTC) Received: by wwb31 with SMTP id 31so40500wwb.31 for ; Mon, 12 Jul 2010 03:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type; bh=r1uRX/rmcT/Htxz5KDbsY7YLOHXvycoXmCHN05y40pc=; b=E6QAJ8rJCs1+FKBmXgoGOuQJqHy+L4zbqypN7FM4Xtzj2mye7R4sKGe6gsxC3aplDC J2ZB7onp9QEDSCsmiJnhmlIDLINYsZZmLmNwQeJYJNImRTwq4XCDRe82S1S0liHkT5tM fbDamnTVOxotrJfkZ+1kXhkqwf30L8nPlZsdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=Qcp+PMlcIeCj1nyOvHFSb8dj5EKO3Ce3DZG6+KNplHA0KD9Z5cjrwOS49ovYMyJhFu YwHZpdSdWkwmF1dCuFyxOCH01gfUY759ZdZrrLE20JM01SwMs6Mfzg6wNMyuzQFYPjmy sr9ga41Jy1adk6Wmv2/1ju4kkEcBJq5O/r7Sg= MIME-Version: 1.0 Received: by 10.216.81.213 with SMTP id m63mr3144632wee.25.1278931385339; Mon, 12 Jul 2010 03:43:05 -0700 (PDT) Received: by 10.216.171.10 with HTTP; Mon, 12 Jul 2010 03:43:05 -0700 (PDT) Date: Mon, 12 Jul 2010 10:43:05 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: dougb@FreeBSD.org Subject: Re: Interactivity problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 10:43:09 -0000 >I use -current on my laptop as my regular X platform, and for the last >few months I've been noticing that interactivity problems have been >getting a lot worse, by which I mean that if I have something running in >the background that is either disk or cpu intensive, anything else I try >to do on the system suffers. The most usual symptom is painfully slow >refresh times on windows, skipping audio, jumpy mouse, etc. These >problems persist even if I nice the hungry process. Does it only happen when X is running? Have you tried using gsched(8) to see if that helps when disk activity is involved? b. From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 10:57:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0006A106566B; Mon, 12 Jul 2010 10:57:00 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 99E308FC08; Mon, 12 Jul 2010 10:56:59 +0000 (UTC) Received: by qwg5 with SMTP id 5so1577140qwg.13 for ; Mon, 12 Jul 2010 03:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=6zwczqIGalwA9FVS1obhAyeFDYQ7CXGfU2MGgO3pwew=; b=deTjCtM8UNifUE9J1JeBQDwEVmsjidvdWEPrz75vqUSQIBA4mCoqCoHk67uLSICyf1 nZveBPYjYL3TOE5YWZbFg7DTN9ArKQ0rTTPsvZ+1Bg3rtkgnqAP9vqWw0AKwTrp1RiLq 6cSBwuAsHfQGCEQWj6yLyZPyxeOaGqI0VyUjA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=tpSpPYNNpdBCH2A/6aarZXwV3CEfT7MeERUpf/ctCLYM7J0ZHTI2nS+oUNr07h7pue cs9zQ5EJuzOMpCPEGnob1d0dcjdI5cTbvwEDPyM2ipJT6nyqo7jv/miQaq9nxEOr1J/I Ap9Cr3o9+qSyI9JmlOYZV+7WC1iv+J8h7sOxs= MIME-Version: 1.0 Received: by 10.224.69.17 with SMTP id x17mr7635282qai.283.1278932218875; Mon, 12 Jul 2010 03:56:58 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.248.12 with HTTP; Mon, 12 Jul 2010 03:56:58 -0700 (PDT) In-Reply-To: <4C3AA6D7.7070904@FreeBSD.org> References: <4C3AA6D7.7070904@FreeBSD.org> Date: Mon, 12 Jul 2010 12:56:58 +0200 X-Google-Sender-Auth: xuSaVULp8Ki1U-6J7IhHlAb_zw8 Message-ID: From: Attilio Rao To: Doug Barton Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: Interactivity problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 10:57:01 -0000 2010/7/12 Doug Barton : > Howdy, > > I use -current on my laptop as my regular X platform, and for the last > few months I've been noticing that interactivity problems have been > getting a lot worse, by which I mean that if I have something running in > the background that is either disk or cpu intensive, anything else I try > to do on the system suffers. The most usual symptom is painfully slow > refresh times on windows, skipping audio, jumpy mouse, etc. These > problems persist even if I nice the hungry process. > > My kernel conf is a typical GENERIC minus stuff I don't have. You can > see the diff to GENERIC at > http://people.freebsd.org/~dougb/kernel-conf.diff > > My loader.conf: > umass_load="yes" > coretemp_load="yes" > linux_load="YES" > nvidia_load="YES" > if_wpi_load="YES" > > /etc/sysctl.conf > debug.debugger_on_panic=0 > kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules > > No malloc.conf or libmap.conf. The only diff in my src tree is a patch > from mav vs. his latest timer update. All in all this is a very GENERIC > system, pardon the pun. :) > > Is anyone else seeing this problem? Does anyone have suggestions? Can you try to extract schedgraph traces for KTR_SCHED? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 11:19:17 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB6D8106566B; Mon, 12 Jul 2010 11:19:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5E78FC08; Mon, 12 Jul 2010 11:19:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o6CBJGLP066735; Mon, 12 Jul 2010 07:19:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o6CBJGjP066730; Mon, 12 Jul 2010 11:19:16 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 12 Jul 2010 11:19:16 GMT Message-Id: <201007121119.o6CBJGjP066730@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 11:19:17 -0000 TB --- 2010-07-12 09:52:36 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-12 09:52:36 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-07-12 09:52:36 - cleaning the object tree TB --- 2010-07-12 09:52:54 - cvsupping the source tree TB --- 2010-07-12 09:52:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-07-12 09:54:06 - building world TB --- 2010-07-12 09:54:06 - MAKEOBJDIRPREFIX=/obj TB --- 2010-07-12 09:54:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-07-12 09:54:06 - TARGET=powerpc TB --- 2010-07-12 09:54:06 - TARGET_ARCH=powerpc TB --- 2010-07-12 09:54:06 - TZ=UTC TB --- 2010-07-12 09:54:06 - __MAKE_CONF=/dev/null TB --- 2010-07-12 09:54:06 - cd /src TB --- 2010-07-12 09:54:06 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 12 09:54:06 UTC 2010 >>> 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 [...] load_elf32.o(.sdata+0x0): first defined here load_elf64.o(.sbss+0x0): multiple definition of `elf32_relocation_offset' load_elf32.o(.sbss+0x0): first defined here load_elf64.o(.sdata+0x4): multiple definition of `elf32_moduletype' load_elf32.o(.sdata+0x4): first defined here reloc_elf64.o(.text+0x0): In function `elf32_reloc': : multiple definition of `elf32_reloc' reloc_elf32.o(.text+0x0): first defined here *** Error code 1 Stop in /src/sys/boot/powerpc/ofw. *** Error code 1 Stop in /src/sys/boot/powerpc. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-07-12 11:19:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-07-12 11:19:16 - ERROR: failed to build world TB --- 2010-07-12 11:19:16 - 4123.94 user 733.60 system 5199.61 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 12:03:25 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57F9D1065739 for ; Mon, 12 Jul 2010 12:03:24 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 503228FC22 for ; Mon, 12 Jul 2010 12:03:23 +0000 (UTC) Received: by bwz12 with SMTP id 12so2791934bwz.13 for ; Mon, 12 Jul 2010 05:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=fkp59GJXKe0VyerFA0SNm2NPxGhnZGpMdmK2If7TEJI=; b=WQir5jstZtxstmMu9/gEkW5wCOfQJSjroBmjypbouPBPxVuq4rDMWInmGZPhg+uuZO IgaMSDGWTXAF4GkXXvTurM4bwtXd/XdKtUey71lAw8MW61OzS2nl5RlZ9xLEgEg4kGKS Sc17epUhV5pg/0dVkPQH8It4b8lM34AQ2qLiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=n2n62MZvb+SyO4RuZmIi3ATrjyf3SsIlXwzWMOc1aneA6NmH7mUFNdxPKEhkbA/qSf 0+r3o1OdENoEptUUrZygQCSC2lwG6P8MpGz2sJrG+OJ26yQAb0BmTtg7CvoOPR93iVrB uH5HWO+ws3DeatCwg3z1cDg2YQmQrZUymys1s= Received: by 10.204.103.199 with SMTP id l7mr6761618bko.18.1278936202870; Mon, 12 Jul 2010 05:03:22 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f10sm18227658bkl.5.2010.07.12.05.03.21 (version=SSLv3 cipher=RC4-MD5); Mon, 12 Jul 2010 05:03:22 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C3B0454.5080700@FreeBSD.org> Date: Mon, 12 Jul 2010 15:02:28 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Kostik Belousov References: <20100712095956.GB2381@deviant.kiev.zoral.com.ua> In-Reply-To: <20100712095956.GB2381@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ATA-related LORs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 12:03:25 -0000 Hi. Kostik Belousov wrote: > on the HEAD r209908, I see a lot of LORs at the boot. It seems that > mutex called "ATA state lock" is held over the large period of kernel > initialization. After the system booted, it seems to operate properly. Thank you. Now testing alternative solution. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 13:34:33 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6953C1065670; Mon, 12 Jul 2010 13:34:33 +0000 (UTC) (envelope-from nyan@FreeBSD.org) Received: from sakura.ccs.furiru.org (sakura.ccs.furiru.org [IPv6:2001:2f0:104:8060::1]) by mx1.freebsd.org (Postfix) with ESMTP id 25F528FC08; Mon, 12 Jul 2010 13:34:32 +0000 (UTC) Received: from localhost (authenticated bits=0) by sakura.ccs.furiru.org (unknown) with ESMTP id o6CDYR4P014192; Mon, 12 Jul 2010 22:34:29 +0900 (JST) (envelope-from nyan@FreeBSD.org) Date: Mon, 12 Jul 2010 22:33:11 +0900 (JST) Message-Id: <20100712.223311.27842410.nyan@FreeBSD.org> To: mav@FreeBSD.org From: TAKAHASHI Yoshihiro In-Reply-To: <4C3AD4A8.602@FreeBSD.org> References: <4C3AD4A8.602@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Jul_12_22_33_11_2010_131)--" Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: [patch] Clocks on PC98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 13:34:33 -0000 ----Next_Part(Mon_Jul_12_22_33_11_2010_131)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit In article <4C3AD4A8.602@FreeBSD.org> Alexander Motin writes: > I've made a patch to unify PC98 event timer code with the rest of x86. > Could somebody test it on that hardware, as all I can say now is that it > builds. > > I have no idea about ISA PNP on PC98, so if it doesn't report timer > presence, it may be needed to add to device.hints lines like: > hint.attimer.0.at="isa" > hint.attimer.0.port="0x71" > hint.attimer.0.irq="0" This patch has two problems. The one is a missing change in timer_spkr_setfreq() and the other is wrong allocation for I/O ports. I attach new patch that works fine for pc98. Please feel it free. Thanks for your work. --- TAKAHASHI Yoshihiro ----Next_Part(Mon_Jul_12_22_33_11_2010_131)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="clock.diff" Index: conf/files.pc98 =================================================================== RCS file: /home/ncvs/src/sys/conf/files.pc98,v retrieving revision 1.386 diff -u -r1.386 files.pc98 --- conf/files.pc98 8 Jun 2010 18:36:03 -0000 1.386 +++ conf/files.pc98 12 Jul 2010 11:10:16 -0000 @@ -227,7 +227,6 @@ libkern/umoddi3.c standard pc98/apm/apm_bioscall.S optional apm pc98/cbus/cbus_dma.c optional isa -pc98/cbus/clock.c standard pc98/cbus/fdc.c optional fdc pc98/cbus/fdc_cbus.c optional fdc isa pc98/cbus/gdc.c optional gdc @@ -253,8 +252,10 @@ # x86 shared code between IA32, AMD64 and PC98 architectures # x86/isa/atpic.c optional atpic +x86/isa/clock.c standard x86/isa/isa.c optional isa x86/x86/io_apic.c optional apic x86/x86/local_apic.c optional apic x86/x86/mca.c standard x86/x86/msi.c optional apic pci +x86/x86/timeevents.c standard Index: pc98/conf/GENERIC.hints =================================================================== RCS file: /home/ncvs/src/sys/pc98/conf/GENERIC.hints,v retrieving revision 1.28 diff -u -r1.28 GENERIC.hints --- pc98/conf/GENERIC.hints 25 Aug 2008 14:52:50 -0000 1.28 +++ pc98/conf/GENERIC.hints 12 Jul 2010 12:52:00 -0000 @@ -42,6 +42,10 @@ #hint.ct.0.at="isa" #hint.ct.0.flags="0x50000" +hint.attimer.0.at="isa" +hint.attimer.0.port="0x71" +hint.attimer.0.irq="0" + hint.pcrtc.0.at="isa" hint.pckbd.0.at="isa" Index: x86/isa/clock.c =================================================================== RCS file: /home/ncvs/src/sys/x86/isa/clock.c,v retrieving revision 1.11 diff -u -r1.11 clock.c --- x86/isa/clock.c 12 Jul 2010 06:46:17 -0000 1.11 +++ x86/isa/clock.c 12 Jul 2010 12:56:47 -0000 @@ -66,9 +66,17 @@ #include #include +#ifdef PC98 +#include +#else #include +#endif #ifdef DEV_ISA +#ifdef PC98 +#include +#else #include +#endif #include #endif @@ -78,8 +86,12 @@ int clkintr_pending; #ifndef TIMER_FREQ +#ifdef PC98 +#define TIMER_FREQ 2457600 +#else #define TIMER_FREQ 1193182 #endif +#endif u_int i8254_freq = TIMER_FREQ; TUNABLE_INT("hw.i8254.freq", &i8254_freq); int i8254_max_count; @@ -97,6 +109,10 @@ int port_rid, intr_rid; struct resource *port_res; struct resource *intr_res; +#ifdef PC98 + int port_rid2; + struct resource *port_res2; +#endif void *intr_handler; struct timecounter tc; struct eventtimer et; @@ -150,7 +166,11 @@ { int mode; +#ifdef PC98 + mode = TIMER_SEL1 | TIMER_SQWAVE | TIMER_16BIT; +#else mode = TIMER_SEL2 | TIMER_SQWAVE | TIMER_16BIT; +#endif if (timer2_state != RELEASED) return (-1); @@ -163,7 +183,11 @@ * and this is probably good enough for timer2, so we aren't as * careful with it as with timer0. */ +#ifdef PC98 + outb(TIMER_MODE, TIMER_SEL1 | (mode & 0x3f)); +#else outb(TIMER_MODE, TIMER_SEL2 | (mode & 0x3f)); +#endif ppi_spkr_on(); /* enable counter2 output to speaker */ return (0); } @@ -175,7 +199,11 @@ if (timer2_state != ACQUIRED) return (-1); timer2_state = RELEASED; +#ifdef PC98 + outb(TIMER_MODE, TIMER_SEL1 | TIMER_SQWAVE | TIMER_16BIT); +#else outb(TIMER_MODE, TIMER_SEL2 | TIMER_SQWAVE | TIMER_16BIT); +#endif ppi_spkr_off(); /* disable counter2 output to speaker */ return (0); } @@ -186,8 +214,13 @@ freq = i8254_freq / freq; mtx_lock_spin(&clock_lock); +#ifdef PC98 + outb(TIMER_CNTR1, freq & 0xff); + outb(TIMER_CNTR1, freq >> 8); +#else outb(TIMER_CNTR2, freq & 0xff); outb(TIMER_CNTR2, freq >> 8); +#endif mtx_unlock_spin(&clock_lock); } @@ -293,7 +326,11 @@ while (ticks_left > 0) { #ifdef KDB if (kdb_active) { +#ifdef PC98 + outb(0x5f, 0); +#else inb(0x84); +#endif tick = prev_tick - 1; if (tick <= 0) tick = i8254_max_count; @@ -377,7 +414,9 @@ { i8254_restore(); /* restore i8254_freq and hz */ +#ifndef PC98 atrtc_restore(); /* reenable RTC interrupts */ +#endif } #endif @@ -387,6 +426,10 @@ { mtx_init(&clock_lock, "clk", NULL, MTX_SPIN | MTX_NOPROFILE); +#ifdef PC98 + if (pc98_machine_type & M_8M) + i8254_freq = 1996800L; /* 1.9968 MHz */ +#endif set_i8254_freq(i8254_freq, 0); } @@ -506,6 +549,51 @@ { 0 } }; +#ifdef PC98 +static void +pc98_alloc_resource(device_t dev) +{ + static bus_addr_t iat1[] = {0, 2, 4, 6}; + static bus_addr_t iat2[] = {0, 4}; + struct attimer_softc *sc; + + sc = device_get_softc(dev); + + sc->port_rid = 0; + bus_set_resource(dev, SYS_RES_IOPORT, sc->port_rid, IO_TIMER1, 1); + sc->port_res = isa_alloc_resourcev(dev, SYS_RES_IOPORT, + &sc->port_rid, iat1, 4, RF_ACTIVE); + if (sc->port_res == NULL) + device_printf(dev, "Warning: Couldn't map I/O.\n"); + else + isa_load_resourcev(sc->port_res, iat1, 4); + + sc->port_rid2 = 4; + bus_set_resource(dev, SYS_RES_IOPORT, sc->port_rid2, TIMER_CNTR1, 1); + sc->port_res2 = isa_alloc_resourcev(dev, SYS_RES_IOPORT, + &sc->port_rid2, iat2, 2, RF_ACTIVE); + if (sc->port_res2 == NULL) + device_printf(dev, "Warning: Couldn't map I/O.\n"); + else + isa_load_resourcev(sc->port_res2, iat2, 2); +} + +static void +pc98_release_resource(device_t dev) +{ + struct attimer_softc *sc; + + sc = device_get_softc(dev); + + if (sc->port_res) + bus_release_resource(dev, SYS_RES_IOPORT, sc->port_rid, + sc->port_res); + if (sc->port_res2) + bus_release_resource(dev, SYS_RES_IOPORT, sc->port_rid2, + sc->port_res2); +} +#endif + static int attimer_probe(device_t dev) { @@ -515,6 +603,11 @@ /* ENOENT means no PnP-ID, device is hinted. */ if (result == ENOENT) { device_set_desc(dev, "AT timer"); +#ifdef PC98 + /* To print resources correctly. */ + pc98_alloc_resource(dev); + pc98_release_resource(dev); +#endif return (BUS_PROBE_LOW_PRIORITY); } return (result); @@ -529,9 +622,13 @@ attimer_sc = sc = device_get_softc(dev); bzero(sc, sizeof(struct attimer_softc)); +#ifdef PC98 + pc98_alloc_resource(dev); +#else if (!(sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid, IO_TIMER1, IO_TIMER1 + 3, 4, RF_ACTIVE))) device_printf(dev,"Warning: Couldn't map I/O.\n"); +#endif i8254_intsrc = intr_lookup_source(0); if (i8254_intsrc != NULL) i8254_pending = i8254_intsrc->is_pic->pic_source_pending; ----Next_Part(Mon_Jul_12_22_33_11_2010_131)---- From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 15:08:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E4141065678; Mon, 12 Jul 2010 15:08:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2F6B28FC12; Mon, 12 Jul 2010 15:08:33 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CF7AD46B7E; Mon, 12 Jul 2010 11:08:32 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 55CFB8A04E; Mon, 12 Jul 2010 11:08:28 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 12 Jul 2010 10:08:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <1278695579.2436.27.camel@localhost.localdomain> <201007100016.29946.hselasky@c2i.net> <4C37DAA2.6080102@acm.poly.edu> In-Reply-To: <4C37DAA2.6080102@acm.poly.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201007121008.33603.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 12 Jul 2010 11:08:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: sbruno@freebsd.org, Boris Kochergin , Hans Petter Selasky Subject: Re: QEMU/KVM Panic on USB Mount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 15:08:33 -0000 On Friday, July 09, 2010 10:27:46 pm Boris Kochergin wrote: > Hans Petter Selasky wrote: > > On Friday 09 July 2010 19:12:59 Sean Bruno wrote: > > > >> In order to come up with the most convoluted problem possible, I present > >> to you screen shots of a panic from a FreeBSD VM running in QEMU > >> emulation under RedHat's KVM infrastructure. > >> > >> I presented a perfectly functional USB partition from my host machine to > >> the VM. Then I attempted to mount the partition from FreeBSD and it > >> generated the panics located here: > >> > >> http://people.freebsd.org/~sbruno/usb_panic1.png > >> http://people.freebsd.org/~sbruno/usb_panic2.png > >> > >> This is 100% reproducible. But not an emergency or anything. > >> > > > > It might be that there is a conflict that both the VM and the OS is accessing > > / loading drivers on the same USB device. The panic seems not directly related > > to USB. > > > > --HPS > > > > > I followed the code for a while and the cause of the panic appears to be > that ffs_vgetf() in /usr/src/sys/ufs/ffs/ffs_vfsops.c fails in one of > the several ways possible, causing in VFS_ROOT() in > /usr/src/sys/kern/vfs_mount.c to return a non-zero value and resulting > in the panic. I think the problem calls for someone with serious VFS chops. > > The I/O errors from the USB device are suspicious (in that they may > cause the mount code to misbehave if they occur during its course). Much of the filesystem code doesn't really handle I/O errors very gracefully. I do think trasz@ did some work a year or so ago to improve this somewhat. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 16:56:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD7A5106566B; Mon, 12 Jul 2010 16:56:36 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 323278FC16; Mon, 12 Jul 2010 16:56:35 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 6B4A911BA87; Mon, 12 Jul 2010 11:56:34 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id B8FY11U9KTRO; Mon, 12 Jul 2010 11:56:32 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Mon, 12 Jul 2010 17:56:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <275997A3-6832-4EB9-B1BD-F9848E2C1F66@FreeBSD.org> References: <201007072113.16320.hselasky@c2i.net> To: Andrew Thompson X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org, Sam Leffler , PseudoCylon , freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 16:56:36 -0000 On 12 Jul 2010, at 01:07, Andrew Thompson wrote: > On 8 July 2010 07:13, Hans Petter Selasky wrote: >> Hi, >>=20 >> When supplying wpa_supplicant.conf with incorrect passwords, but a = valid SSID, >> I have seen kernel panics several times when using USB based WLAN = dongles. >> When only supplying a valid password, no panic has been seen. >>=20 >> How to reproduce: >>=20 >> 1) configure invalid password >> 2) wpa_cli: reconfigure >> 3) configure valid password >> 4) wpa_cli: reconfigure >> 5) goto 1 >>=20 >> The USB commands which are executed inside the newstate callback = usually take >> very little time, but still not as little time as PCI read/writes. = I've forced >> slower operation in the newstate callback, and can reproduce warning = printouts >> from the IEEE802.11 layer in FreeBSD. Try to apply the following = patch to your >> USB code: >>=20 >> http://p4web.freebsd.org/@@180604?ac=3D10 >>=20 >> In my opinion the deferring of all states to a single task is wrong. = There >> should be at least one task per possible state, and the queuing = mechanism >> should follow the last-queued is last executed rule. This is not the = case with >> the task-queue mechanism in the kernel. >=20 > This turned out to be refcounting of the ieee80211_node struct which > was causing this panic. vap->iv_bss can be freed at any time so all > users of it need to bump the refcount to use it safely. >=20 > This patch should fix the panic in the rum driver. > http://people.freebsd.org/~thompsa/rum_node_refcnt.diff >=20 > There are other places where it is still an issue such as the > ieee80211_tx_mgt_timeout callout which havnt been addressed yet, and > of course all other ieee80211 drivers. Oh, this makes sense now. My previous attempt at help you made no = sense... Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 17:09:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1861C1065672 for ; Mon, 12 Jul 2010 17:09:50 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6DAE68FC1A for ; Mon, 12 Jul 2010 17:09:49 +0000 (UTC) Received: by bwz12 with SMTP id 12so3033716bwz.13 for ; Mon, 12 Jul 2010 10:09:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.118.3 with SMTP id t3mr10989447bkq.163.1278954587013; Mon, 12 Jul 2010 10:09:47 -0700 (PDT) Received: by 10.204.48.35 with HTTP; Mon, 12 Jul 2010 10:09:46 -0700 (PDT) In-Reply-To: <4C3594FF.8070907@FreeBSD.org> References: <4C31C71C.2010606@FreeBSD.org> <4C357F0A.70009@FreeBSD.org> <4C3594FF.8070907@FreeBSD.org> Date: Mon, 12 Jul 2010 19:09:46 +0200 Message-ID: From: Olivier Smedts To: Martin Matuska Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Jason J. W. Williams" , "Sam Fourman Jr." , "freebsd-current@freebsd.org" Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 17:09:50 -0000 2010/7/8 Martin Matuska : > Hi Jason, > > as for me, I am ready to stand for the stability of my v15 upgrade, it > has been discussed with our zfs team, and we also see it as a kind of a > starting point. > > We generally have two options: > a) push ZFS v15 now > - it has been already disussed > - we can continue with incremental upgrades that do bugfixes or > introduce non-intrusive features like we did until now > - upgrade to higher versions in the future > > b) do not push anything, wait for a uncertain ammount of time and import > a higher version > - =C2=A0this might take months or even more than 1 year > - our project is not an anarchy or a dictatorship, so it has to be > argued, discussed, evaluated and publicly tested again > > As for me, I go for a). > > The recent ZFS code contains even more OpenSolaris specific parts, zvol > code probably needs to be reprogrammed once again and there are also > other features like autoexpansion of pools that need polishing. If you > want some future information, there are plans and already work to make > the very latest ZFS available. But its uncertainity again, I cannot give > you any dates but what is very probable that you won't see anything that > early. Of course any volunteers that are willing to help us porting ZFS > features are welcome :-) > > Now to the performance fixes for DB workloads - can you point me to the > code or tell me what do they do? > We have already now the prefetch improvements from v19 and ARC > improvements from v15 in stable/8. > Many parts of the OpenSolaris code can be very easily integrated without > breaking existing stuff and again, v15 is a very good starting point for > this. > > Regarding performance, e.g. my PHP web servers with codebase in ZFS > yield 15-20% more req/s with v15 patch (as compared to v14). I'm currently trying your patchset, I have updated versions of kernel and userland zfs code. Now, are there any benefits to upgrade the zpool and the zfs to the latest versions, besides quotas ? > Cheers, > mm > > D=C5=88a 8. 7. 2010 9:47, Jason J. W. Williams =C2=A0wrote / nap=C3=ADsal= (a): >> Hi Martin, >> >> If you're using it for NFS then that can be a good feature, but I see a = lot more folks complaining about lack of removal for log devices. >> >> We've been using ZFS on OpenSolaris for DB servers since 2006 and OpenSo= laris bits are very stable. In most cases we've found ZFS under OSol to be = more stable than Solaris. Normally this is due to the youth of ZFS and the = speed with which bugs are being corrected...which end up in OSol while Sola= ris languishes under it's long release cycle. =C2=A0I'll posit Joyent as an= example here of the stability of OSol bits...they use the SXCE distro rece= ntly discontinued. >> >> v19 also includes a number of performance fixes for DB workloads. >> >> -J >> >> Sent via iPhone >> >> Is your e-mail Premiere? >> >> On Jul 8, 2010, at 1:32, Martin Matuska wrote: >> >> >>> User and group quotas is no important enhancement? >>> >>> We have to see the whole thing from a stability perspective as well - >>> OpenSolaris has by far less testing than Solaris 10. >>> Oracle cannot afford to feed his enterprise customers (and these are no= t >>> few) with untested code. >>> >>> D=C5=88a 7. 7. 2010 20:30, Sam Fourman Jr. wrote / nap=C3=ADsal(a): >>> >>>> On Wed, Jul 7, 2010 at 1:25 PM, Jason J. W. Williams >>>> wrote: >>>> >>>> >>>>> If the target is FreeBSD 9 instead of 8.1, why not merge ZFS v19? 15 >>>>> really doesn't give any major enhancements over 14 and FreeBSD 9 isn'= t >>>>> coming out any time. >>>>> >>>>> 19 would give much need log device removal and triple parity RAID-Z. >>>>> Both of which are well tested at this point via OpenSolaris. >>>>> >>>>> >>>>> >>>> these are very valid points, but I am not sure that anyone has zfs v19= patches >>>> >>>> >>>> > _______________________________________________ > 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 Olivier Smedts=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 _ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ASCII ri= bbon campaign ( ) e-mail: olivier@gid0.org=C2=A0 =C2=A0 =C2=A0 =C2=A0 - against HTML email & = vCards=C2=A0 X www: http://www.gid0.org=C2=A0 =C2=A0 - against proprietary attachments / \ =C2=A0 "Il y a seulement 10 sortes de gens dans le monde : =C2=A0 ceux qui comprennent le binaire, =C2=A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 17:53:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFEEE1065672 for ; Mon, 12 Jul 2010 17:53:54 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id A91048FC16 for ; Mon, 12 Jul 2010 17:53:54 +0000 (UTC) Received: from [77.41.96.17] (port=15385 helo=dc7700p.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OYNCS-000KPX-JV for freebsd-current@freebsd.org; Mon, 12 Jul 2010 21:53:52 +0400 Message-ID: <4C3B56B0.7000107@lissyara.su> Date: Mon, 12 Jul 2010 21:53:52 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.9.1.10) Gecko/20100627 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4C35FFE7.8010809@lissyara.su> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: Re: WARNING: Non-uniform processors. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 17:53:55 -0000 09.07.2010 14:41, Ivan Voras пишет: > On 07/08/10 18:42, Alex Keda wrote: >> When booting, I have strange message. >> All work OK (processor with hyperthreading, but system seems it as 1 CPU ). >> lissyara-gp# dmesg >> Copyright (c) 1992-2010 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 9.0-CURRENT #0 r209745: Wed Jul 7 06:08:36 MSD 2010 >> root@lissyara-gp.grand-prix:/usr/obj/usr/src/sys/GENERIC i386 >> WARNING: WITNESS option enabled, expect reduced performance. >> CPU: Intel(R) Pentium(R) 4 CPU 3.06GHz (3056.87-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9 >> >> Features=0xbfebfbff >> >> Features2=0x4400 >> real memory = 1611137024 (1536 MB) >> avail memory = 1559203840 (1486 MB) >> Event timer "LAPIC" frequency 0 Hz quality 500 >> ACPI APIC Table: >> WARNING: Non-uniform processors. >> WARNING: Using suboptimal topology. >> ioapic0: Changing APIC ID to 8 >> ioapic0 irqs 0-23 on motherboard >> kbd1 at kbdmux0 >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: reservation of 0, a0000 (3) failed >> acpi0: reservation of 100000, 5ff00000 (3) failed >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0:<24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 >> cpu0: on acpi0 > > Yes, your situation looks a bit strange, but maybe it's because of the > Compaq (or early HPaq) brand, they did strange things with BIOSes in > those days. > > Apparently, the OS detects only one logical CPU (no hyperthreading) on > your system, but it looks like HTT is enabled, so this might be the > cause of your message. > > In any case, you will probably not have any problems with this > configuration. HTT in those days sucked anyway. > > On the other hand, you are running a CURRENT kernel with WITNESS and > other debugging enabled, so as the boot message says, expect your system > to run very slow. OK. Thanks for explanation! From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 20:04:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26B081065670; Mon, 12 Jul 2010 20:04:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 236588FC23; Mon, 12 Jul 2010 20:04:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=HRj3ij7MtkgA:10 a=UBIxAjGgU1YA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=hwjHTafsMXyKm7GaZ_oA:9 a=Jx0BzAULFPxU7FjL2gn-SgJJS_MA:4 a=wPNLvfGTeEIA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1378929241; Mon, 12 Jul 2010 22:04:06 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 12 Jul 2010 22:01:11 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.1-PRERELEASE; KDE/4.3.4; amd64; ; ) References: <201007072113.16320.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007122201.11534.hselasky@c2i.net> Cc: Sam Leffler , PseudoCylon , freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 20:04:09 -0000 Hi Andrew, Your patch appears to be working. Can you fix this issue in the other WLAN drivers aswell? Then send an e-mail to request testing? I had a go at it here: http://p4web.freebsd.org/@@180844?ac=10 I found another panic issue: ifconfig wlan0 delete ifconfig wlan0 destroy When not associate or associated. Backtrace (AMD64 - 9-current): node_free() + 0x2c rum_tx_free() + 0x3b which is called from the bulk tx callback Another thread is running an IOCTL -> rum_stop(), which causes the CANCELLED event to be passed to USB. Can't we free any nodes at this point? --HPS > This turned out to be refcounting of the ieee80211_node struct which > was causing this panic. vap->iv_bss can be freed at any time so all > users of it need to bump the refcount to use it safely. > > This patch should fix the panic in the rum driver. > http://people.freebsd.org/~thompsa/rum_node_refcnt.diff > > There are other places where it is still an issue such as the > ieee80211_tx_mgt_timeout callout which havnt been addressed yet, and > of course all other ieee80211 drivers. > From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 20:13:35 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37A9A106566B for ; Mon, 12 Jul 2010 20:13:35 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id EC2E08FC1D for ; Mon, 12 Jul 2010 20:13:34 +0000 (UTC) Received: from smtp.hudson-trading.com ([209.249.190.9] helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OYMc2-0000rS-65 for current@freebsd.org; Mon, 12 Jul 2010 13:16:14 -0400 From: George Neville-Neil Content-Type: multipart/mixed; boundary=Apple-Mail-10-63366 Date: Mon, 12 Jul 2010 13:16:13 -0400 Message-Id: <59EEB71E-1FE5-430C-85DF-52727AE7805D@neville-neil.com> To: current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: hwpmc on Intel Core architectures fixed counters 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, 12 Jul 2010 20:13:35 -0000 --Apple-Mail-10-63366 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Howdy, If anyone is using hwpmc on core architectures, i.e. Core, Core2, = Nehalem, Westmere, can you please test the following patch which fixes occasional panics of this = code on those=20 processors? The specific bug address comes when sampling the IAF (Fixed = Function) counters which are:=20 IAF INSTR_RETIRED_ANY CPU_CLK_UNHALTED_CORE CPU_CLK_UNHALTED_REF I plan to commit this to HEAD this week. I have tested it on HEAD and = 7.X. Thanks, George --Apple-Mail-10-63366 Content-Disposition: attachment; filename=head-iaf-wrmsr.patch Content-Type: application/octet-stream; x-unix-mode=0664; name="head-iaf-wrmsr.patch" Content-Transfer-Encoding: 7bit Index: sys/dev/hwpmc/hwpmc_core.c =================================================================== --- sys/dev/hwpmc/hwpmc_core.c (revision 209857) +++ sys/dev/hwpmc/hwpmc_core.c (working copy) @@ -147,6 +147,7 @@ int core_ri, n, npmc; struct pmc_cpu *pc; struct core_cpu *cc; + uint64_t msr = 0; KASSERT(cpu >= 0 && cpu < pmc_cpu_max(), ("[core,%d] insane cpu number (%d)", __LINE__, cpu)); @@ -166,11 +167,14 @@ npmc = md->pmd_classdep[PMC_MDEP_CLASS_INDEX_IAP].pcd_num; core_ri = md->pmd_classdep[PMC_MDEP_CLASS_INDEX_IAP].pcd_ri; - for (n = 0; n < npmc; n++) - wrmsr(IAP_EVSEL0 + n, 0); + for (n = 0; n < npmc; n++) { + msr = rdmsr(IAP_EVSEL0 + n); + wrmsr(IAP_EVSEL0 + n, msr & ~IAP_EVSEL_MASK); + } if (core_cputype != PMC_CPU_INTEL_CORE) { - wrmsr(IAF_CTRL, 0); + msr = rdmsr(IAF_CTRL); + wrmsr(IAF_CTRL, msr & ~IAF_CTRL_MASK); npmc += md->pmd_classdep[PMC_MDEP_CLASS_INDEX_IAF].pcd_num; } @@ -374,6 +378,7 @@ { struct pmc *pm; struct core_cpu *iafc; + uint64_t msr = 0; KASSERT(cpu >= 0 && cpu < pmc_cpu_max(), ("[core,%d] illegal CPU value %d", __LINE__, cpu)); @@ -387,12 +392,15 @@ iafc->pc_iafctrl |= pm->pm_md.pm_iaf.pm_iaf_ctrl; - wrmsr(IAF_CTRL, iafc->pc_iafctrl); + msr = rdmsr(IAF_CTRL); + wrmsr(IAF_CTRL, msr | (iafc->pc_iafctrl & IAF_CTRL_MASK)); do { iafc->pc_resync = 0; iafc->pc_globalctrl |= (1ULL << (ri + IAF_OFFSET)); - wrmsr(IA_GLOBAL_CTRL, iafc->pc_globalctrl); + msr = rdmsr(IA_GLOBAL_CTRL); + wrmsr(IA_GLOBAL_CTRL, msr | (iafc->pc_globalctrl & + IAF_GLOBAL_CTRL_MASK)); } while (iafc->pc_resync != 0); PMCDBG(MDP,STA,1,"iafctrl=%x(%x) globalctrl=%jx(%jx)", @@ -407,6 +415,7 @@ { uint32_t fc; struct core_cpu *iafc; + uint64_t msr = 0; PMCDBG(MDP,STO,1,"iaf-stop cpu=%d ri=%d", cpu, ri); @@ -425,12 +434,15 @@ iafc->pc_iafctrl &= ~fc; PMCDBG(MDP,STO,1,"iaf-stop iafctrl=%x", iafc->pc_iafctrl); - wrmsr(IAF_CTRL, iafc->pc_iafctrl); + msr = rdmsr(IAF_CTRL); + wrmsr(IAF_CTRL, msr | (iafc->pc_iafctrl & IAF_CTRL_MASK)); do { iafc->pc_resync = 0; iafc->pc_globalctrl &= ~(1ULL << (ri + IAF_OFFSET)); - wrmsr(IA_GLOBAL_CTRL, iafc->pc_globalctrl); + msr = rdmsr(IA_GLOBAL_CTRL); + wrmsr(IA_GLOBAL_CTRL, msr | (iafc->pc_globalctrl & + IAF_GLOBAL_CTRL_MASK)); } while (iafc->pc_resync != 0); PMCDBG(MDP,STO,1,"iafctrl=%x(%x) globalctrl=%jx(%jx)", @@ -445,6 +457,7 @@ { struct core_cpu *cc; struct pmc *pm; + uint64_t msr; KASSERT(cpu >= 0 && cpu < pmc_cpu_max(), ("[core,%d] illegal cpu value %d", __LINE__, cpu)); @@ -460,9 +473,11 @@ if (PMC_IS_SAMPLING_MODE(PMC_TO_MODE(pm))) v = iaf_reload_count_to_perfctr_value(v); - wrmsr(IAF_CTRL, 0); /* Turn off fixed counters */ - wrmsr(IAF_CTR0 + ri, v); - wrmsr(IAF_CTRL, cc->pc_iafctrl); + msr = rdmsr(IAF_CTRL); + wrmsr(IAF_CTRL, msr & ~IAF_CTRL_MASK); + wrmsr(IAF_CTR0 + ri, v & ((1ULL << core_iaf_width) - 1)); + msr = rdmsr(IAF_CTRL); + wrmsr(IAF_CTRL, msr | (cc->pc_iafctrl & IAF_CTRL_MASK)); PMCDBG(MDP,WRI,1, "iaf-write cpu=%d ri=%d msr=0x%x v=%jx iafctrl=%jx " "pmc=%jx", cpu, ri, IAF_RI_TO_MSR(ri), v, @@ -1879,6 +1894,7 @@ { struct pmc *pm; struct core_cpu *cc; + uint64_t msr; KASSERT(cpu >= 0 && cpu < pmc_cpu_max(), ("[core,%d] illegal cpu value %d", __LINE__, cpu)); @@ -1894,7 +1910,8 @@ PMCDBG(MDP,STO,1, "iap-stop cpu=%d ri=%d", cpu, ri); - wrmsr(IAP_EVSEL0 + ri, 0); /* stop hw */ + msr = rdmsr(IAP_EVSEL0 + ri); + wrmsr(IAP_EVSEL0 + ri, msr & IAP_EVSEL_MASK); /* stop hw */ if (core_cputype == PMC_CPU_INTEL_CORE) return (0); @@ -1937,7 +1954,7 @@ * a stopped state when the pcd_write() entry point is called. */ - wrmsr(IAP_PMC0 + ri, v); + wrmsr(IAP_PMC0 + ri, v & ((1ULL << core_iap_width) - 1)); return (0); } @@ -1987,6 +2004,7 @@ struct pmc *pm; struct core_cpu *cc; int error, found_interrupt, ri; + uint64_t msr = 0; PMCDBG(MDP,INT, 1, "cpu=%d tf=0x%p um=%d", cpu, (void *) tf, TRAPF_USERMODE(tf)); @@ -2018,7 +2036,8 @@ * Stop the counter, reload it but only restart it if * the PMC is not stalled. */ - wrmsr(IAP_EVSEL0 + ri, 0); + msr = rdmsr(IAP_EVSEL0 + ri); + wrmsr(IAP_EVSEL0 + ri, msr & ~IAP_EVSEL_MASK); wrmsr(IAP_PMC0 + ri, v); if (error) Index: sys/dev/hwpmc/hwpmc_core.h =================================================================== --- sys/dev/hwpmc/hwpmc_core.h (revision 209857) +++ sys/dev/hwpmc/hwpmc_core.h (working copy) @@ -67,20 +67,59 @@ /* * Fixed-function counters. */ + #define IAF_MASK 0xF +#define IAF_COUNTER_MASK 0x0000ffffffffffff #define IAF_CTR0 0x309 #define IAF_CTR1 0x30A #define IAF_CTR2 0x30B +/* + * The IAF_CTRL MSR is laid out in the following way. + * + * Bit Position Use + * 63 - 12 Reserved (do not touch) + * 11 Ctr 2 PMI + * 10 Reserved (do not touch) + * 9-8 Ctr 2 Enable + * 7 Ctr 1 PMI + * 6 Reserved (do not touch) + * 5-4 Ctr 1 Enable + * 3 Ctr 0 PMI + * 2 Reserved (do not touch) + * 1-0 Ctr 0 Enable (3: All Levels, 2: User, 1: OS, 0: Disable) + */ + #define IAF_OFFSET 32 #define IAF_CTRL 0x38D +#define IAF_CTRL_MASK 0x0000000000000bbb /* * Programmable counters. */ #define IAP_PMC0 0x0C1 + +/* + * IAP_EVSEL(n) is laid out in the following way. + * + * Bit Position Use + * 63-31 Reserved (do not touch) + * 31-24 Counter Mask + * 23 Invert + * 22 Enable + * 21 Reserved (do not touch) + * 20 APIC Interrupt Enable + * 19 Pin Control + * 18 Edge Detect + * 17 OS + * 16 User + * 15-8 Unit Mask + * 7-0 Event Select + */ + +#define IAP_EVSEL_MASK 0x00000000ffdfffff #define IAP_EVSEL0 0x186 /* @@ -90,6 +129,21 @@ #define IA_GLOBAL_STATUS 0x38E #define IA_GLOBAL_CTRL 0x38F + +/* + * IA_GLOBAL_CTRL is layed out in the following way. + * + * Bit Position Use + * 63-35 Reserved (do not touch) + * 34 IAF Counter 2 Enable + * 33 IAF Counter 1 Enable + * 32 IAF Counter 0 Enable + * 31-0 Depends on programmable counters + */ + +/* The mask is only for the fixed porttion of the register. */ +#define IAF_GLOBAL_CTRL_MASK 0x0000000700000000 + #define IA_GLOBAL_OVF_CTRL 0x390 #define IA_GLOBAL_STATUS_FLAG_CONDCHG (1ULL << 63) --Apple-Mail-10-63366-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 12 21:34:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9334B1065674 for ; Mon, 12 Jul 2010 21:34:30 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [188.40.32.143]) by mx1.freebsd.org (Postfix) with ESMTP id 1943E8FC16 for ; Mon, 12 Jul 2010 21:34:29 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id A6B7C100818; Mon, 12 Jul 2010 23:34:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hvfjRByjlzql; Mon, 12 Jul 2010 23:34:26 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 7F234100811; Mon, 12 Jul 2010 23:34:26 +0200 (CEST) Message-ID: <4C3B8A67.4040807@FreeBSD.org> Date: Mon, 12 Jul 2010 23:34:31 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Olivier Smedts References: <4C31C71C.2010606@FreeBSD.org> <4C357F0A.70009@FreeBSD.org> <4C3594FF.8070907@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "Jason J. W. Williams" , "Sam Fourman Jr." , "freebsd-current@freebsd.org" Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2010 21:34:30 -0000 Upgrading your pool to version 15, compared to version 14, you get only these additional features: - user and group quotas - getting rid of the old version message in zpool status (-x) and these disadvantages: - not importable and/or operable with pre-v15 kernel module and updated boot loader code If you do not need user and group quotas and the message does not disturb you, there is no need to upgrade the pool. Dňa 12. 7. 2010 19:09, Olivier Smedts wrote / napísal(a): > I'm currently trying your patchset, I have updated versions of kernel > and userland zfs code. > > Now, are there any benefits to upgrade the zpool and the zfs to the > latest versions, besides quotas ? From owner-freebsd-current@FreeBSD.ORG Tue Jul 13 01:54:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB60B106566C for ; Tue, 13 Jul 2010 01:54:09 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51801.mail.re2.yahoo.com (web51801.mail.re2.yahoo.com [206.190.38.232]) by mx1.freebsd.org (Postfix) with SMTP id A496D8FC08 for ; Tue, 13 Jul 2010 01:54:09 +0000 (UTC) Received: (qmail 29731 invoked by uid 60001); 13 Jul 2010 01:54:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1278986048; bh=RucMWKr8zZ+iKRVPv3e1DWSq9wdRUys474Hqo8wNciY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Lgva5aUAUPiTmMgfkLGZr7r49XmRovLiuT2Q5oaUFk68WN2lT2FS9oDqAJNyCgZBfKT9PI4omaG7/zzROiDk0FDlzCZ/7gMq5KF7Tez2jusXVSvAW0vvq3Hvn7PvXYJhLzzapKZMMdNXETZHSQgkaAarvDBHfSeO07lRCr0lStk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aGstxQjgnPtjb6NaRbWX48nbjbkkDSK+rc9Glsp8F7nBuKQKWoIEq59roEr8LBGWeijzK1ZXFoAgnwYVcWk4CjxYPlL9t7Zedrmk3e8hY139fVvccGb/Z7t67gHHSzWdO1MXLH8VK4TuoLkh0mUIuo1/viFE4u3dOYDn4uwkYzY=; Message-ID: <768329.28397.qm@web51801.mail.re2.yahoo.com> X-YMail-OSG: 0aHUVxEVM1n1Uf5SdctRgxfkbbRjf0riYvKVYyKlmA7Yojv DeF2JAQ0eTWVEAuoRRfGxqEnYkE0UH7TS8zt1q0p5v5c4anaczPVMmp9BrAg dzFv6hc3w3AXboVUAFL8rYqwNReLW9RDQqIKLq7cgN2GL6XhjILA1GYqoGvu Y3zpFkzTUPOKw269WyTeJRUyoB311uZ.xEC34HTC.epXBLPYYtww2xMVxRWc peqsry412aG.674HP7ZQjivPcTWaVJ6J5aSY951mPlHOmTteO4qECKXXCwX5 UrwqMkRq5qL5gF5QN.vVO6VbViTcPLGwWMRLrelW3uDQ- Received: from [173.183.132.20] by web51801.mail.re2.yahoo.com via HTTP; Mon, 12 Jul 2010 18:54:08 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.104.276605 References: <201007072113.16320.hselasky@c2i.net> <201007122201.11534.hselasky@c2i.net> Date: Mon, 12 Jul 2010 18:54:08 -0700 (PDT) From: PseudoCylon To: Hans Petter Selasky , freebsd-current@freebsd.org In-Reply-To: <201007122201.11534.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Leffler , freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2010 01:54:10 -0000 ----- Original Message ---- > From: Hans Petter Selasky > To: freebsd-current@freebsd.org > Cc: Andrew Thompson ; Sam Leffler ; >PseudoCylon ; freebsd-usb@freebsd.org > Sent: Mon, July 12, 2010 2:01:11 PM > Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers > > Hi Andrew, > > Your patch appears to be working. Can you fix this issue in the other WLAN > drivers aswell? Then send an e-mail to request testing? I had a go at it here: > > http://p4web.freebsd.org/@@180844?ac=10 > Since I wasn't able to reproduce the panic, I can only confirm the patched run(4) driver runs OK. I just want to patch hostap related fix before calling for this test. I'll ask the user if it's fixed. Should the debugging code, usb_pause_mtx(), be left in the code for testing? If the drivers don't panic to begin with, we won't know the patch really fixed the issue. AK > I found another panic issue: > > ifconfig wlan0 delete > ifconfig wlan0 destroy > > When not associate or associated. > > Backtrace (AMD64 - 9-current): > > node_free() + 0x2c > rum_tx_free() + 0x3b > which is called from the bulk tx callback > > Another thread is running an IOCTL -> rum_stop(), which causes the CANCELLED > event to be passed to USB. Can't we free any nodes at this point? > > --HPS > > > This turned out to be refcounting of the ieee80211_node struct which > > was causing this panic. vap->iv_bss can be freed at any time so all > > users of it need to bump the refcount to use it safely. > > > > This patch should fix the panic in the rum driver. > > http://people.freebsd.org/~thompsa/rum_node_refcnt.diff > > > > There are other places where it is still an issue such as the > > ieee80211_tx_mgt_timeout callout which havnt been addressed yet, and > > of course all other ieee80211 drivers. > > > From owner-freebsd-current@FreeBSD.ORG Tue Jul 13 02:02:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4D07106566B for ; Tue, 13 Jul 2010 02:02:29 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51805.mail.re2.yahoo.com (web51805.mail.re2.yahoo.com [206.190.38.236]) by mx1.freebsd.org (Postfix) with SMTP id 5EF248FC16 for ; Tue, 13 Jul 2010 02:02:29 +0000 (UTC) Received: (qmail 54933 invoked by uid 60001); 13 Jul 2010 02:02:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1278986548; bh=TR943d6vndZOGRH63W8veJ06a9REdbubt842v9/fbjg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Iy8gyeDFAl01k9WittjqRvs7i4Di7Jijs2Clv5yO57QT3Oygaqc1pCDqnFSeMZ+KCn9ZgICWayr0g2zfeFVYCTmYM7SXGA+BOl1fMSIErATA58EjFIzCk3sWkjhoBj+1bu/tpIv1/ZFdhNvyiVVX9VPWrcyWnAmoE9+wDflWilA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=RD/ZLzWP7u+H+f5d3glxzULkTHpHUpVaVCaSLlIRMs8WJ0E7uKRftn/0U668T1M0vcw5YjLT7i+yMhcQlq20AyhRCSvinjPOMyjwS419gLNEBThd5mOU9XNz0t+WfsKA0sbuRdaktRZkoMUCKwcEa4KXPXbhPIT+q7cUvOZt3/M=; Message-ID: <597509.54869.qm@web51805.mail.re2.yahoo.com> X-YMail-OSG: g_ZgfLoVM1lbgAsI32pVsZDezIYUuqqEZ7RfhXxCSqZ_jSC TUlGLcQfu0g6k5ZXIY03lnjNBgrgmSphQKBT5X8kx1jiJgrZ_ZAnYkt6BzHy rM.Ug9_hAOg_8gRdnJkcvlqhNk.t3o0cqbDvuebg0Szf5bDP3dLzZ9.8Iu5f 4wLLt.zwVCCt7jkeVFdZOJsebuJUa5sc68eXWHkwO74_fld5JKqGTLKW5.JS neX2BbOHBPSZG8sj7fi3aRQUX9dMHw.448nNDzUADUO02p69fzweJcIp0YKc nJy7O2UHeQUGLLXd5jahP9V1p4IIJy.YcROBI0AeWFdlp9LI4 Received: from [173.183.132.20] by web51805.mail.re2.yahoo.com via HTTP; Mon, 12 Jul 2010 19:02:28 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.104.276605 Date: Mon, 12 Jul 2010 19:02:28 -0700 (PDT) From: PseudoCylon To: Ganbold Tsagaankhuu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, Ganbold Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2010 02:02:29 -0000 ----- Original Message ---- > From: PseudoCylon > To: Ganbold Tsagaankhuu > Cc: Ganbold ; freebsd-current@freebsd.org > Sent: Tue, July 6, 2010 12:26:58 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > >>>>>> From: Ganbold > >>>>>> To: PseudoCylon > >>>>>> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu > > >>>>>> Sent: Wed, June 16, 2010 6:33:47 AM > >>>>>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > >>>>>> > >>>>>> AK-san, > >>>>>> > >>>>>> > >>>>> PseudoCylon wrote: > >>>>> > >>>>> Strange, looks like this time works as expected, but sometimes it > >>>>> doesn't work. > >>>>> > >>>>> In some cases it doesn't work and you can find complete tcpdump output > >>>>> from very beginning to the modem hang: > >>>>> > >>>>> > >>>>> > >>>> Hello, > >>>> > >>>> Are following true? > >>>> When manually load/reload hostapd, works > >>>> When loaded by rc.conf, doesn't work > >>>> > >>>> If so, please try attached patch. (patch to if_run.c only) Or, here is a >patched file. > >>>> http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c > >>>> > >>>> When auto-loading, the driver is brought up and down a few times. It >might be the cause. > >>>> > >>> I will test it few more days and let you know. > >>> > >>> thanks, > >>> > >>> Ganbold > >>> > >> Hello, > >> > >> How is the patch doing on your rspro? Is it working well? > >> > > > >Sorry for late response. Due to business trip I tested couple of times > >only and it seems working relatively ok. 1-2 times ADSL modem hang, but > >seemed like after 3-4 hours. > >Tried couple of times again, but I couldn't reproduce it. I will try to > >reproduce it and let you know the results. > > > >thanks a lot, > > > >Ganbold > Hello, Ganbold Is the latest patch working? AK > Hello, > > I say every one has a job. > > At least it's start up OK, right? > > Can you try attached patch? (patch to if_run.c you currently using) Or, here >is a patched file > http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c > > I encountered similar problem about 5 days ago. It kind of hard to reproduce. >A couple of things have to happen at the right (or wrong) time. > > If the modem still hangs at the start up, please let me know. That means the >last patch isn't working. > > AK > > -- begin patch -- > > diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c > index f302246..e5a2a4d 100644 > --- a/dev/usb/wlan/if_run.c > +++ b/dev/usb/wlan/if_run.c > @@ -888,8 +888,7 @@ run_cmdq_cb(void *arg, int pending) > > /* call cmdq[].func locked */ > RUN_LOCK(sc); > -for(i = sc->cmdq_exec; sc->cmdq[i].func && pending; > - i = sc->cmdq_exec, pending--){ > +for(i = sc->cmdq_exec; sc->cmdq[i].func; i = sc->cmdq_exec){ > DPRINTFN(6, "cmdq_exec=%d pending=%d\n", i, pending); > if(sc->cmdq_run == RUN_CMDQ_GO || > (sc->cmdq_key_set == RUN_CMDQ_GO && > > -- end patch -- > > > > From owner-freebsd-current@FreeBSD.ORG Tue Jul 13 06:48:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04B31106566C; Tue, 13 Jul 2010 06:48:35 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id DDB998FC18; Tue, 13 Jul 2010 06:48:33 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=HRj3ij7MtkgA:10 a=UBIxAjGgU1YA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=xe-73Pwk_GwCdW-hIm4A:9 a=7AFlrT4Ur7Y_3Ul-qMCJpxDMks0A:4 a=wPNLvfGTeEIA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1404564908; Tue, 13 Jul 2010 08:48:31 +0200 From: Hans Petter Selasky To: PseudoCylon Date: Tue, 13 Jul 2010 08:45:36 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.1-PRERELEASE; KDE/4.3.4; amd64; ; ) References: <201007072113.16320.hselasky@c2i.net> <201007122201.11534.hselasky@c2i.net> <768329.28397.qm@web51801.mail.re2.yahoo.com> In-Reply-To: <768329.28397.qm@web51801.mail.re2.yahoo.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007130845.36437.hselasky@c2i.net> Cc: Sam Leffler , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2010 06:48:35 -0000 On Tuesday 13 July 2010 03:54:08 PseudoCylon wrote: > Should the debugging code, usb_pause_mtx(), be left in the code for > testing? If the drivers don't panic to begin with, we won't know the > patch really fixed the issue. > No, I think it is safe to remove it. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jul 13 08:50:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9E91106567F for ; Tue, 13 Jul 2010 08:50:28 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas01p.mx.bigpond.com (nschwmtas01p.mx.bigpond.com [61.9.189.137]) by mx1.freebsd.org (Postfix) with ESMTP id 4420E8FC21 for ; Tue, 13 Jul 2010 08:50:27 +0000 (UTC) Received: from nschwotgx01p.mx.bigpond.com ([124.188.161.100]) by nschwmtas01p.mx.bigpond.com with ESMTP id <20100713085026.IRTE1369.nschwmtas01p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com> for ; Tue, 13 Jul 2010 08:50:26 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20100713085025.VPDB7719.nschwotgx01p.mx.bigpond.com@duncan.reilly.home> for ; Tue, 13 Jul 2010 08:50:25 +0000 Date: Tue, 13 Jul 2010 18:50:25 +1000 From: Andrew Reilly To: freebsd-current@freebsd.org Message-ID: <20100713085025.GA1836@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx01p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Tue, 13 Jul 2010 08:50:25 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090203.4C3C28D2.00F7,ss=1,fgs=0 X-SIH-MSG-ID: rh4zGdX9TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rHNvZRu8u6xD9PJhqNNGQgaa7iTY3Rs9mK Subject: Samba wedged: what does it mean? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2010 08:50:28 -0000 Hi there, I've been providing a light-use samba server on my freebsd-current box, mostly for secondary storage my wife's laptop. It's worked mostly-fine for a dozen years. I've never seen anything like this before, and am not sure where to start poking it. Here's the output of netstat and ps, for the suspicious bits. It's been sitting like that for just shy of twelve hours. Nothing else on the system seems to be broken. I've stopped samba: only these wedged copies exist. Any way out, short of a reboot? This is on: FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Fri Jul 9 21:05:44 EST 2010 root@duncan.reilly.home:/nb/obj/nb/src/sys/DUNCAN amd64 The samba34 server was serving an un-journalled UFS2+SU file system. Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 263 0 duncan.microsoft-ds irulan.51095 CLOSED tcp4 278 0 duncan.microsoft-ds irulan.51094 CLOSED tcp4 515 0 duncan.microsoft-ds irulan.50915 CLOSED tcp4 82 0 duncan.microsoft-ds irulan.50869 CLOSED tcp4 194 0 duncan.microsoft-ds irulan.50800 CLOSED tcp4 419 0 duncan.microsoft-ds irulan.50596 CLOSED tcp4 194 0 duncan.microsoft-ds irulan.50572 CLOSED tcp4 337 0 duncan.microsoft-ds irulan.50551 CLOSED tcp4 1024 0 duncan.microsoft-ds irulan.50546 CLOSED tcp4 680 0 duncan.microsoft-ds irulan.50442 CLOSED tcp4 82 0 duncan.microsoft-ds irulan.50410 CLOSED tcp4 360 0 duncan.microsoft-ds irulan.49285 CLOSED root 119 0.0 0.2 49904 7816 ?? D 6:17am 0:00.77 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 187 0.0 0.2 49692 7016 ?? D 6:55am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 188 0.0 0.3 49904 7896 ?? D 6:56am 0:01.93 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 212 0.0 0.2 49692 7096 ?? D 7:06am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 215 0.0 0.3 49904 8268 ?? D 7:07am 0:03.59 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 233 0.0 0.2 49692 7052 ?? D 7:16am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 234 0.0 0.3 49904 8040 ?? D 7:17am 0:01.11 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 252 0.0 0.2 49692 7080 ?? D 7:25am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 253 0.0 0.2 49692 7060 ?? D 7:26am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 254 0.0 0.3 49904 7844 ?? D 7:27am 0:00.29 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 447 0.0 0.2 49692 7268 ?? D 7:52am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf root 448 0.0 0.2 49692 7240 ?? D 7:53am 0:00.01 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Tue Jul 13 03:14:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C6A71065674 for ; Tue, 13 Jul 2010 03:14:05 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 23FFE8FC1E for ; Tue, 13 Jul 2010 03:14:04 +0000 (UTC) Received: by vws6 with SMTP id 6so248155vws.13 for ; Mon, 12 Jul 2010 20:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=/ZFCiEoJsHrYH0OMmNrcT9KNI02luGcnEq/ddSOfyck=; b=gDexsEKq0k5YepD7vhd25b5OW//1PILDxOdKrVZp1Bgtp6geep6BpuxcuAtcpHY3J4 nEBJSG0F8cBSRCfQAjVoNPCA2j7hh7rS4wTbOHpg2VRzXj7U8h0x2wBrFY7dSub02XTR 8URiBqqmDunr2fH+KSm5fWth/ddFW5Ie7Cn70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=q1KwrCNQI3mi1+3KJXuQ/zzpGLYW7sbpvmbm1+7jyxGr5F636cWNn5zPxizLfGuJLn kt1J4V3bumGU+molJtRQkzAqZGQXeTlvAIRe15/PPoZErGxOZOyLU79daRVOyXv6LSJx rhY0jqKorcYhmOKz+5yrXMFZayUobXioYHIPc= MIME-Version: 1.0 Received: by 10.220.121.233 with SMTP id i41mr7427339vcr.143.1278990844207; Mon, 12 Jul 2010 20:14:04 -0700 (PDT) Received: by 10.220.203.204 with HTTP; Mon, 12 Jul 2010 20:14:04 -0700 (PDT) Date: Mon, 12 Jul 2010 23:14:04 -0400 Message-ID: From: grarpamp To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 13 Jul 2010 11:18:45 +0000 Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2010 03:14:05 -0000 Wanted to say thank you for those working on keeping ZFS up to date :-) Are all the non-FreeBSD specific fixes being made by the FreeBSD team being punted back up to the [Open]Solaris folks so that they may include them in their native ZFS... and thus trickle back down to FreeBSD, thereby minimizing the overall FreeBSD porting/review changeset? Here is the ZFS site's list of the major version differences for reference. Note that I think upwards resize and maybe one other commonly requested item are actually present in one of these versions but didn't make it into the log below, it's probably on zfs-discuss though. [zpool v15, zfs v4] seems to be a good spot... till ZFS-crypto ;-) Thanks! http://hub.opensolaris.org/bin/view/Community+Group+zfs/n [zpool] http://hub.opensolaris.org/bin/view/Community+Group+zfs/n-1 [zfs] ======================================== ZFS File System Version 5 This version includes support for the following feature: * System attributes This feature is available in: * Nevada, build 137 The related change requests are: * 6716117 ZFS needs native system attribute infrastructure * 6516171 zpl symlinks should have their own object type ======================================== ZFS File System Version 4 This version includes support for the following features: * userused@... and groupused@... properties * userquota@... and groupquota@... properties These features are available in: * Solaris Express Community Edition, build 114 The related bug and PSARC case for version 4 changes are: * 6501037 want user/group quotas on ZFS * PSARC 2009/204 ZFS user/group quotas & space accounting ======================================== ZFS File System Version 3 This version includes support for the following features: * Support for sharing ZFS file systems over CIFS * Case insensitivity support * System attribute support * Integrated anti-virus support These features integrated into the following release: * Solaris Express Community Edition, build 77 These features were integrated with the following bug fixes: * 6617183 CIFS Service PSARC 2006/715 * 6546893 Solaris system attribute support * 6417428 Case-insensitive file system name lookup to support CIFS * 6417435 DOS attributes and additional timestamps to support for CIFS * 6417442 File system quarantined and modified attributes to support an integrated Anti-Virus service ======================================== ZFS File System Version 2 This version includes support for the following features: * Enhanced directory entries. In particular, directory entries now store the object type, (for example, file, directory, named pipe, and so on) in addition to the object number. * Upgrading ZFS file systems to provide future ZFS file system enhancements to existing file systems. These features were integrated with the following bug fixes: * 6572637 store object type in directory entries * PSARC/2007/328 zfs upgrade These features are available in: * Solaris Express Community Edition, build 69 ======================================== File System Version 1 This page describes the features that are available with version 1 of the ZFS file system on-disk format (not the pool version). Because this is the initial ZFS on-disk format that integrated on 10/31/05, see the list of initial features in the ZFS Admin Guide. The first official releases supporting this version are: * Solaris Express Community Edition, build 36 * Solaris 10 6/06 release ======================================== ======================================== ZFS Pool Version 24 This version includes support for system attributes. Pool version 24 is available in this release: * Nevada, build 137 The change records for the version 24 change are: * 6716117 ZFS needs native system attribute infrastructure * 6516171 zpl symlinks should have their own object type ======================================== ZFS Pool Version 23 This version includes support for the slim ZIL. Pool version 23 is available in this release: * OpenSolaris, build 135 The change record for the version 23 change is: * 6595532 ZIL is too talkative ======================================== ZFS Pool Version 22 This version includes support for zfs receive properties. Pool version 22 is available in this release: * Solaris Express Community Edition, build 128 The PSARC case for the version 22 change is: * PSARC/2009/510 ZFS Received Properties ======================================== ZFS Pool Version 21 This version includes support for ZFS deduplication properties. Pool version 21 is available in this release: * Solaris Express Community Edition, build 128 The PSARC case for the version 21 change is: * PSARC/2009/571 ZFS Deduplication Properties ======================================== ZFS Pool Version 20 This version includes the zle compression algorithm that is needed to support the ZFS deduplication properties in ZFS pool version 21. Both pool versions are available in this release: * Solaris Express Community Edition, build 128 The PSARC case for the version 20 change is: * PSARC/2009/571 ZFS Deduplication Properties ======================================== ZFS Pool Version 19 This version includes support for the following feature: * ZFS log device removal This feature is available in: * Solaris Express Community Edition, build 125 The related change record for the version 19 change is: * 6574286 removing a slog doesn't work ======================================== ZFS Pool Version 18 This version includes support for the following feature: * ZFS snapshot holds This feature is available in: * Solaris Express Community Edition, build 121 The related change record for the version 18 change is: * 6803121 want user-settable refcounts on snapshots ======================================== ZFS Pool Version 17 This version includes support for the following feature: * triple-parity RAID-Z This feature is available in: * Solaris Express Community Edition, build 120 The related change record for the version 17 change is: * 6854612 triple-parity RAID-Z ======================================== ZFS Pool Version 16 This version includes support for the following feature: * stmf property support This feature is available in: * Solaris Express Community Edition, build 116 The related bug for the version 16 change is: * 6736004 zvols need an additional property for comstar support ======================================== ZFS Pool Version 15 This version includes support for the following features: * userused@... and groupused@... properties * userquota@... and groupquota@... properties These features are available in: * Solaris Express Community Edition, build 114 The related bug and PSARC case for version 15 changes are: * 6501037 want user/group quotas on ZFS * PSARC 2009/204 ZFS user/group quotas & space accounting ======================================== ZFS Pool Version 14 This version includes support for the following feature: * passthrough-x aclinherit property support This feature is available in: * Solaris Express Community Edition, build 103 The related bug and PSARC case for the version 14 change are: * 6765166 Need to provide mechanism to optionally inherit ACE_EXECUTE * PSARC 2008/659 New ZFS "passthrough-x" ACL inheritance rules ======================================== ZFS Pool Version 13 This version includes support for the following features: * usedbysnapshots property * usedbychildren property * usedbyrefreservation property * usedbydataset property These features are available in: * Solaris Express Community Edition, build 98 The related bug and PSARC case for version 13 change is: * 6730799 want snapused property * PSARC 2008/518 ZFS space accounting enhancements ======================================== ZFS Pool Version 12 This version includes support for the following feature: * Properties for Snapshots This feature is available in: * Solaris Express Community Edition, build 96 The related bug for the version 12 change is: * 6701797 want user properties on snapshots ======================================== ZFS Pool Version 11 This version includes support for the following feature: * Improved zpool scrub / resilver performance This feature is available in: * Solaris Express Community Edition, build 94 The related bug for the version 11 change is: * 6343667 scrub/resilver has to start over when a snapshot is taken * (Note, this bug is fixed when using build 94 even with older pool versions. However, upgrading the pool can improve scrub performance when there are many filesystems, snapshots, and clones.) ======================================== ZFS Pool Version 10 This version includes support for the following feature: * Devices can be added to a storage pool as "cache devices." These devices provide an additional layer of caching between main memory and disk. Using cache devices provides the greatest performance improvement for random read-workloads of mostly static content. This feature is available in the Solaris Express Community Edition, build 78. The Solaris 10 10/08 release includes ZFS pool version 10, but support for cache devices is not included in this Solaris release. The related bug for the version 10 change is: * 6536054 second tier ("external") ARC ======================================== ZFS Pool Version 9 This version includes support for the following features: * In addition to the existing ZFS quota and reservation features, this release includes dataset quotas and reservations that do not include descendent datasets, such as snapshots and clones, in the space consumption. ("zfs set refquota" and "zfs set refreservation".) * A reservation is automatically set when a non-sparse ZFS volume is created that matches the size of the volume. This release provides an immediate reservation feature so that you set a reservation on a non-sparse volume with enough space to take snapshots and modify the contents of the volume. * CIFS server support These features are available in Solaris Express Community Edition, build 77. The related bugs for version 9 changes are: * 6431277 want filesystem-only quotas * 6483677 need immediate reservation * 6617183 CIFS Service PSARC 2006/715 ======================================== ZFS Pool Version 8 This version now supports the ability to delegate zfs(1M) administrative tasks to ordinary users. This feature is available in: * Solaris Express Community Edition, build 69 * Solaris 10 10/08 release The related bug for the version 8 change is: * 6349470 investigate non-root restore/backup ======================================== ZFS Pool Version 7 This version includes support for the following feature: The ZFS Intent Log (ZIL) satisfies the need of some applications to know the data they changed is on stable storage on return from a system call. The Intent Log holds records of those system calls and they are replayed if the system power fails or panics if they have not been committed to the main pool. When the Intent Log is allocated from the main pool, it allocates blocks that chain through the pool. This version adds the capability to specify a separate Intent Log device or devices. This feature is available in: * Solaris Express Community Edition, build 68 * Solaris 10 10/08 release The related bug for the version 7 change is: * 6339640 Make ZIL use NVRAM when available. ======================================== ZFS Pool Version 6 This version includes support for the following feature: * 'bootfs' pool property This feature is available in: * Solaris Express Community Edition, build 62 * Solaris 10 10/08 release The related bugs for version 6 changes are as follows: * 4929890 ZFS Boot support for the x86 platform * 6479807 pools need properties ======================================== ZFS Pool Version 5 This version includes support for the following feature: * gzip compression for ZFS datasets This feature is available in: * Solaris Express Community Edition, build 62 * Solaris 10 10/08 release The related bug for the version 5 changes is: * 6536606 gzip compression for ZFS ======================================== ZFS Pool Version 4 This version includes support for the following feature: * zpool history This feature is available in: * Solaris Express Community Edition, build 62 * Solaris 10 8/07 release The related bugs for version 4 changes are as follows: * 6529406 zpool history needs to bump the on-disk version * 6343741 want to store a command history on disk ======================================== ZFS Pool Version 3 This version includes support for the following features: * Hot spares * Double-parity RAID-Z (raidz2) * Improved RAID-Z accounting These features are available in: * Solaris Express Community Edition, build 42 * Solaris 10 11/06 release, (build 3) The related bugs for version 3 changes are as follows: * 6405966 Hot Spare support in ZFS * 6417978 double parity RAID-Z a.k.a. RAID6 * 6288488 du reports misleading size on RAID-Z ======================================== ZFS Pool Version 2 This version includes support for "Ditto Blocks", or replicated metadata. Due to the tree-like structure of the ZFS on-disk format, an uncorrectable error in a leaf block may be relatively benign, while an uncorrectable error in pool metadata can result in an unopenable pool. This feature introduces automatic replication of metadata (up to 3 copies of each block) independent of any underlying pool-wide redundancy. For example, on a pool with a single mirror, the most critical metadata will appear three times on each side of the mirror, for a total of six copies. This ensures that while user data may be lost due to corruption, all data in the pool will be discoverable and the pool will still be usable. This will be expanded in the future to allow user data replication on a per-dataset basis. This feature was integrated on 4/10/06 with the following bug fix: 6410698 ZFS metadata needs to be more highly replicated (ditto blocks) This feature is available in: * Solaris Express Community Edition, build 38 * Solaris 10 10/06 release (build 09) ======================================== ZFS Pool Version 1 This is the initial ZFS on-disk format as integrated on 10/31/05. During the next six months of internal use, there were a few on-disk format changes that did not result in a version number change, but resulted in a flag day since earlier versions could not read the newer changes. The first official releases supporting this version are: * Solaris Express Community Edition, build 36 * Solaris 10 6/06 release Earlier releases may not support this version, despite being formatted with the same on-disk number. This is due to: 6389368 fat zap should use 16k blocks (with backwards compatability) 6390677 version number checking makes upgrades challenging ======================================== From owner-freebsd-current@FreeBSD.ORG Tue Jul 13 14:02:44 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D813D1065670 for ; Tue, 13 Jul 2010 14:02:44 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [188.40.32.143]) by mx1.freebsd.org (Postfix) with ESMTP id 5610E8FC12 for ; Tue, 13 Jul 2010 14:02:44 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 5A65F101D0F for ; Tue, 13 Jul 2010 16:02:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bOMMv4ySyzx2 for ; Tue, 13 Jul 2010 16:02:41 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 40090101D06 for ; Tue, 13 Jul 2010 16:02:41 +0200 (CEST) Message-ID: <4C3C7202.7090103@FreeBSD.org> Date: Tue, 13 Jul 2010 16:02:42 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit Cc: Subject: [HEADSUP] ZFS version 15 committed to head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2010 14:02:44 -0000 Dear community, as you may have noticed, ZFS v15 support with many bugfixes was committed to head in revision 209962. The commit was tagged for MFC, so if there are no stopper issues I am going to commit it to stable/8 in 2 months from today. Here is a short summary of what we gained with this update: 1. Stability - more mature ZFS code, comparable to Solaris 10 update 8 with latest bugfixes 2. Compatibility - Solaris 10 update 8 default ZFS pools can now be imported into FreeBSD 3. Features - user and group quotas (ZFS-internal) are very useful for intranet fileservers that want to use ZFS 4. Speed - my real-world benchmarks give a 15-20% RPS yield in PHP webserver workloads with codebase on ZFS I would like to thank everybody who helped testing the upgrade before it got commited. For the future, it would be very nice to reply not only to my e-mail but to the mailing list, too, so we can share the experience with others. For people interested in running this on 8.1 I will provide patches for releng/8.1 and stable/8 as soon as 8.1 gets released. Feel free to test everything and don't forget to report any bugs found. Cheers, mm From owner-freebsd-current@FreeBSD.ORG Tue Jul 13 16:30:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A55AC106566C for ; Tue, 13 Jul 2010 16:30:21 +0000 (UTC) (envelope-from jasonjwwilliams@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4BFC18FC1F for ; Tue, 13 Jul 2010 16:30:20 +0000 (UTC) Received: by vws19 with SMTP id 19so679399vws.13 for ; Tue, 13 Jul 2010 09:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vLfVFeftq0gxSHlDSlJ8UnYRgGVx06yTltHEXTUjV/I=; b=mHAJWZ4rBZbZxmabK2tlqnh5KYuhHQD/tY4VVsHIWzIz8PeRU5hEJv78Q8zYLdFVIG LayQvlkARuFxQBid9HeSGo9TIXVPd3vXChwqZnHPbeXJRRiyyPxZrKjOPoAIdMrOEBxK oGXjlwPMbRXrLKeDNUVX3dhe3JeUI4RYCtOw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T5/VX6t8QQib5B9RDuCg7D0CzCe7qCec7/lVeXGra1vnaQBvqi6beX3U+aDZvfmNNi IdcDWDhk8IcG3qPvNbXsZQ6bXk45obtxpjL8xcrXGwJeQTp5vvatnz+pXrktWcO6jiGj Bm9gKzY6Rn4wDYmuWHPr/VQd8aHOjXy4bJ20M= MIME-Version: 1.0 Received: by 10.220.88.224 with SMTP id b32mr7936613vcm.217.1279038620352; Tue, 13 Jul 2010 09:30:20 -0700 (PDT) Received: by 10.220.202.68 with HTTP; Tue, 13 Jul 2010 09:30:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 10:30:20 -0600 Message-ID: From: "Jason J. W. Williams" To: grarpamp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2010 16:30:21 -0000 If there's any way to backport ZFS log device removal that would be very helpful. That's the primary hold up for ops folks moving our OpenSolaris servers to FreeBSD. -J On Mon, Jul 12, 2010 at 9:14 PM, grarpamp wrote: > Wanted to say thank you for those working on keeping ZFS up to date :-) > > Are all the non-FreeBSD specific fixes being made by the FreeBSD team > being punted back up to the [Open]Solaris folks so that they may include > them in their native ZFS... and thus trickle back down to FreeBSD, thereb= y > minimizing the overall FreeBSD porting/review changeset? > > Here is the ZFS site's list of the major version differences for referenc= e. > > Note that I think upwards resize and maybe one other commonly requested > item are actually present in one of these versions but didn't make it int= o > the log below, it's probably on zfs-discuss though. > > [zpool v15, zfs v4] seems to be a good spot... till ZFS-crypto ;-) > Thanks! > > http://hub.opensolaris.org/bin/view/Community+Group+zfs/n =A0 [zpool] > http://hub.opensolaris.org/bin/view/Community+Group+zfs/n-1 [zfs] > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS File System Version 5 > > This version includes support for the following feature: > > =A0 =A0* System attributes > > This feature is available in: > > =A0 =A0* Nevada, build 137 > > The related change requests are: > > =A0 =A0* 6716117 ZFS needs native system attribute infrastructure > =A0 =A0* 6516171 zpl symlinks should have their own object type > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS File System Version 4 > > This version includes support for the following features: > > =A0 =A0* userused@... and groupused@... properties > =A0 =A0* userquota@... and groupquota@... properties > > These features are available in: > > =A0 =A0* Solaris Express Community Edition, build 114 > > The related bug and PSARC case for version 4 changes are: > > =A0 =A0* 6501037 want user/group quotas on ZFS > =A0 =A0* PSARC 2009/204 ZFS user/group quotas & space accounting > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS File System Version 3 > > This version includes support for the following features: > > =A0 =A0* Support for sharing ZFS file systems over CIFS > =A0 =A0* Case insensitivity support > =A0 =A0* System attribute support > =A0 =A0* Integrated anti-virus support > > These features integrated into the following release: > > =A0 =A0* Solaris Express Community Edition, build 77 > > These features were integrated with the following bug fixes: > > =A0 =A0* 6617183 CIFS Service =A0PSARC 2006/715 > =A0 =A0* 6546893 Solaris system attribute support > =A0 =A0* 6417428 Case-insensitive file system name lookup to support > =A0 =A0CIFS > =A0 =A0* 6417435 DOS attributes and additional timestamps to support > =A0 =A0for CIFS > =A0 =A0* 6417442 File system quarantined and modified attributes to > =A0 =A0support an integrated Anti-Virus service > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS File System Version 2 > > This version includes support for the following features: > > =A0 =A0* Enhanced directory entries. In particular, directory entries > =A0 =A0now store the object type, (for example, file, directory, named > =A0 =A0pipe, and so on) in addition to the object number. > > =A0 =A0* Upgrading ZFS file systems to provide future ZFS file system > =A0 =A0enhancements to existing file systems. > > These features were integrated with the following bug fixes: > > =A0 =A0* 6572637 store object type in directory entries > =A0 =A0* PSARC/2007/328 zfs upgrade > > These features are available in: > > =A0 =A0* Solaris Express Community Edition, build 69 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > File System Version 1 > > This page describes the features that are available with version 1 > of the ZFS file system on-disk format (not the pool version). Because > this is the initial ZFS on-disk format that integrated on 10/31/05, > see the list of initial features in the ZFS Admin Guide. The first > official releases supporting this version are: > > =A0 =A0* Solaris Express Community Edition, build 36 > =A0 =A0* Solaris 10 6/06 release > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 24 > > This version includes support for system attributes. > > Pool version 24 is available in this release: > > =A0 =A0* Nevada, build 137 > > The change records for the version 24 change are: > > =A0 =A0* 6716117 =A0ZFS needs native system attribute infrastructure > =A0 =A0* 6516171 =A0zpl symlinks should have their own object type > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 23 > > This version includes support for the slim ZIL. > > Pool version 23 is available in this release: > > =A0 =A0* OpenSolaris, build 135 > > The change record for the version 23 change is: > > =A0 =A0* 6595532 ZIL is too talkative > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 22 > > This version includes support for zfs receive properties. > > Pool version 22 is available in this release: > > =A0 =A0* Solaris Express Community Edition, build 128 > > The PSARC case for the version 22 change is: > > =A0 =A0* PSARC/2009/510 ZFS Received Properties > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 21 > > This version includes support for ZFS deduplication properties. > > Pool version 21 is available in this release: > > =A0 =A0* Solaris Express Community Edition, build 128 > > The PSARC case for the version 21 change is: > > =A0 =A0* PSARC/2009/571 ZFS Deduplication Properties > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 20 > > This version includes the zle compression algorithm that is needed > to support the ZFS deduplication properties in ZFS pool version 21. > Both pool versions are available in this release: > > =A0 =A0* Solaris Express Community Edition, build 128 > > The PSARC case for the version 20 change is: > > =A0 =A0* PSARC/2009/571 ZFS Deduplication Properties > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 19 > > This version includes support for the following feature: > > =A0 =A0* ZFS log device removal > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 125 > > The related change record for the version 19 change is: > > =A0 =A0* 6574286 removing a slog doesn't work > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 18 > > This version includes support for the following feature: > > =A0 =A0* ZFS snapshot holds > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 121 > > The related change record for the version 18 change is: > > =A0 =A0* 6803121 want user-settable refcounts on snapshots > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 17 > > This version includes support for the following feature: > > =A0 =A0* triple-parity RAID-Z > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 120 > > The related change record for the version 17 change is: > > =A0 =A0* 6854612 triple-parity RAID-Z > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 16 > > This version includes support for the following feature: > > =A0 =A0* stmf property support > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 116 > > The related bug for the version 16 change is: > > =A0 =A0* 6736004 zvols need an additional property for comstar support > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 15 > > This version includes support for the following features: > > =A0 =A0* userused@... and groupused@... properties > =A0 =A0* userquota@... and groupquota@... properties > > These features are available in: > > =A0 =A0* Solaris Express Community Edition, build 114 > > The related bug and PSARC case for version 15 changes are: > > =A0 =A0* 6501037 want user/group quotas on ZFS > =A0 =A0* PSARC 2009/204 ZFS user/group quotas & space accounting > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 14 > > This version includes support for the following feature: > > =A0 =A0* passthrough-x aclinherit property support > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 103 > > The related bug and PSARC case for the version 14 change are: > > =A0 =A0* 6765166 Need to provide mechanism to optionally inherit > =A0 =A0ACE_EXECUTE > =A0 =A0* PSARC 2008/659 New ZFS "passthrough-x" ACL inheritance rules > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 13 > > This version includes support for the following features: > > =A0 =A0* usedbysnapshots property > =A0 =A0* usedbychildren property > =A0 =A0* usedbyrefreservation property > =A0 =A0* usedbydataset property > > These features are available in: > > =A0 =A0* Solaris Express Community Edition, build 98 > > The related bug and PSARC case for version 13 change is: > > =A0 =A0* 6730799 want snapused property > =A0 =A0* PSARC 2008/518 ZFS space accounting enhancements > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 12 > > This version includes support for the following feature: > > =A0 =A0* Properties for Snapshots > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 96 > > The related bug for the version 12 change is: > > =A0 =A0* 6701797 want user properties on snapshots > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 11 > > This version includes support for the following feature: > > =A0 =A0* Improved zpool scrub / resilver performance > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 94 > > The related bug for the version 11 change is: > > =A0 =A0* 6343667 scrub/resilver has to start over when a snapshot is > =A0 =A0taken > =A0 =A0* (Note, this bug is fixed when using build 94 even with older > =A0 =A0pool versions. However, upgrading the pool can improve scrub > =A0 =A0performance when there are many filesystems, snapshots, and > =A0 =A0clones.) > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 10 > > This version includes support for the following feature: > > =A0 =A0* Devices can be added to a storage pool as "cache devices." > =A0 =A0These devices provide an additional layer of caching between > =A0 =A0main memory and disk. Using cache devices provides the greatest > =A0 =A0performance improvement for random read-workloads of mostly > =A0 =A0static content. > > This feature is available in the Solaris Express Community Edition, > build 78. > > The Solaris 10 10/08 release includes ZFS pool version 10, but > support for cache devices is not included in this Solaris release. > > The related bug for the version 10 change is: > > =A0 =A0* 6536054 second tier ("external") ARC > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 9 > > This version includes support for the following features: > > =A0 =A0* In addition to the existing ZFS quota and reservation features, > =A0 =A0this release includes dataset quotas and reservations that do > =A0 =A0not include descendent datasets, such as snapshots and clones, > =A0 =A0in the space consumption. ("zfs set refquota" and "zfs set > =A0 =A0refreservation".) > > =A0 =A0* A reservation is automatically set when a non-sparse ZFS > =A0 =A0volume is created that matches the size of the volume. This > =A0 =A0release provides an immediate reservation feature so that you > =A0 =A0set a reservation on a non-sparse volume with enough space to > =A0 =A0take snapshots and modify the contents of the volume. > > =A0 =A0* CIFS server support > > These features are available in Solaris Express Community Edition, > build 77. > > The related bugs for version 9 changes are: > > =A0 =A0* 6431277 want filesystem-only quotas > =A0 =A0* 6483677 need immediate reservation > =A0 =A0* 6617183 CIFS Service =A0PSARC 2006/715 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 8 > > This version now supports the ability to delegate zfs(1M) administrative > tasks to ordinary users. > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 69 > =A0 =A0* Solaris 10 10/08 release > > The related bug for the version 8 change is: > > =A0 =A0* 6349470 investigate non-root restore/backup > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 7 > > This version includes support for the following feature: > > The ZFS Intent Log (ZIL) satisfies the need of some applications > to know the data they changed is on stable storage on return from > a system call. The Intent Log holds records of those system calls > and they are replayed if the system power fails or panics if they > have not been committed to the main pool. When the Intent Log is > allocated from the main pool, it allocates blocks that chain through > the pool. This version adds the capability to specify a separate > Intent Log device or devices. > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 68 > =A0 =A0* Solaris 10 10/08 release > > The related bug for the version 7 change is: > > =A0 =A0* 6339640 Make ZIL use NVRAM when available. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 6 > > This version includes support for the following feature: > > =A0 =A0* 'bootfs' pool property > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 62 > =A0 =A0* Solaris 10 10/08 release > > The related bugs for version 6 changes are as follows: > > =A0 =A0* 4929890 ZFS Boot support for the x86 platform > =A0 =A0* 6479807 pools need properties > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 5 > > This version includes support for the following feature: > > =A0 =A0* gzip compression for ZFS datasets > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 62 > =A0 =A0* Solaris 10 10/08 release > > The related bug for the version 5 changes is: > > =A0 =A0* 6536606 gzip compression for ZFS > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 4 > > This version includes support for the following feature: > > =A0 =A0* zpool history > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 62 > =A0 =A0* Solaris 10 8/07 release > > The related bugs for version 4 changes are as follows: > > =A0 =A0* 6529406 zpool history needs to bump the on-disk version > =A0 =A0* 6343741 want to store a command history on disk > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 3 > > This version includes support for the following features: > > =A0 =A0* Hot spares > =A0 =A0* Double-parity RAID-Z (raidz2) > =A0 =A0* Improved RAID-Z accounting > > These features are available in: > > =A0 =A0* Solaris Express Community Edition, build 42 > =A0 =A0* Solaris 10 11/06 release, (build 3) > > The related bugs for version 3 changes are as follows: > > =A0 =A0* 6405966 Hot Spare support in ZFS > =A0 =A0* 6417978 double parity RAID-Z a.k.a. RAID6 > =A0 =A0* 6288488 du reports misleading size on RAID-Z > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 2 > > This version includes support for "Ditto Blocks", or replicated > metadata. Due to the tree-like structure of the ZFS on-disk format, > an uncorrectable error in a leaf block may be relatively benign, > while an uncorrectable error in pool metadata can result in an > unopenable pool. This feature introduces automatic replication of > metadata (up to 3 copies of each block) independent of any underlying > pool-wide redundancy. For example, on a pool with a single mirror, > the most critical metadata will appear three times on each side of > the mirror, for a total of six copies. This ensures that while user > data may be lost due to corruption, all data in the pool will be > discoverable and the pool will still be usable. This will be expanded > in the future to allow user data replication on a per-dataset basis. > > This feature was integrated on 4/10/06 with the following bug fix: > > 6410698 ZFS metadata needs to be more highly replicated (ditto blocks) > > This feature is available in: > > =A0 =A0* Solaris Express Community Edition, build 38 > =A0 =A0* Solaris 10 10/06 release (build 09) > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ZFS Pool Version 1 > > This is the initial ZFS on-disk format as integrated on 10/31/05. > During the next six months of internal use, there were a few on-disk > format changes that did not result in a version number change, but > resulted in a flag day since earlier versions could not read the > newer changes. The first official releases supporting this version > are: > > =A0 =A0* Solaris Express Community Edition, build 36 > =A0 =A0* Solaris 10 6/06 release > > Earlier releases may not support this version, despite being formatted > with the same on-disk number. This is due to: > > 6389368 fat zap should use 16k blocks (with backwards compatability) > 6390677 version number checking makes upgrades challenging > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Tue Jul 13 17:05:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC3061065674 for ; Tue, 13 Jul 2010 17:05:14 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id AAD888FC0C for ; Tue, 13 Jul 2010 17:05:14 +0000 (UTC) Received: by pvh1 with SMTP id 1so2595194pvh.13 for ; Tue, 13 Jul 2010 10:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bw92sl/AlFqy6PbhhdzIWe4sBEZaMXgWexI18n3Ua6M=; b=HVTY8T/7++LEFeKY34U5U9++SMg+2d0Mn6vIJo81bGGW14b3O68d62vDc3Z3zW0+os DGVdcHglPCzkcbgQijIOUWnCQUuM0v1Oov9Uttf43B0h+K98wfSdjuU6tLFcu/WFjHHS x90Ao2g28JjxduhMuFy8Vt74g1Rl9WJ+/iFsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=vww7hTazgJZALZg/Rh607zo7Fy6mybNrtyNA6LrtGaiBbNDGji9FQJEWIbcNLeqx+d SFHzu1y0KFkbsONutE0rpjLd7l6xItC5jgt6T/yFJupAHNNL57Onnhx/H9FSm6eQFdZV T2M0jX3O0JnwN4xBLjIWgF9bbg0NI00PgxvlQ= Received: by 10.114.112.6 with SMTP id k6mr18597768wac.173.1279040713769; Tue, 13 Jul 2010 10:05:13 -0700 (PDT) Received: from beastie.micom.mng.net ([202.179.21.129]) by mx.google.com with ESMTPS id q6sm89095385waj.22.2010.07.13.10.05.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Jul 2010 10:05:08 -0700 (PDT) Message-ID: <4C3C9CBB.7060103@gmail.com> Date: Wed, 14 Jul 2010 01:04:59 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.23 (X11/20091011) MIME-Version: 1.0 To: PseudoCylon References: <597509.54869.qm@web51805.mail.re2.yahoo.com> In-Reply-To: <597509.54869.qm@web51805.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ganbold Tsagaankhuu , freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2010 17:05:14 -0000 PseudoCylon wrote: > ----- Original Message ---- > >> From: PseudoCylon >> To: Ganbold Tsagaankhuu >> Cc: Ganbold ; freebsd-current@freebsd.org >> Sent: Tue, July 6, 2010 12:26:58 AM >> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >> >> >>>>>>>> From: Ganbold >>>>>>>> To: PseudoCylon >>>>>>>> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu >>>>>>>> >> >> >>>>>>>> Sent: Wed, June 16, 2010 6:33:47 AM >>>>>>>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >>>>>>>> >>>>>>>> AK-san, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> PseudoCylon wrote: >>>>>>> >>>>>>> Strange, looks like this time works as expected, but sometimes it >>>>>>> doesn't work. >>>>>>> >>>>>>> In some cases it doesn't work and you can find complete tcpdump output >>>>>>> from very beginning to the modem hang: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hello, >>>>>> >>>>>> Are following true? >>>>>> When manually load/reload hostapd, works >>>>>> When loaded by rc.conf, doesn't work >>>>>> >>>>>> If so, please try attached patch. (patch to if_run.c only) Or, here is a >>>>>> >> patched file. >> >>>>>> http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c >>>>>> >>>>>> When auto-loading, the driver is brought up and down a few times. It >>>>>> >> might be the cause. >> >>>>>> >>>>>> >>>>> I will test it few more days and let you know. >>>>> >>>>> thanks, >>>>> >>>>> Ganbold >>>>> >>>>> >>>> Hello, >>>> >>>> How is the patch doing on your rspro? Is it working well? >>>> >>>> >>> Sorry for late response. Due to business trip I tested couple of times >>> only and it seems working relatively ok. 1-2 times ADSL modem hang, but >>> seemed like after 3-4 hours. >>> Tried couple of times again, but I couldn't reproduce it. I will try to >>> reproduce it and let you know the results. >>> >>> thanks a lot, >>> >>> Ganbold >>> > Hello, Ganbold > > Is the latest patch working? > AK-san, Only tested once, the patch works ok so far. thanks, Ganbold > > AK > > >> Hello, >> >> I say every one has a job. >> >> At least it's start up OK, right? >> >> Can you try attached patch? (patch to if_run.c you currently using) Or, here >> is a patched file >> http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c >> >> I encountered similar problem about 5 days ago. It kind of hard to reproduce. >> A couple of things have to happen at the right (or wrong) time. >> >> If the modem still hangs at the start up, please let me know. That means the >> last patch isn't working. >> >> AK >> >> -- begin patch -- >> >> diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c >> index f302246..e5a2a4d 100644 >> --- a/dev/usb/wlan/if_run.c >> +++ b/dev/usb/wlan/if_run.c >> @@ -888,8 +888,7 @@ run_cmdq_cb(void *arg, int pending) >> >> /* call cmdq[].func locked */ >> RUN_LOCK(sc); >> -for(i = sc->cmdq_exec; sc->cmdq[i].func && pending; >> - i = sc->cmdq_exec, pending--){ >> +for(i = sc->cmdq_exec; sc->cmdq[i].func; i = sc->cmdq_exec){ >> DPRINTFN(6, "cmdq_exec=%d pending=%d\n", i, pending); >> if(sc->cmdq_run == RUN_CMDQ_GO || >> (sc->cmdq_key_set == RUN_CMDQ_GO && >> >> -- end patch -- >> >> >> >> >> > > > > -- My interest is in the future because I am going to spend the rest of my life there. From owner-freebsd-current@FreeBSD.ORG Tue Jul 13 17:28:53 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE6E6106567C; Tue, 13 Jul 2010 17:28:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9897A8FC12; Tue, 13 Jul 2010 17:28:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o6DHSqq5044044; Tue, 13 Jul 2010 13:28:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o6DHSqXh044038; Tue, 13 Jul 2010 17:28:52 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 13 Jul 2010 17:28:52 GMT Message-Id: <201007131728.o6DHSqXh044038@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:28:53 -0000 TB --- 2010-07-13 15:53:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-13 15:53:12 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-07-13 15:53:12 - cleaning the object tree TB --- 2010-07-13 15:53:34 - cvsupping the source tree TB --- 2010-07-13 15:53:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-07-13 15:53:50 - building world TB --- 2010-07-13 15:53:50 - MAKEOBJDIRPREFIX=/obj TB --- 2010-07-13 15:53:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-07-13 15:53:50 - TARGET=powerpc TB --- 2010-07-13 15:53:50 - TARGET_ARCH=powerpc TB --- 2010-07-13 15:53:50 - TZ=UTC TB --- 2010-07-13 15:53:50 - __MAKE_CONF=/dev/null TB --- 2010-07-13 15:53:50 - cd /src TB --- 2010-07-13 15:53:50 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 13 15:53:50 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 13 17:25:04 UTC 2010 TB --- 2010-07-13 17:25:04 - generating LINT kernel config TB --- 2010-07-13 17:25:04 - cd /src/sys/powerpc/conf TB --- 2010-07-13 17:25:04 - /usr/bin/make -B LINT TB --- 2010-07-13 17:25:04 - building LINT kernel TB --- 2010-07-13 17:25:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-07-13 17:25:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-07-13 17:25:04 - TARGET=powerpc TB --- 2010-07-13 17:25:04 - TARGET_ARCH=powerpc TB --- 2010-07-13 17:25:04 - TZ=UTC TB --- 2010-07-13 17:25:04 - __MAKE_CONF=/dev/null TB --- 2010-07-13 17:25:04 - cd /src TB --- 2010-07-13 17:25:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 13 17:25:04 UTC 2010 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/bktr/bktr_audio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/bktr/bktr_card.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/bktr/bktr_core.c cc1: warnings being treated as errors /src/sys/dev/bktr/bktr_core.c: In function 'common_bktr_attach': /src/sys/dev/bktr/bktr_core.c:542: warning: format '%d' expects type 'int', but argument 3 has type 'long int' /src/sys/dev/bktr/bktr_core.c: In function 'video_ioctl': /src/sys/dev/bktr/bktr_core.c:1813: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int' *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-07-13 17:28:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-07-13 17:28:52 - ERROR: failed to build lint kernel TB --- 2010-07-13 17:28:52 - 4655.23 user 813.51 system 5740.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 13 23:28:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBA461065674 for ; Tue, 13 Jul 2010 23:28:27 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by mx1.freebsd.org (Postfix) with ESMTP id 831918FC19 for ; Tue, 13 Jul 2010 23:28:27 +0000 (UTC) Received: from nskntotgx03p.mx.bigpond.com ([124.188.161.100]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20100713232825.BUMC1693.nskntmtas02p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com> for ; Tue, 13 Jul 2010 23:28:25 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20100713232824.ZCFJ13584.nskntotgx03p.mx.bigpond.com@duncan.reilly.home> for ; Tue, 13 Jul 2010 23:28:24 +0000 Date: Wed, 14 Jul 2010 09:28:24 +1000 From: Andrew Reilly To: freebsd-current@freebsd.org Message-ID: <20100713232824.GA10152@duncan.reilly.home> References: <20100713085025.GA1836@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100713085025.GA1836@duncan.reilly.home> User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nskntotgx03p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Tue, 13 Jul 2010 23:28:24 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090205.4C3CF699.0090,ss=1,fgs=0 X-SIH-MSG-ID: qBw1E9L8TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rHNvZRu8u6xD9PJhiGNGMoaa7hTY3Rs9mK Subject: Re: Samba wedged: what does it mean? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2010 23:28:28 -0000 Hi all, Just another note: the system logs this morning had a couple of LOR reports that I haven't seen before: +lock order reversal: + 1st 0xffffff00027e5400 if_addr_mtx (if_addr_mtx) @ /nb/src/sys/netinet/igmp.c:1710 + 2nd 0xffffffff80e5bdc0 ifnet_rw (ifnet_rw) @ /nb/src/sys/net/if.c:225 + 1st 0xffffff00027e5400 if_addr_mtx (if_addr_mtx) @ /nb/src/sys/netinet/igmp.c:1710 + 2nd 0xffffff000283faf8 radix node head (radix node head) @ /nb/src/sys/net/route.c:362 + 1st 0xffffff00027e5400 if_addr_mtx (if_addr_mtx) @ /nb/src/sys/netinet/igmp.c:1710 + 2nd 0xffffff00027e53c0 if_afdata (if_afdata) @ /nb/src/sys/net/if_llatbl.c:129 + 1st 0xffffff00027e5400 if_addr_mtx (if_addr_mtx) @ /nb/src/sys/netinet/igmp.c:1710 + 2nd 0xffffff80002f6020 nfe0 (network driver) @ /nb/src/sys/dev/nfe/if_nfe.c:2549 Not sure if those are relevant or not. Also, it seems that for whole time of the samba blockage I wasn't receiving any mail (via fetchmail --> local qmail smtp server), but had no trouble connecting to the system over ssh, or doing most other things. On Tue, Jul 13, 2010 at 06:50:25PM +1000, Andrew Reilly wrote: > This is on: > FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Fri Jul 9 21:05:44 EST 2010 root@duncan.reilly.home:/nb/obj/nb/src/sys/DUNCAN amd64 > Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 00:14:28 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA6EF1065673; Wed, 14 Jul 2010 00:14:28 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 786488FC19; Wed, 14 Jul 2010 00:14:28 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c211-30-160-13.belrs4.nsw.optusnet.com.au [211.30.160.13]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6E0EPGw032150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jul 2010 10:14:26 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o6E0ENXt092741; Wed, 14 Jul 2010 10:14:23 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o6E0EN4L092740; Wed, 14 Jul 2010 10:14:23 +1000 (EST) (envelope-from peter) Date: Wed, 14 Jul 2010 10:14:23 +1000 From: Peter Jeremy To: Martin Matuska Message-ID: <20100714001423.GA92530@server.vk2pj.dyndns.org> References: <4C31C71C.2010606@FreeBSD.org> <20100708200446.GA33822@server.vk2pj.dyndns.org> <4C364379.6020608@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <4C364379.6020608@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 00:14:29 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jul-08 23:30:33 +0200, Martin Matuska wrote: >On 8. 7. 2010 22:04, Peter Jeremy wrote / nap=EDsal(a): >> Without patching arc_memory_throttle(), a system behaves especially >> poorly if it uses ZFS with any of mmap(2), UFS or NFS client - in my >> case, ports/mail/mairix was almost guaranteed to wedge the system. >> This is the problem that the following hack is intended to work around: >> perl -e '$x =3D "x" x 1000000;' >> >> =20 >Regarding ARC, you might want to try the revision 209227 from head that >is scheduled for MFC on 18.7.2010: >http://people.freebsd.org/~mm/patches/zfs/head-12636.patch I have done some testing with 8-STABLE with head-12636.patch and have managed to successfully reproduce a deadlock. The system is amd64 with 2GB RAM running a mixed UFS+ZFS environment. On a freshly booted system, I unmount/remount my ZFS /home and a UFS scratch filesystem that contains a 1.5GB file [ensuring there is no cached data from either FS]. I then dd(1) the 1.5GB UFS file to /dev/null and, once that is finished, start mairix on my ~6GB mail directory (on ZFS /home). After some time, I get the following 'systat -v' output: 4 users Load 9.30 8.97 8.33 Jul 14 09:49 Mem:KB REAL VIRTUAL VN PAGER SWAP PAG= ER Tot Share Tot Share Free in out in o= ut Act 122308 4436 721892 7876 59824 count =20 All 418376 7020 1074594k 38920 pages =20 Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt cow 4031 total 4 76 133k 3 194 30 135 zfod ata0 = irq14 ozfod 30 bge0 = irq16 99.8%Sys 0.2%Intr 0.0%User 0.0%Nice 0.0%Idle %ozfod atapc= i1 20 | | | | | | | | | | | daefr uhci0= ehci =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= prcfr uhci1 22 dtbuf totfr 2000 cpu0:= time Namei Name-cache Dir-cache 100000 desvn react 2001 cpu1:= time Calls hits % hits % 918 numvn pdwak 273 frevn pdpgs intrn Disks ad0 ad1 540404 wire KB/t 0.00 0.00 297512 act tps 0 0 1122808 inact MB/s 0.00 0.00 57876 cache %busy 0 0 1948 free 218192 buf Apart from normal daemons, the only processes running are vmstat, systat and mairix (via SSH sessions). Note that the system is running at virtually 100%sys with extremely low free memory and extremely high context switches but no obviously useful activity. At this stage, the system is basically unusable (I can't even kill the mairix process). My understanding of the problem is that the VM system sees "available" RAM as the sum of "cache" and "free" - which is reasonably high so there is no pressure to free up "inact" RAM. OTOH, ZFS ARC only counts "free" RAM - which is critically low so it throttles itself but has no way to get the VM system to move RAM onto the "free" list. --=20 Peter Jeremy --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw9AV8ACgkQ/opHv/APuIeJGQCfeXn7XQ7VGWkcZ53X8rxqEr+g GLsAoMTUTWy8T2j7nKxmk6zf6hCQ4NL4 =NhxZ -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 00:45:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A61D2106566C for ; Wed, 14 Jul 2010 00:45:25 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 636D18FC20 for ; Wed, 14 Jul 2010 00:45:25 +0000 (UTC) Received: by iwn35 with SMTP id 35so7952680iwn.13 for ; Tue, 13 Jul 2010 17:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=sDgnf0bbwrPJEJgNj/Str5A7KUwxq9zCI0OLVKzM9/8=; b=bRhcO6gDPapYhkuQfn0eIPpaH4/0cCCf95Z5FfgOUy9/OtZn7nkwZsXNBvFHlvDZR6 JXFq3ImYKZDetM0xbSCof9zCa1+0pfJQfM97vJXeVSJvBZfcBS+lUKW0UsAZjvCxKZ6V GP21HE25VxNYrhVmxix91D/ZGwcwG71wgidWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=VFloQehJEJ0wmYdbB33bELraHMtNA5S9t1zRb0eJlRH1CAWsAMj/5UTDIy4iaiPyux gobpJ8vZla8R+GOi4vVpKKe9r+bR9EJbpWn58JrJZui0NHhdopOSoRfwdU8QXZFDjq8M Usm81m4XgsIVkTlF1Kjuya9yPONx8uR/U9Jr8= Received: by 10.231.182.204 with SMTP id cd12mr4793738ibb.101.1279068324894; Tue, 13 Jul 2010 17:45:24 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id e8sm27494597ibb.14.2010.07.13.17.45.22 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Jul 2010 17:45:23 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C3D08A5.2090109@dataix.net> Date: Tue, 13 Jul 2010 20:45:25 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: "Jason J. W. Williams" References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, grarpamp Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 00:45:25 -0000 On 07/13/2010 12:30, Jason J. W. Williams wrote: > If there's any way to backport ZFS log device removal that would be > very helpful. That's the primary hold up for ops folks moving our > OpenSolaris servers to FreeBSD. I second this. In explanation I have one machine that needs to be rearranged for a upgrade/update for a different purpose than what it is currently doing that is holding up some of the other tasks that are planned. I already made the mistake once in a test situation by removing a log device that was da0 during a reboot & popped in another device, something happened, rebooted the machine, plugged in original and the situation was irreparable causing the pool to be corrupt. Needless to say it was only a test environment but this has stopped me cold from using further log devices because of this. ;( This is not really top priority right now but would be a great Christmas present ;) If someone points me in the right direction I guess I could always start reviewing the changes for inclusion on a patch against head & stable/8. Regards, Thanks & Good Luck, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 02:40:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66EC7106566C; Wed, 14 Jul 2010 02:40:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F2758FC14; Wed, 14 Jul 2010 02:40:44 +0000 (UTC) Received: by iwn35 with SMTP id 35so8069239iwn.13 for ; Tue, 13 Jul 2010 19:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Gw6g22hkdqzNefRELoNMPursY3ZAwnyWnN0FNmriDgE=; b=xUC+P2004lryqDCVWquGn/bsKyOeSIQvASeU6fmuYg1/fJFGpnnWn4icyBZt6tK19z /EmmukGki3QYwX2lsVEh78ALMrnkvWA85kP8Mh4sp21x/uantNBebXVaTKlYRWzPiUtr s+rsoNooS2UDDNEvtIjBI+YetsHKPKR40CM4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=RI459jsvBzgTuvLPpQk+b5KWn1xG3G3bCZOdYN1np1OH+7UnDoumht0GUwi2TVrc5x 6gtg2oK3S4+dBA6EzjlzVEPAFcwJUuVjMqQsan/UpPcAhloCcgYfAT4qOuvnVH0LFt06 UpwB55LidPGwCIxMgW2Y3Cjxw4d1twMgNJ8IY= MIME-Version: 1.0 Received: by 10.231.85.206 with SMTP id p14mr14577910ibl.89.1279075244229; Tue, 13 Jul 2010 19:40:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.152.79 with HTTP; Tue, 13 Jul 2010 19:40:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Jul 2010 10:40:44 +0800 X-Google-Sender-Auth: CASV7cdSPd3wWGwOCDrCGyMdZsw Message-ID: From: Adrian Chadd To: syrinx@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@FreeBSD.org" , freebsd-current@freebsd.org Subject: Re: Call for testers: wireless module for bsnmpd(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 02:40:45 -0000 Howdy! Compiling this on MIPS gives this error: Warning: Object directory not changed from original /usr/home/adrian/w/snmp_wlan cc -fpic -DPIC -O -pipe -EB -msoft-float -G0 -mno-dsp -mabicalls -DSNMPTREE_TYPES -g -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c wlan_sys.c -o wlan_sys.So cc1: warnings being treated as errors wlan_sys.c: In function 'wlan_get_scan_results': wlan_sys.c:2221: warning: cast increases required alignment of target type wlan_sys.c: In function 'wlan_get_peerinfo': wlan_sys.c:2713: warning: cast increases required alignment of target type *** Error code 1 Adrian On 10 July 2010 19:27, Shteryana Shopova wrote: > Hi all, > > As some of you may know, I've been awarded a grant by the FreeBSD > Foundation to make several improvements to FreeBSD's SNMP daemon. The > first part of the project - a module for monitoring wireless > networking under FreeBSD - is now completed and I'd really appreciate > if I could get some help in more extensive testing in a wider range of > wireless networking usage scenarios. A tarbal of the latest sources of > the module is available under > http://people.freebsd.org/~syrinx/snmp/snmp_wlan-20100710-01.tar. To > compile and install the module - > #fetch http://people.freebsd.org/~syrinx/snmp/snmp_wlan-20100710-01.tar > #tar -xvf snmp_wlan-20100710-01.tar > #cd snmp_wlan > #make > #make install (as root) > > To enable loading of the module in bsnmpd(1), one should add the > following line to bsnmpd(1) config file (usually /etc/snmpd.config) - > > begemotSnmpdModulePath."wlan" = "/usr/lib/snmp_wlan.so" > > More details on how the module works may be found in the snmp_wlan(3) > man page and in the private BEGEMOT-WIRELESS-MIB the module implements > (installed under /usr/share/snmp/mibs/BEGEMOT-WIRELESS-MIB.txt). > Know issues currently are that BITS types are not always handled > properly, and TX rates may not always be properly set - I am working > on fixing those. > All feedback is wellcome - bug reports, requests for features to be > included in future versions of the module, code style and bug fix > patches. I will be glad to help resolve any problems that may arise > while installing/working with the module and answer any questions you > may have. Thanks! > > cheers, > Shteryana > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 03:16:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E28EB1065675; Wed, 14 Jul 2010 03:16:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8C20E8FC17; Wed, 14 Jul 2010 03:16:52 +0000 (UTC) Received: by iwn35 with SMTP id 35so8104880iwn.13 for ; Tue, 13 Jul 2010 20:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=SqO+rFe5kFaar2D1a13FR0KUwGC4KMdftndQDlqtPgg=; b=wZv6Dl14sovwaBlBE3n/AK8hU+KXPlfm9W6lodIZVunqCb57xXnnZ8fdqOds5pmtbC eCTljy+uipOnAp7p/d6dWe1YaQGNIFhTnw7fZ/5Gab3dkImbiH5i3Ky2geOVcdRhYWMt OXGJf6tpCo2HzvHHCeSMOjxRi1q2RU+aQ93lY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=apSq1EQw6a50iNO0zttj3vjD4+iG2eqXKHQvR3UF99wRFKeawfdnvUI74nUUiohwgB NZ8urAAlTCXdpU5Q87bvfqcRovIezyGFfm6LP3LyAOeBoudZMVFVWemt/jyiSUxdtu35 4AvuaiI1e+kK7S2usr5hwv3nC9CIUCopl4HSs= MIME-Version: 1.0 Received: by 10.231.139.212 with SMTP id f20mr15515445ibu.166.1279077411764; Tue, 13 Jul 2010 20:16:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.152.79 with HTTP; Tue, 13 Jul 2010 20:16:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Jul 2010 11:16:50 +0800 X-Google-Sender-Auth: JELEGVVxpImsfBrQBE_78K1vWlI Message-ID: From: Adrian Chadd To: syrinx@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@FreeBSD.org" , freebsd-current@freebsd.org Subject: Re: Call for testers: wireless module for bsnmpd(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 03:16:53 -0000 On 10 July 2010 19:27, Shteryana Shopova wrote: > Hi all, > > As some of you may know, I've been awarded a grant by the FreeBSD > Foundation to make several improvements to FreeBSD's SNMP daemon. The > first part of the project - a module for monitoring wireless > networking under FreeBSD - is now completed and I'd really appreciate > if I could get some help in more extensive testing in a wider range of > wireless networking usage scenarios. A tarbal of the latest sources of > the module is available under I've already emailed you about the alignment warnings. The returned error value is an SNMPv2 error (SNMP_ERR_INCONS_VALUE) which causes v1 requests to error out. Is it at all possible to return something valid if a v1 request is made? snmpwalk'ing to inspect what -is- returned fails, even when querying in v2 mode: BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nRIFS."wlan0" = INTEGER: false(2) BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nShortGI."wlan0" = INTEGER: false(2) BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nSMPSMode."wlan0" = INTEGER: disabled(1) Error in packet. Reason: (genError) A general failure occured Failed object: BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nSMPSMode."wlan0" The daemon logs errors when features aren't supported by the underlying driver (eg querying TDMA stats on a non-TDMA interface.) This may hide any actual underlying issues. It isn't immediately clear which parameters are related to station and which are related to hostap. Eg, wlanIfaceBeaconMissedThreshold. Is that the station threshold or the AP threshold? Would it be worthwhile creating separate branches for different stat types (station, ap, TDMA AP, dot11n stuff, etc, etc?) rather than whacking it all together in one tree? I've not seen binary string indexing values on tables before. Eg: BEGEMOT-WIRELESS-MIB::wlanIfacePeerAddress."wlan0".'...$..'.61 = STRING: 0:11:24:c7:e4:3d BEGEMOT-WIRELESS-MIB::wlanIfacePeerAddress."wlan0".'..#2'.'.219 = STRING: 0:23:32:27:fc:db BEGEMOT-WIRELESS-MIB::wlanIfacePeerAssociationId."wlan0".'...$..'.61 = INTEGER: 2 BEGEMOT-WIRELESS-MIB::wlanIfacePeerAssociationId."wlan0".'..#2'.'.219 = INTEGER: 1 Is that going to be portable to different utilities? Some of the code I've seen (and written!) expect numeric table indexes rather than what I see above. Adrian From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 07:16:14 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 211851065686 for ; Wed, 14 Jul 2010 07:16:14 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [188.40.32.143]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3DA8FC1F for ; Wed, 14 Jul 2010 07:16:13 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 3CA6C100E14; Wed, 14 Jul 2010 09:16:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bozMtF63z+Qs; Wed, 14 Jul 2010 09:16:09 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 58B37100E0D; Wed, 14 Jul 2010 09:16:09 +0200 (CEST) Message-ID: <4C3D6439.3010702@FreeBSD.org> Date: Wed, 14 Jul 2010 09:16:09 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Peter Jeremy References: <4C31C71C.2010606@FreeBSD.org> <20100708200446.GA33822@server.vk2pj.dyndns.org> <4C364379.6020608@FreeBSD.org> <20100714001423.GA92530@server.vk2pj.dyndns.org> In-Reply-To: <20100714001423.GA92530@server.vk2pj.dyndns.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 07:16:14 -0000 Without head-12636.patch you are unable to reproduce the deadlock? Dòa 14. 7. 2010 2:14, Peter Jeremy wrote / napísal(a): > On 2010-Jul-08 23:30:33 +0200, Martin Matuska wrote: >> On 8. 7. 2010 22:04, Peter Jeremy wrote / napísal(a): >>> Without patching arc_memory_throttle(), a system behaves especially >>> poorly if it uses ZFS with any of mmap(2), UFS or NFS client - in my >>> case, ports/mail/mairix was almost guaranteed to wedge the system. >>> This is the problem that the following hack is intended to work around: >>> perl -e '$x = "x" x 1000000;' >>> >>> >> Regarding ARC, you might want to try the revision 209227 from head that >> is scheduled for MFC on 18.7.2010: >> http://people.freebsd.org/~mm/patches/zfs/head-12636.patch > I have done some testing with 8-STABLE with head-12636.patch and have > managed to successfully reproduce a deadlock. The system is amd64 > with 2GB RAM running a mixed UFS+ZFS environment. On a freshly booted > system, I unmount/remount my ZFS /home and a UFS scratch filesystem > that contains a 1.5GB file [ensuring there is no cached data from > either FS]. I then dd(1) the 1.5GB UFS file to /dev/null and, once > that is finished, start mairix on my ~6GB mail directory (on ZFS > /home). After some time, I get the following 'systat -v' output: > > 4 users Load 9.30 8.97 8.33 Jul 14 09:49 > > Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER > Tot Share Tot Share Free in out in out > Act 122308 4436 721892 7876 59824 count > All 418376 7020 1074594k 38920 pages > Proc: Interrupts > r p d s w Csw Trp Sys Int Sof Flt cow 4031 total > 4 76 133k 3 194 30 135 zfod ata0 irq14 > ozfod 30 bge0 irq16 > 99.8%Sys 0.2%Intr 0.0%User 0.0%Nice 0.0%Idle %ozfod atapci1 20 > | | | | | | | | | | | daefr uhci0 ehci > ================================================== prcfr uhci1 22 > dtbuf totfr 2000 cpu0: time > Namei Name-cache Dir-cache 100000 desvn react 2001 cpu1: time > Calls hits % hits % 918 numvn pdwak > 273 frevn pdpgs > intrn > Disks ad0 ad1 540404 wire > KB/t 0.00 0.00 297512 act > tps 0 0 1122808 inact > MB/s 0.00 0.00 57876 cache > %busy 0 0 1948 free > 218192 buf > > Apart from normal daemons, the only processes running are vmstat, > systat and mairix (via SSH sessions). Note that the system is running > at virtually 100%sys with extremely low free memory and extremely high > context switches but no obviously useful activity. At this stage, the > system is basically unusable (I can't even kill the mairix process). > > My understanding of the problem is that the VM system sees "available" > RAM as the sum of "cache" and "free" - which is reasonably high so > there is no pressure to free up "inact" RAM. OTOH, ZFS ARC only > counts "free" RAM - which is critically low so it throttles itself > but has no way to get the VM system to move RAM onto the "free" list. > From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 07:30:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71AB01065670 for ; Wed, 14 Jul 2010 07:30:26 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [188.40.32.143]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7F98FC28 for ; Wed, 14 Jul 2010 07:30:25 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 359EE100895; Wed, 14 Jul 2010 09:30:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AI+4s1dOk8S0; Wed, 14 Jul 2010 09:30:21 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 9F58510088C; Wed, 14 Jul 2010 09:30:21 +0200 (CEST) Message-ID: <4C3D678E.5040403@FreeBSD.org> Date: Wed, 14 Jul 2010 09:30:22 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: jhell References: <4C3D08A5.2090109@dataix.net> In-Reply-To: <4C3D08A5.2090109@dataix.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "Jason J. W. Williams" , freebsd-current@freebsd.org, grarpamp Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 07:30:26 -0000 What about the OpenSolaris revision 9701 for starters? Could that help your case? 9701:cc5b64682e64 6803605 should be able to offline log devices http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6803605 6726045 vdev_deflate_ratio is not set when offlining a log device http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6726045 Dňa 14. 7. 2010 2:45, jhell wrote / napísal(a): > On 07/13/2010 12:30, Jason J. W. Williams wrote: >> If there's any way to backport ZFS log device removal that would be >> very helpful. That's the primary hold up for ops folks moving our >> OpenSolaris servers to FreeBSD. > I second this. > > In explanation I have one machine that needs to be rearranged for a > upgrade/update for a different purpose than what it is currently doing > that is holding up some of the other tasks that are planned. I already > made the mistake once in a test situation by removing a log device that > was da0 during a reboot & popped in another device, something happened, > rebooted the machine, plugged in original and the situation was > irreparable causing the pool to be corrupt. > > Needless to say it was only a test environment but this has stopped me > cold from using further log devices because of this. ;( > > This is not really top priority right now but would be a great Christmas > present ;) > > If someone points me in the right direction I guess I could always start > reviewing the changes for inclusion on a patch against head & stable/8. > > > Regards, Thanks & Good Luck, > From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 08:22:30 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CCF310656DF; Wed, 14 Jul 2010 08:22:30 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 1E6E78FC08; Wed, 14 Jul 2010 08:22:28 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 4913948C9A; Wed, 14 Jul 2010 10:01:43 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.094846, version=1.2.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 4.4656] X-CRM114-CacheID: sfid-20100714_10013_B3D97A84 X-CRM114-Status: UNSURE (4.4656) This message is 'unsure'; please train it! X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Jul 14 10:01:42 2010 X-DSPAM-Confidence: 0.6432 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4c3d6ee6409831843215864 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00164, wrote, 0.00298, wrote+>, 0.00330, >+For, 0.01000, 1+and, 0.01000, patches, 0.01000, Subject*version, 0.99000, Content-Type*1250, 0.99000, Content-Type*charset=windows+1250, 0.99000, for+>, 0.01000, with+what, 0.99000, To*FreeBSD.org>, 0.01000, I've, 0.01194, gets, 0.02933, Subject*Re, 0.03072, 02, 0.03163, PM, 0.03191, versions, 0.03338, >, 0.05322, >, 0.05322, 8+1, 0.05698, 8+1, 0.05698, Martin, 0.07456, On, 0.07996, 8, 0.08614, 8, 0.08614, X-Spambayes-Classification: ham; 0.17 Message-ID: <4C3D6ECA.40200@fsn.hu> Date: Wed, 14 Jul 2010 10:01:14 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Martin Matuska References: <4C3C7202.7090103@FreeBSD.org> In-Reply-To: <4C3C7202.7090103@FreeBSD.org> Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: [HEADSUP] ZFS version 15 committed to head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 08:22:30 -0000 Hi, On 07/13/2010 04:02 PM, Martin Matuska wrote: > For people interested in running this on 8.1 I will provide patches for > releng/8.1 and stable/8 as soon as 8.1 gets released. Previously, I've run earlier versions (8) with sys/cddl taken from head. Is this a no-go with what we have currently in stable/8 and trunk? Thanks, From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 08:23:52 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A348A1065670; Wed, 14 Jul 2010 08:23:52 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id 324F98FC24; Wed, 14 Jul 2010 08:23:51 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c211-30-160-13.belrs4.nsw.optusnet.com.au [211.30.160.13]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6E8NnQC004511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jul 2010 18:23:50 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o6E8Nkiw095513; Wed, 14 Jul 2010 18:23:46 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o6E8NkIX095512; Wed, 14 Jul 2010 18:23:46 +1000 (EST) (envelope-from peter) Date: Wed, 14 Jul 2010 18:23:46 +1000 From: Peter Jeremy To: Martin Matuska Message-ID: <20100714082346.GA95442@server.vk2pj.dyndns.org> References: <4C31C71C.2010606@FreeBSD.org> <20100708200446.GA33822@server.vk2pj.dyndns.org> <4C364379.6020608@FreeBSD.org> <20100714001423.GA92530@server.vk2pj.dyndns.org> <4C3D6439.3010702@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <4C3D6439.3010702@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 08:23:52 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jul-14 09:16:09 +0200, Martin Matuska wrote: > Without head-12636.patch you are unable to reproduce the deadlock? The deadlock occurs with either stock 8-stable or with head-12636.patch. I have also been testing arc.patch2 from http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057696.html I am unable to reproduce the deadlock when using the combination of arc.patch2 and head-12636.patch but have not yet tested arc.patch2 alone. --=20 Peter Jeremy --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw9dBIACgkQ/opHv/APuId6TwCgjuqD4gvoDaHZFXmx+ACb2d/l U3UAnRoP5ctEgUDq5J5VX+ISKRMczzlr =3AA+ -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 09:26:11 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C1E0106566C for ; Wed, 14 Jul 2010 09:26:11 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [188.40.32.143]) by mx1.freebsd.org (Postfix) with ESMTP id B8ED88FC16 for ; Wed, 14 Jul 2010 09:26:10 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id B9FDE102AA1; Wed, 14 Jul 2010 11:26:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qnLISuDFrupv; Wed, 14 Jul 2010 11:26:07 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 2A722102A9A; Wed, 14 Jul 2010 11:26:07 +0200 (CEST) Message-ID: <4C3D82B0.1010907@FreeBSD.org> Date: Wed, 14 Jul 2010 11:26:08 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Peter Jeremy References: <4C31C71C.2010606@FreeBSD.org> <20100708200446.GA33822@server.vk2pj.dyndns.org> <4C364379.6020608@FreeBSD.org> <20100714001423.GA92530@server.vk2pj.dyndns.org> <4C3D6439.3010702@FreeBSD.org> <20100714082346.GA95442@server.vk2pj.dyndns.org> In-Reply-To: <20100714082346.GA95442@server.vk2pj.dyndns.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 09:26:11 -0000 In other words: The problem is not caused by head-12636.patch And this is important, otherwise we are seeking for an error where it isn't. I know about the current ARC problem and we have to seek a reasonable solution for it, but no ugly hacks that work only in specific cases / workloads. Dòa 14. 7. 2010 10:23, Peter Jeremy wrote / napísal(a): > On 2010-Jul-14 09:16:09 +0200, Martin Matuska wrote: >> Without head-12636.patch you are unable to reproduce the deadlock? > The deadlock occurs with either stock 8-stable or with head-12636.patch. > > I have also been testing arc.patch2 from > http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057696.html > I am unable to reproduce the deadlock when using the combination of > arc.patch2 and head-12636.patch but have not yet tested arc.patch2 alone. > From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 10:03:40 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CC051065673; Wed, 14 Jul 2010 10:03:40 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 9EB268FC18; Wed, 14 Jul 2010 10:03:39 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c211-30-160-13.belrs4.nsw.optusnet.com.au [211.30.160.13]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6EA3bHw021173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jul 2010 20:03:37 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o6EA3aAF096094; Wed, 14 Jul 2010 20:03:36 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o6EA3a75096093; Wed, 14 Jul 2010 20:03:36 +1000 (EST) (envelope-from peter) Date: Wed, 14 Jul 2010 20:03:36 +1000 From: Peter Jeremy To: Martin Matuska Message-ID: <20100714100336.GB95442@server.vk2pj.dyndns.org> References: <4C31C71C.2010606@FreeBSD.org> <20100708200446.GA33822@server.vk2pj.dyndns.org> <4C364379.6020608@FreeBSD.org> <20100714001423.GA92530@server.vk2pj.dyndns.org> <4C3D6439.3010702@FreeBSD.org> <20100714082346.GA95442@server.vk2pj.dyndns.org> <4C3D82B0.1010907@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline In-Reply-To: <4C3D82B0.1010907@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 10:03:40 -0000 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jul-14 11:26:08 +0200, Martin Matuska wrote: > In other words: >The problem is not caused by head-12636.patch Agreed. >And this is important, otherwise we are seeking for an error where it isn'= t. >I know about the current ARC problem and we have to seek a reasonable >solution for it, but no ugly hacks that work only in specific cases / >workloads. I only tried it because you recommended it as a solution to the ARC issue. At this stage, the "hack" patch I have is far less hackier than regularly running a 1-line perl script that just dirties a lot of memory and exits. --=20 Peter Jeremy --l76fUT7nc3MelDdI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw9i3gACgkQ/opHv/APuIezKgCbBJ5zj09VVbwTbiWDgC3EzbKC khcAniQB/rQuCUiRmC7bGFTGs2vGwtso =0W+o -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 12:31:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE01106566B for ; Wed, 14 Jul 2010 12:31:30 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51801.mail.re2.yahoo.com (web51801.mail.re2.yahoo.com [206.190.38.232]) by mx1.freebsd.org (Postfix) with SMTP id 5FCDE8FC13 for ; Wed, 14 Jul 2010 12:31:30 +0000 (UTC) Received: (qmail 27287 invoked by uid 60001); 14 Jul 2010 12:31:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1279110689; bh=UXqtfrOztvnWGBWu47ODYvdGZZhzzajidClsCIikYT0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pe344NUATQzoxBTdlZFL74QdSlskfnmUvhgcIxGENYyEIOVnyqkejlm09A/4U6xcBpbDdrKOIbm15mPVnU0NhJzRUZzi+EFgD6o41zkxhV+HVNhItzmwiGPNwLwAFcMbSqvxT+vdcT4Y3FRBKuAydFHhnv4cpVbhIcM86GRRxPQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EGRYVNJvjAPcnWCiw+jVLZMVcb9kk2HIWNFzqQkp7HXuXpbSXxZzPObuLlwU5c0q6PmZwAncgnn3rQZHuoH4mGeDhDlNW/9tNRy4wveXLlKT06GqHsGUIyoGXzdowv+RAtADSJ//u3/CI0UXWwyLEIHaKiEBqfXNPfSOnd42foU=; Message-ID: <713105.26677.qm@web51801.mail.re2.yahoo.com> X-YMail-OSG: _JMZQK8VM1knJTTRFUB_QnY4qPxbzLrMf6444YC0WUr6jUR GAO5dnvisN1P45v4MnuRZe8vL0t91RKO2naGdB6_zKIDmDpNXbZn4iQT1XSF J9DLwyfF1u9z98b79NCqUB5iec5VU4wPjTWelCDTBhDeIE0l_dbGRkaLVb0D KvvKFR4DulSc6TomDdUcd2ScVCDPMYs27F1OuKD_ulUmPzLMePXN4D5zJE7G gJ32xgOyKKayg2LxAjcM20YsNp5_gxNraYYjNa06v95nb90qluuWjWchY1eV zhxSa3Fn0xI.NRi2vuLXx37TChXweoVa29YrjkJKHcM1V51TnHjrbQaRNtvJ N8pZxYLJFmUA- Received: from [173.183.132.20] by web51801.mail.re2.yahoo.com via HTTP; Wed, 14 Jul 2010 05:31:29 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.104.276605 References: <201007072113.16320.hselasky@c2i.net> <201007122201.11534.hselasky@c2i.net> Date: Wed, 14 Jul 2010 05:31:29 -0700 (PDT) From: PseudoCylon To: Hans Petter Selasky , freebsd-current@freebsd.org In-Reply-To: <201007122201.11534.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Leffler , freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 12:31:30 -0000 ----- Original Message ---- > From: Hans Petter Selasky > To: freebsd-current@freebsd.org > Cc: Andrew Thompson ; Sam Leffler ; >PseudoCylon ; freebsd-usb@freebsd.org > Sent: Mon, July 12, 2010 2:01:11 PM > Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers > > Hi Andrew, > > Your patch appears to be working. Can you fix this issue in the other WLAN > drivers aswell? Then send an e-mail to request testing? I had a go at it here: > > http://p4web.freebsd.org/@@180844?ac=10 > Can this patch be included into testing? patch to P4 USB rev. 14 if_run.c If not, at least please delete an extra semicolon at the end of line 3191 (must be an merge bug). I missed it since it wans't in diff/patch. AK summary of changes * fixes bugs in rev 209144 a shared key was written properly only on first time init, but not subsequent init. Make sure the key is written all the time. * stop checking 'pending' in run_cmdq_cb(). When loop 'pending' times, new tasks enqueued while looping won't be executed because 'pending' passed from taskqueue function won't be incremented. -- patch begin -- diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c index 7a3952c..12b45ec 100644 --- a/dev/usb/wlan/if_run.c +++ b/dev/usb/wlan/if_run.c @@ -830,9 +830,6 @@ run_vap_create(struct ieee80211com *ic, if(sc->rvp_cnt++ == 0) ic->ic_opmode = opmode; -if(opmode == IEEE80211_M_HOSTAP) -sc->cmdq_run = RUN_CMDQ_GO; - DPRINTF("rvp_id=%d bmap=%x rvp_cnt=%d\n", rvp->rvp_id, sc->rvp_bmap, sc->rvp_cnt); @@ -891,15 +888,16 @@ run_cmdq_cb(void *arg, int pending) /* call cmdq[].func locked */ RUN_LOCK(sc); -for(i = sc->cmdq_exec; sc->cmdq[i].func && pending; - i = sc->cmdq_exec, pending--){ +for (i = sc->cmdq_exec; sc->cmdq[i].func; i = sc->cmdq_exec) { DPRINTFN(6, "cmdq_exec=%d pending=%d\n", i, pending); -if(sc->cmdq_run == RUN_CMDQ_GO){ +if (sc->cmdq_run == RUN_CMDQ_GO || + (sc->cmdq_key_set == RUN_CMDQ_GO && + sc->cmdq[i].func == run_key_set_cb)) { /* * If arg0 is NULL, callback func needs more * than one arg. So, pass ptr to cmdq struct. */ -if(sc->cmdq[i].arg0) +if (sc->cmdq[i].arg0) sc->cmdq[i].func(sc->cmdq[i].arg0); else sc->cmdq[i].func(&sc->cmdq[i]); @@ -1771,6 +1769,19 @@ run_newstate(struct ieee80211vap *vap, enum ieee80211_state nstate, int arg) case IEEE80211_S_INIT: restart_ratectl = 1; +/* + * When hostapd has set a key, don't clear it. + * But, when the device is being brought down, clear it. + */ +if (sc->cmdq_key_set != RUN_CMDQ_GO || + ostate == IEEE80211_S_RUN) { +/* clear shared key table */ +run_set_region_4(sc, + RT2860_SKEY(rvp->rvp_id, 0), 0, 4 * 32); +/* clear shared key mode */ +run_set_region_4(sc, RT2860_SKEY_MODE_0_7, 0, 4); +} + if (ostate != IEEE80211_S_RUN) break; @@ -2100,13 +2111,10 @@ run_key_set(struct ieee80211vap *vap, struct ieee80211_key *k, * To make sure key will be set when hostapd * calls iv_key_set() before if_init(). */ -if(vap->iv_opmode == IEEE80211_M_HOSTAP){ -RUN_LOCK(sc); +if (vap->iv_opmode == IEEE80211_M_HOSTAP) sc->cmdq_key_set = RUN_CMDQ_GO; -RUN_UNLOCK(sc); -} -return(1); +return (1); } /* @@ -3188,7 +3196,7 @@ run_sendprot(struct run_softc *sc, ackrate = ieee80211_ack_rate(ic->ic_rt, rate); isshort = (ic->ic_flags & IEEE80211_F_SHPREAMBLE) != 0; -dur = ieee80211_compute_duration(ic->ic_rt, pktlen, rate, isshort); +dur = ieee80211_compute_duration(ic->ic_rt, pktlen, rate, isshort) + ieee80211_ack_duration(ic->ic_rt, rate, isshort); wflags = RT2860_TX_FRAG; @@ -4693,14 +4701,6 @@ run_init_locked(struct run_softc *sc) /* clear WCID attribute table */ run_set_region_4(sc, RT2860_WCID_ATTR(0), 0, 8 * 32); -/* hostapd sets a key before init. So, don't clear it. */ -if(sc->cmdq_key_set != RUN_CMDQ_GO){ -/* clear shared key table */ -run_set_region_4(sc, RT2860_SKEY(0, 0), 0, 8 * 32); -/* clear shared key mode */ -run_set_region_4(sc, RT2860_SKEY_MODE_0_7, 0, 4); -} - run_read(sc, RT2860_US_CYC_CNT, &tmp); tmp = (tmp & ~0xff) | 0x1e; run_write(sc, RT2860_US_CYC_CNT, tmp); @@ -4807,7 +4807,7 @@ run_stop(void *arg) ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); sc->ratectl_run = RUN_RATECTL_OFF; -sc->cmdq_run = sc->cmdq_key_set; +sc->cmdq_run = RUN_CMDQ_ABORT; RUN_UNLOCK(sc); -- end patch -- From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 12:33:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACFBA1065674 for ; Wed, 14 Jul 2010 12:33:00 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51804.mail.re2.yahoo.com (web51804.mail.re2.yahoo.com [206.190.38.235]) by mx1.freebsd.org (Postfix) with SMTP id 505B28FC0A for ; Wed, 14 Jul 2010 12:33:00 +0000 (UTC) Received: (qmail 25081 invoked by uid 60001); 14 Jul 2010 12:32:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1279110779; bh=s9zZTAkKlAa891hg1a8p3+/FW2+zvcp6NV1mwmhkKwE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0OquwBVDHiRNLa83ebb0PVnIj/INM2vu3QUhH96qDeqD28iIa9MH7gWjBEQzdmdyVeffaDJ863XGcc30nkjZXTqBog107pnX8N51MlXadS9mlX3h7xojxbiHTAW6FX9+ZZG6lsIagdD4a+aVyc7trsiPVEL1RGPvWhNb5e6I6VU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ICPCA9tOdF74szfp9eoYpdM2uOIIqhGBp4b/Zj/pShDhZJ+MVkguUnfD7fe2tUkoIDEMvX3VcH9fkCYqJKSuxg4F4Z4gjEvtvB/L65QohX9pV0m4DJelPDtqG+GoB3iAliuyQAUyNhN2JG4WjQ8SmECkODBmO+5koFdP/i3d6IY=; Message-ID: <465071.23870.qm@web51804.mail.re2.yahoo.com> X-YMail-OSG: y4hTrtMVM1lCyjUnq50DDljgglj.6EVESdTOn5qAYiyvwZ9 WPeuaE3nLlFZ7_uEux1WUrDItVTcyQwGYz9CcttOTNnD4dgNwP.CV2ytPa9D sf7XACv7ahOxOWpTRvzJv5TAwARN8dl6bCi2Q9e1ch5blA7hQToiXf2zuE.X c1X5bfQLulmJoCuUFIrjgoMmeIAooOhHD4xGtqq_e_fcu7uVVItvH7dA906R 84XAY3Pi2lwUCRN9GAsn9xAb4x1Xje.gybv1t_RU5USCCO3QWDsT6sfDOMfn wGWgQYdunik1Gbi5xR77PU1M_Dj22tJtwBzm.AEeLhaZYhfNN Received: from [173.183.132.20] by web51804.mail.re2.yahoo.com via HTTP; Wed, 14 Jul 2010 05:32:59 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.104.276605 References: <597509.54869.qm@web51805.mail.re2.yahoo.com> <4C3C9CBB.7060103@gmail.com> Date: Wed, 14 Jul 2010 05:32:59 -0700 (PDT) From: PseudoCylon To: Ganbold In-Reply-To: <4C3C9CBB.7060103@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ganbold Tsagaankhuu , freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 12:33:00 -0000 ----- Original Message ---- > From: Ganbold > To: PseudoCylon > Cc: Ganbold Tsagaankhuu ; freebsd-current@freebsd.org > Sent: Tue, July 13, 2010 11:04:59 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > PseudoCylon wrote: > > ----- Original Message ---- > > > >> From: PseudoCylon > >> To: Ganbold Tsagaankhuu > >> Cc: Ganbold ; freebsd-current@freebsd.org > >> Sent: Tue, July 6, 2010 12:26:58 AM > >> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > >> > >> > >>>>>>>> From: Ganbold > >>>>>>>> To: PseudoCylon > >>>>>>>> Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu > >>>>>>>> > >> > >> > >>>>>>>> Sent: Wed, June 16, 2010 6:33:47 AM > >>>>>>>> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > >>>>>>>> > >>>>>>>> AK-san, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> PseudoCylon wrote: > >>>>>>> > >>>>>>> Strange, looks like this time works as expected, but sometimes it > >>>>>>> doesn't work. > >>>>>>> > >>>>>>> In some cases it doesn't work and you can find complete tcpdump >output > >>>>>>> from very beginning to the modem hang: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> Are following true? > >>>>>> When manually load/reload hostapd, works > >>>>>> When loaded by rc.conf, doesn't work > >>>>>> > >>>>>> If so, please try attached patch. (patch to if_run.c only) Or, here is >a > > >>>>>> > >> patched file. > >> > >>>>>> http://gitorious.org/run/run/blobs/raw/cmdq_fix/dev/usb/wlan/if_run.c > >>>>>> > >>>>>> When auto-loading, the driver is brought up and down a few times. It > >>>>>> > >> might be the cause. > >> > >>>>>> > >>>>>> > >>>>> I will test it few more days and let you know. > >>>>> > >>>>> thanks, > >>>>> > >>>>> Ganbold > >>>>> > >>>>> > >>>> Hello, > >>>> > >>>> How is the patch doing on your rspro? Is it working well? > >>>> > >>>> > >>> Sorry for late response. Due to business trip I tested couple of times > >>> only and it seems working relatively ok. 1-2 times ADSL modem hang, but > >>> seemed like after 3-4 hours. > >>> Tried couple of times again, but I couldn't reproduce it. I will try to > >>> reproduce it and let you know the results. > >>> > >>> thanks a lot, > >>> > >>> Ganbold > >>> > > Hello, Ganbold > > > > Is the latest patch working? > > > > AK-san, > > Only tested once, the patch works ok so far. > > thanks, > > Ganbold > Good to hear. If anything goes wrong please report. Thanks for testing. AK From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 12:53:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3E6A106564A; Wed, 14 Jul 2010 12:53:56 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id B79888FC1E; Wed, 14 Jul 2010 12:53:55 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=HRj3ij7MtkgA:10 a=UBIxAjGgU1YA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=yp3tKpVPvOpUWRPwl10A:9 a=vb7KpOactU-25VnTXeMpJ6YlZ3kA:4 a=wPNLvfGTeEIA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1393927694; Wed, 14 Jul 2010 14:53:53 +0200 From: Hans Petter Selasky To: PseudoCylon Date: Wed, 14 Jul 2010 14:50:59 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201007072113.16320.hselasky@c2i.net> <201007122201.11534.hselasky@c2i.net> <713105.26677.qm@web51801.mail.re2.yahoo.com> In-Reply-To: <713105.26677.qm@web51801.mail.re2.yahoo.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007141450.59356.hselasky@c2i.net> Cc: Sam Leffler , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 12:53:56 -0000 On Wednesday 14 July 2010 14:31:29 PseudoCylon wrote: > -if(vap->iv_opmode == IEEE80211_M_HOSTAP){ > -RUN_LOCK(sc); > +if (vap->iv_opmode == IEEE80211_M_HOSTAP) > sc->cmdq_key_set = RUN_CMDQ_GO; > -RUN_UNLOCK(sc); > -} > Why are you removing these locks? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 13:14:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3D2C1065678; Wed, 14 Jul 2010 13:14:43 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id C71E48FC15; Wed, 14 Jul 2010 13:14:42 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=+aufMl16ZjoZikD717oZHt/II3iOLg17uabV0d0CmU0= c=1 sm=1 a=HRj3ij7MtkgA:10 a=UBIxAjGgU1YA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=BEL1k6X5M7XCOl_27zQA:9 a=_FUVAfVLo7ZMgwwlwbfSzTOVigcA:4 a=wPNLvfGTeEIA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 289938; Wed, 14 Jul 2010 15:14:41 +0200 To: PseudoCylon From: Hans Petter Selasky X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' Date: Wed, 14 Jul 2010 15:11:46 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007141511.46190.hselasky@c2i.net> Cc: Sam Leffler , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 13:14:43 -0000 On Wednesday 14 July 2010 14:31:29 PseudoCylon wrote: > -if(vap->iv_opmode == IEEE80211_M_HOSTAP){ > -RUN_LOCK(sc); > +if (vap->iv_opmode == IEEE80211_M_HOSTAP) > sc->cmdq_key_set = RUN_CMDQ_GO; > -RUN_UNLOCK(sc); > -} > > Why are you removing these locks? Another question: i = RUN_CMDQ_GET(&sc->cmdq_store); DPRINTF("cmdq_store=%d\n", i); sc->cmdq[i].func = run_update_beacon_cb; sc->cmdq[i].arg0 = vap; Why is this code and similar places not enclosed with mutexes? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 18:43:15 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95D56106564A for ; Wed, 14 Jul 2010 18:43:15 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 4F11D8FC14 for ; Wed, 14 Jul 2010 18:43:14 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 7715D9CB0ED for ; Wed, 14 Jul 2010 20:38:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTebFFBby0m2 for ; Wed, 14 Jul 2010 20:38:35 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id EA97D9CB70D for ; Wed, 14 Jul 2010 20:38:34 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id o6EIcYOq019753 for current@freebsd.org; Wed, 14 Jul 2010 20:38:34 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 14 Jul 2010 20:38:34 +0200 From: Roman Divacky To: current@freebsd.org Message-ID: <20100714183834.GA19684@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [TESTING]: updated clang/LLVM needs testing in ClangBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 18:43:15 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi, ClangBSD was updated to LLVM/clang revision r108243 which we plan to merge into HEAD. We would like that revision to be tested as much as possible and therefore we ask you to test ClangBSD to assure that the revision we are updating to does not have some really embarassing bugs. How to do it (on i386 and amd64): 0) install fresh devel/llvm-devel port 1) svn co http://svn.freebsd.org/base/projects/clangbsd src 2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf 3) cd src && make buildworld 4) make installworld DESTDIR=/usr/clangbsd 5) (optional) try to build kernel with clang and boot it 5.1) cd /sys/{arch}/conf 5.2) config YOUR_KERNEL 5.3) setenv CC clang in tcsh or export CC=clang in sh/bash 5.4) cd ../compile/YOUR_KERNEL 5.5) make && make install please make sure that it builds (on amd64/i386) and that the resulting world is runnable. ie. try to chroot into it and "do stuff". ie. chroot /clangbsd /bin/tcsh ... stuff ... there's a wiki page on this effort: http://wiki.freebsd.org/BuildingFreeBSDWithClang please report back any problems/success to me and/or this mailing list.0 thank you for your testing! Roman Divacky on behalf of the ClangBSD team --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw+BCoACgkQLVEj6D3CBEzpegCfXhs1My8oPJ+aExHVDGeAfui6 4KsAn21oQNSXbHLksCOK/RegPJ+13LGN =bbh7 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 21:26:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EAF01065678; Wed, 14 Jul 2010 21:26:37 +0000 (UTC) (envelope-from jasonjwwilliams@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id C5F498FC1F; Wed, 14 Jul 2010 21:26:36 +0000 (UTC) Received: by gyd8 with SMTP id 8so253801gyd.13 for ; Wed, 14 Jul 2010 14:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xQXUBJ1o15DNWrKMwHouWNNhoLWhBczHsLIaD4RstUk=; b=O3dcHb6c+6y8RUqyuBWaGSWwyuoFAmVAFRYebCdFZDWXSd4F+kM5VRbe+BHm8Hytee /pE1EQDZq0UDDELN3rgSUnEFk4scyFzfzhs/O+RbhtUaRHa0aW+x1QoGRbGOniVBH69Y 0JSEg0BMd8NtJostMcfIybkiYfrmh0ndvNPCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=X8mr3xnzhVvbOqc7VcRExPjQkja+eqP31O3l8PBttrwEhyhPAGakgAb/KqS8v9pta6 74XY9NoGmrDdPdO5168OUP/HC0J0/efMd7ljAlWPvqM+kyNgqKH+vdwPUNCZtVFGNdvO cu61bjWf8LYO/n4iX8TswZkwbPxQgtiHSA7Tc= MIME-Version: 1.0 Received: by 10.151.134.34 with SMTP id l34mr8889986ybn.263.1279142795159; Wed, 14 Jul 2010 14:26:35 -0700 (PDT) Received: by 10.220.202.68 with HTTP; Wed, 14 Jul 2010 14:26:34 -0700 (PDT) In-Reply-To: <4C3D678E.5040403@FreeBSD.org> References: <4C3D08A5.2090109@dataix.net> <4C3D678E.5040403@FreeBSD.org> Date: Wed, 14 Jul 2010 15:26:34 -0600 Message-ID: From: "Jason J. W. Williams" To: Martin Matuska Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, grarpamp Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2010 21:26:37 -0000 Hey Martin, Actually it's this one: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=3D6574286 -J On Wed, Jul 14, 2010 at 1:30 AM, Martin Matuska wrote: > =C2=A0What about the OpenSolaris revision 9701 for starters? > Could that help your case? > > 9701:cc5b64682e64 > > 6803605 should be able to offline log devices > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=3D6803605 > > 6726045 vdev_deflate_ratio is not set when offlining a log device > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=3D6726045 > > D=C5=88a 14. 7. 2010 2:45, jhell wrote / nap=C3=ADsal(a): >> On 07/13/2010 12:30, Jason J. W. Williams wrote: >>> If there's any way to backport ZFS log device removal that would be >>> very helpful. That's the primary hold up for ops folks moving our >>> OpenSolaris servers to FreeBSD. >> I second this. >> >> In explanation I have one machine that needs to be rearranged for a >> upgrade/update for a different purpose than what it is currently doing >> that is holding up some of the other tasks that are planned. I already >> made the mistake once in a test situation by removing a log device that >> was da0 during a reboot & popped in another device, something happened, >> rebooted the machine, plugged in original and the situation was >> irreparable causing the pool to be corrupt. >> >> Needless to say it was only a test environment but this has stopped me >> cold from using further log devices because of this. ;( >> >> This is not really top priority right now but would be a great Christmas >> present ;) >> >> If someone points me in the right direction I guess I could always start >> reviewing the changes for inclusion on a patch against head & stable/8. >> >> >> Regards, Thanks & Good Luck, >> > From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 11:25:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D80A1065679; Thu, 15 Jul 2010 11:25:31 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 10D788FC21; Thu, 15 Jul 2010 11:25:29 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA29185; Thu, 15 Jul 2010 14:25:28 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OZMZD-0001hZ-U5; Thu, 15 Jul 2010 14:25:28 +0300 Message-ID: <4C3EF026.7090706@freebsd.org> Date: Thu, 15 Jul 2010 14:25:26 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> <4C39B7DE.3030100@freebsd.org> In-Reply-To: <4C39B7DE.3030100@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2010 11:25:32 -0000 on 11/07/2010 15:23 Andriy Gapon said the following: > on 11/07/2010 14:54 Andriy Gapon said the following: >> For completeness, here is a patch that simply drops the inline assembly and the >> comment about it, and GCC-generated assembly and its diff: >> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff >> >> As was speculated above, the only thing really changed is section alignment >> (from 128 to 4). > > After making the above analysis I wondered why we require set_pcpu section > alignment at all. After all, it's not used as loaded, data from the section > gets copied into special per-cpu memory areas. So, logically, it's those areas > that need to be aligned, not the section. > > svn log and google quickly pointed me to this excellent analysis and explanation > by bz (thanks again!): > http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff > > Summary: this alignment is needed to work around a bug in GNU binutils ld for > __start_SECNAME placement. > > As explained by bz, ld internally generates an equivalent of the following > linker script: > ... > __start_pcpu_set = ALIGN(NN); > pcpu_set : { > ... > } > __stop_pcpu_set = .; > > Where NN is an alignment of the first _input_ pcpu_set section found in > whichever .o file happens to be first. Not the resulting alignment of pcpu_set > _output_ section. > Alignment requirement of input sections is based on largest alignment > requirement of section's members. So if section is empty then the required > alignment is 1. Alignment of output section, if not explicitly overridden e.g. > via linker script, is the largest alignment of the corresponding input sections. > > I think that the problem can be fixed by making ld define __start_SECNAME like > follows: > ... > pcpu_set : { > __start_pcpu_set = ABSOLUTE(.); > ... > } > __stop_pcpu_set = .; > > This way __start_SECNAME would always point to the actual start of the output > section. > > Here's a patch that implements the idea: > http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch > > This is similar to what was done upstream: > http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306&r2=1.307&cvsroot=src&f=h > The code is quite different there, and approach is somewhat different, but the > idea is the same - place __start_SECNAME inside the section, not outside it. Does anybody see any obvious or non-obvious flaw in the above analysis and the proposed patches? Does anyone object against me committing the ld patch and some time later the pcpu.h patch? My plan is to commit the ld patch tomorrow and the pcpu.h patch early next week. P.S. Pro-active testing is welcome! Especially if you have an "unusual" architecture or use epair or both. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 11:33:05 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA996106566B; Thu, 15 Jul 2010 11:33:05 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8958FC1B; Thu, 15 Jul 2010 11:33:05 +0000 (UTC) Received: by ywf9 with SMTP id 9so71556ywf.13 for ; Thu, 15 Jul 2010 04:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=gIrRl0D/9plhVYL68+er+rnAgxTQrDJwOj6J2LgYjzw=; b=qmua3wJRsEJ+PtHbxhm6ItiXeJahu0VYUyYHj0DC2mymwGWMSNilsp592XeOMOVWSD p9IUC+QImou46wiJolRJAzL7rkHfdgrBBD6prcTL90y3v8DbWLy3dew6my2wAvy07Ixi Caa9Ig1xI8yuviL7xiUM5BnhmQUjzCo7Tkq7w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=k8HSM4kf2GyT9XCPPXrAHvnktg4NEsj2twtoPvxJMo5/ebonTrx/MQEfz6dyxhljR4 eidKLhP8OnSVeCkMK4/Dh0kT4/4Wgw5MxqA+aiWBL8JgWSMUkJwaLyBNr2IrhcXoX12x rDt1aXzJxDTPSTgCuS4M4lNTmFmlCOcHf0uc4= MIME-Version: 1.0 Received: by 10.150.142.3 with SMTP id p3mr5833222ybd.114.1279193584547; Thu, 15 Jul 2010 04:33:04 -0700 (PDT) Sender: r.c.ladan@gmail.com Received: by 10.151.15.15 with HTTP; Thu, 15 Jul 2010 04:33:04 -0700 (PDT) In-Reply-To: <20100714183834.GA19684@freebsd.org> References: <20100714183834.GA19684@freebsd.org> Date: Thu, 15 Jul 2010 13:33:04 +0200 X-Google-Sender-Auth: ta6QI9noMhFtlf1bKZ1TbQ5UUVE Message-ID: From: =?ISO-8859-1?Q?Ren=E9_Ladan?= To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: [TESTING]: updated clang/LLVM needs testing in ClangBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2010 11:33:06 -0000 2010/7/14 Roman Divacky : > hi, > > ClangBSD was updated to LLVM/clang revision r108243 which we plan to > merge into HEAD. We would like that revision to be tested as much as possible > and therefore we ask you to test ClangBSD to assure that the revision > we are updating to does not have some really embarassing bugs. > > How to do it (on i386 and amd64): > > 0) install fresh devel/llvm-devel port > > 1) svn co http://svn.freebsd.org/base/projects/clangbsd src > > 2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf > > 3) cd src && make buildworld > And here my buildworld fails with: ===> lib/clang/libclanglex (depend) tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Common /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td > DiagnosticCommonKinds.inc.h tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Lex /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td > DiagnosticLexKinds.inc.h rm -f .depend CC='clang -isysroot /usr/obj/usr/home/rene/freebsd/clangbsd/tmp -B/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/ -L/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/' mkdep -f .depend -a -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" -DCLANG_VENDOR=\"FreeBSD\ \" -DSVN_REVISION=\"108243\" -DCLANG_VENDOR_SUFFIX=\"\ 20100713\" /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/LiteralSupport.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroArgs.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroInfo.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPCaching.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPDirectives.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPExpressions.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPLexerChange.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPMacroExpansion.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PTHLexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Pragma.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessingRecord.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Preprocessor.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessorLexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/ScratchBuffer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/TokenConcatenation.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/TokenLexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:1110:10: fatal error: 'emmintrin.h' file not found #include ^ 1 error generated. mkdep: compile failed *** Error code 1 Stop in /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex. *** Error code 1 Stop in /usr/home/rene/freebsd/clangbsd/lib/clang. *** Error code 1 Stop in /usr/home/rene/freebsd/clangbsd/lib. *** Error code 1 Stop in /usr/home/rene/freebsd/clangbsd. *** Error code 1 Stop in /usr/home/rene/freebsd/clangbsd. *** Error code 1 Stop in /usr/home/rene/freebsd/clangbsd. *** Error code 1 Stop in /usr/home/rene/freebsd/clangbsd. I do have CPUTYPE=nocona in /etc/make.conf, but apart from that /etc/make.conf only contains port-related stuff. /etc/src.conf only contains the two WERROR lines. acer# locate emmintrin.h /usr/home/rene/freebsd/clangbsd/contrib/gcc/config/i386/.svn/prop-base/emmintrin.h.svn-base /usr/home/rene/freebsd/clangbsd/contrib/gcc/config/i386/.svn/text-base/emmintrin.h.svn-base /usr/home/rene/freebsd/clangbsd/contrib/gcc/config/i386/emmintrin.h /usr/home/rene/freebsd/clangbsd/contrib/llvm/tools/clang/lib/Headers/.svn/text-base/emmintrin.h.svn-base /usr/home/rene/freebsd/clangbsd/contrib/llvm/tools/clang/lib/Headers/emmintrin.h /usr/include/clang/2.0/emmintrin.h /usr/include/gcc/4.2/emmintrin.h /usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd9.0/4.4.5/include/emmintrin.h /usr/obj/usr/src/tmp/usr/include/clang/2.0/emmintrin.h /usr/obj/usr/src/tmp/usr/include/gcc/4.2/emmintrin.h acer# ls -l /usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/include/*/*/emmintrin.h -rwxr-xr-x 1 root wheel 36913 Jul 15 11:24 /usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/include/clang/2.8/emmintrin.h -rwxr-xr-x 1 root wheel 42617 Oct 14 2009 /usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/include/gcc/4.2/emmintrin.h acer# uname -a FreeBSD acer 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r209980M: Tue Jul 13 11:48:03 CEST 2010 rene@acer:/usr/obj/usr/src/sys/GENERIC amd64 Regards, Rene From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 11:39:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C250106567B; Thu, 15 Jul 2010 11:39:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2432C8FC15; Thu, 15 Jul 2010 11:39:54 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o6FBdoQJ082478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 14:39:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o6FBdonA043778; Thu, 15 Jul 2010 14:39:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6FBdotr043777; Thu, 15 Jul 2010 14:39:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Jul 2010 14:39:50 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20100715113950.GT2381@deviant.kiev.zoral.com.ua> References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> <4C39B7DE.3030100@freebsd.org> <4C3EF026.7090706@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8+OS07CeIgZ706fH" Content-Disposition: inline In-Reply-To: <4C3EF026.7090706@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2010 11:39:55 -0000 --8+OS07CeIgZ706fH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 02:25:26PM +0300, Andriy Gapon wrote: > on 11/07/2010 15:23 Andriy Gapon said the following: > > on 11/07/2010 14:54 Andriy Gapon said the following: > >> For completeness, here is a patch that simply drops the inline assembl= y and the > >> comment about it, and GCC-generated assembly and its diff: > >> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch > >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s > >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff > >> > >> As was speculated above, the only thing really changed is section alig= nment > >> (from 128 to 4). > >=20 > > After making the above analysis I wondered why we require set_pcpu sect= ion > > alignment at all. After all, it's not used as loaded, data from the se= ction > > gets copied into special per-cpu memory areas. So, logically, it's tho= se areas > > that need to be aligned, not the section. > >=20 > > svn log and google quickly pointed me to this excellent analysis and ex= planation > > by bz (thanks again!): > > http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff > >=20 > > Summary: this alignment is needed to work around a bug in GNU binutils = ld for > > __start_SECNAME placement. > >=20 > > As explained by bz, ld internally generates an equivalent of the follow= ing > > linker script: > > ... > > __start_pcpu_set =3D ALIGN(NN); > > pcpu_set : { > > ... > > } > > __stop_pcpu_set =3D .; > >=20 > > Where NN is an alignment of the first _input_ pcpu_set section found in > > whichever .o file happens to be first. Not the resulting alignment of = pcpu_set > > _output_ section. > > Alignment requirement of input sections is based on largest alignment > > requirement of section's members. So if section is empty then the requ= ired > > alignment is 1. Alignment of output section, if not explicitly overrid= den e.g. > > via linker script, is the largest alignment of the corresponding input = sections. > >=20 > > I think that the problem can be fixed by making ld define __start_SECNA= ME like > > follows: > > ... > > pcpu_set : { > > __start_pcpu_set =3D ABSOLUTE(.); > > ... > > } > > __stop_pcpu_set =3D .; > >=20 > > This way __start_SECNAME would always point to the actual start of the = output > > section. > >=20 > > Here's a patch that implements the idea: > > http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch > >=20 > > This is similar to what was done upstream: > > http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=3D1.30= 6&r2=3D1.307&cvsroot=3Dsrc&f=3Dh > > The code is quite different there, and approach is somewhat different, = but the > > idea is the same - place __start_SECNAME inside the section, not outsid= e it. >=20 > Does anybody see any obvious or non-obvious flaw in the above analysis an= d the > proposed patches? > Does anyone object against me committing the ld patch and some time later= the > pcpu.h patch? >=20 > My plan is to commit the ld patch tomorrow and the pcpu.h patch early nex= t week. >=20 > P.S. > Pro-active testing is welcome! Especially if you have an "unusual" archi= tecture > or use epair or both. >=20 Is new behaviour completely identical to the behaviour of the newer ld ? Even if yes, I think that such changes make potential import of newer binutils harder. --8+OS07CeIgZ706fH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw+84UACgkQC3+MBN1Mb4hteACdG6JTcLWlpNSmv/+Nly2eBk2t hlEAoJxEY5TdVYFqCXL1jGMco2VIhTFZ =Wh6A -----END PGP SIGNATURE----- --8+OS07CeIgZ706fH-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 12:00:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E91431065673; Thu, 15 Jul 2010 12:00:45 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 052698FC35; Thu, 15 Jul 2010 12:00:44 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA29613; Thu, 15 Jul 2010 15:00:42 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C3EF869.9070804@freebsd.org> Date: Thu, 15 Jul 2010 15:00:41 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Kostik Belousov References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> <4C39B7DE.3030100@freebsd.org> <4C3EF026.7090706@freebsd.org> <20100715113950.GT2381@deviant.kiev.zoral.com.ua> In-Reply-To: <20100715113950.GT2381@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2010 12:00:46 -0000 on 15/07/2010 14:39 Kostik Belousov said the following: > > Is new behaviour completely identical to the behaviour of the newer > ld ? No, it's not completely identical. __start_SECNAME placement would be identical, but our ld would still assign the symbol while latest upstream binutils PROVIDES it. > Even if yes, I think that such changes make potential import of > newer binutils harder. How? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 12:36:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFE1A106566C; Thu, 15 Jul 2010 12:36:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 77BDC8FC1D; Thu, 15 Jul 2010 12:35:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o6FCZwZE086835; Thu, 15 Jul 2010 08:35:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o6FCZvG3086813; Thu, 15 Jul 2010 12:35:57 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 15 Jul 2010 12:35:57 GMT Message-Id: <201007151235.o6FCZvG3086813@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips 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, 15 Jul 2010 12:36:01 -0000 TB --- 2010-07-15 12:35:16 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-15 12:35:16 - starting HEAD tinderbox run for mips/mips TB --- 2010-07-15 12:35:16 - cleaning the object tree TB --- 2010-07-15 12:35:28 - cvsupping the source tree TB --- 2010-07-15 12:35:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-07-15 12:35:57 - building world TB --- 2010-07-15 12:35:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-07-15 12:35:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-07-15 12:35:57 - TARGET=mips TB --- 2010-07-15 12:35:57 - TARGET_ARCH=mips TB --- 2010-07-15 12:35:57 - TZ=UTC TB --- 2010-07-15 12:35:57 - __MAKE_CONF=/dev/null TB --- 2010-07-15 12:35:57 - cd /src TB --- 2010-07-15 12:35:57 - /usr/bin/make -B buildworld "/src/Makefile.inc1", line 1484: ERROR: kernel config file not found. *** Error code 1 Stop in /src. TB --- 2010-07-15 12:35:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-07-15 12:35:57 - ERROR: failed to build world TB --- 2010-07-15 12:35:57 - 2.39 user 10.01 system 41.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 12:54:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F965106567A for ; Thu, 15 Jul 2010 12:54:49 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from mail-forward.uio.no (mail-forward.uio.no [129.240.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id EA7678FC17 for ; Thu, 15 Jul 2010 12:54:48 +0000 (UTC) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1OZNdv-0004DM-VZ for freebsd-current@freebsd.org; Thu, 15 Jul 2010 14:34:23 +0200 Received: from putsch.kolbu.ws ([158.36.191.193]) by mail-mx3.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OZNdv-0007wH-JW for freebsd-current@freebsd.org; Thu, 15 Jul 2010 14:34:23 +0200 Received: from chiller by putsch.kolbu.ws with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OZNdv-0007ro-BP for freebsd-current@freebsd.org; Thu, 15 Jul 2010 14:34:23 +0200 Date: Thu, 15 Jul 2010 14:34:23 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: freebsd-current@freebsd.org Message-ID: <20100715123423.GC52222@putsch.kolbu.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.18 (2008-05-17) X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 629347B372D67D49D58A7B5097BD9FCD30C6A559 X-UiO-SPAM-Test: remote_host: 158.36.191.193 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1692 max/h 11 blacklist 0 greylist 0 ratelimit 0 Subject: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2010 12:54:49 -0000 Upgraded to from stable to current yesterday and very quickly received a panic. It did however not dump it's core, so I was unable to debug it. Today it did panic again, and I took a picture: (Sorry about the bad quality) http://folk.uio.no/stalk/mpt/IMG_1403.JPG And from the backtrace: http://folk.uio.no/stalk/mpt/IMG_1404.JPG Both times I hade the mpt0: request timed out just before the panic. I'm not sure why it's not dumping it's core (It was working under stable, and I have dumpdev="AUTO" and dumpdir="/var/crash" in rc.conf) -- Ståle Kristoffersen From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 14:32:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93E671065675 for ; Thu, 15 Jul 2010 14:32:46 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from mail-forward.uio.no (mail-forward.uio.no [129.240.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1B6CB8FC1C for ; Thu, 15 Jul 2010 14:32:45 +0000 (UTC) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1OZPUT-00088z-1i for freebsd-current@freebsd.org; Thu, 15 Jul 2010 16:32:45 +0200 Received: from putsch.kolbu.ws ([158.36.191.193]) by mail-mx3.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OZPUS-0001jK-FT for freebsd-current@freebsd.org; Thu, 15 Jul 2010 16:32:44 +0200 Received: from chiller by putsch.kolbu.ws with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OZPUS-000AJB-6g; Thu, 15 Jul 2010 16:32:44 +0200 Date: Thu, 15 Jul 2010 16:32:44 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: =?iso-8859-1?Q?St=E5le?= Kristoffersen Message-ID: <20100715143244.GA37994@putsch.kolbu.ws> References: <20100715123423.GC52222@putsch.kolbu.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100715123423.GC52222@putsch.kolbu.ws> User-Agent: Mutt/1.5.18 (2008-05-17) X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8E90C473E1FF9673F26456F90BA0DDE39F1116AE X-UiO-SPAM-Test: remote_host: 158.36.191.193 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1696 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: freebsd-current@freebsd.org Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2010 14:32:46 -0000 On 2010-07-15 at 14:34, Ståle Kristoffersen wrote: > Upgraded to from stable to current yesterday and very quickly received a > panic. It did however not dump it's core, so I was unable to debug it. > Today it did panic again, and I took a picture: (Sorry about the bad > quality) > > http://folk.uio.no/stalk/mpt/IMG_1403.JPG > > And from the backtrace: > http://folk.uio.no/stalk/mpt/IMG_1404.JPG > > Both times I hade the mpt0: request timed out just before the panic. > > I'm not sure why it's not dumping it's core (It was working under stable, > and I have dumpdev="AUTO" and dumpdir="/var/crash" in rc.conf) Just to be complete: I also get this LOR at boot: lock order reversal: 1st 0xffffff80a5108b38 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2607 2nd 0xffffff0002dc6000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:283 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_remove() at ufsdirhash_remove+0x16 ufs_dirremove() at ufs_dirremove+0x1a4 ufs_remove() at ufs_remove+0x92 VOP_REMOVE_APV() at VOP_REMOVE_APV+0x93 kern_unlinkat() at kern_unlinkat+0x2cb syscallenter() at syscallenter+0x1b5 syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (10, FreeBSD ELF64, unlink), rip = 0x80072f3cc, rsp = 0x7fffffffdb08, rbp = 0x7fffffffef58 --- lock order reversal: 1st 0xffffff00407a4458 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1058 2nd 0xffffff00407aedb8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2090 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xd11 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b devfs_allocv() at devfs_allocv+0x100 devfs_root() at devfs_root+0x48 vfs_donmount() at vfs_donmount+0xfb2 nmount() at nmount+0x63 syscallenter() at syscallenter+0x1b5 syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007b2b4c, rsp = 0x7fffffffdd28, rbp = 0x800c09048 --- -- Ståle Kristoffersen From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 16:00:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB583106566C for ; Thu, 15 Jul 2010 16:00:50 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3DA158FC13 for ; Thu, 15 Jul 2010 16:00:49 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o6FG0m3N061986; Thu, 15 Jul 2010 18:00:48 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6FG0m8k061985; Thu, 15 Jul 2010 18:00:48 +0200 (CEST) (envelope-from marius) Date: Thu, 15 Jul 2010 18:00:48 +0200 From: Marius Strobl To: =?unknown-8bit?Q?St=E5le?= Kristoffersen Message-ID: <20100715160048.GA61891@alchemy.franken.de> References: <20100715123423.GC52222@putsch.kolbu.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100715123423.GC52222@putsch.kolbu.ws> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2010 16:00:50 -0000 On Thu, Jul 15, 2010 at 02:34:23PM +0200, Stle Kristoffersen wrote: > Upgraded to from stable to current yesterday and very quickly received a > panic. It did however not dump it's core, so I was unable to debug it. > Today it did panic again, and I took a picture: (Sorry about the bad > quality) > > http://folk.uio.no/stalk/mpt/IMG_1403.JPG > > And from the backtrace: > http://folk.uio.no/stalk/mpt/IMG_1404.JPG > > Both times I hade the mpt0: request timed out just before the panic. > > I'm not sure why it's not dumping it's core (It was working under stable, > and I have dumpdev="AUTO" and dumpdir="/var/crash" in rc.conf) What revision were you using? Does using current as of r209598 make a difference? Marius From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 17:47:05 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAC8E106564A; Thu, 15 Jul 2010 17:47:05 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 422168FC1E; Thu, 15 Jul 2010 17:47:04 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id AA6D29CB0AE; Thu, 15 Jul 2010 19:42:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvInjfnuTgnK; Thu, 15 Jul 2010 19:42:22 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 8D82C9CB720; Thu, 15 Jul 2010 19:42:22 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id o6FHgMTH079856; Thu, 15 Jul 2010 19:42:22 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 15 Jul 2010 19:42:22 +0200 From: Roman Divacky To: Ren? Ladan Message-ID: <20100715174222.GA79771@freebsd.org> References: <20100714183834.GA19684@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: [TESTING]: updated clang/LLVM needs testing in ClangBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2010 17:47:06 -0000 I updated clang/LLVM in clangbsd to a newer version which I believe will fix thas. can you rene (and everyone else) please retest with updated ClangBSD and report back? thank you! On Thu, Jul 15, 2010 at 01:33:04PM +0200, Ren? Ladan wrote: > 2010/7/14 Roman Divacky : > > hi, > > > > ClangBSD was updated to LLVM/clang revision r108243 which we plan to > > merge into HEAD. We would like that revision to be tested as much as possible > > and therefore we ask you to test ClangBSD to assure that the revision > > we are updating to does not have some really embarassing bugs. > > > > How to do it (on i386 and amd64): > > > > 0) install fresh devel/llvm-devel port > > > > 1) svn co http://svn.freebsd.org/base/projects/clangbsd src > > > > 2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf > > > > 3) cd src && make buildworld > > > And here my buildworld fails with: > > ===> lib/clang/libclanglex (depend) > tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include > -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include > -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex > -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include > -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic > -gen-clang-diags-defs -clang-component=Common > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td > > DiagnosticCommonKinds.inc.h > tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include > -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include > -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex > -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include > -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic > -gen-clang-diags-defs -clang-component=Lex > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td > > DiagnosticLexKinds.inc.h > rm -f .depend > CC='clang -isysroot /usr/obj/usr/home/rene/freebsd/clangbsd/tmp > -B/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/ > -L/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/' mkdep -f > .depend -a -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include > -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include > -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex > -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS > -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" > -DCLANG_VENDOR=\"FreeBSD\ \" -DSVN_REVISION=\"108243\" > -DCLANG_VENDOR_SUFFIX=\"\ 20100713\" > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/LiteralSupport.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroArgs.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroInfo.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPCaching.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPDirectives.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPExpressions.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPLexerChange.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPMacroExpansion.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PTHLexer.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Pragma.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessingRecord.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Preprocessor.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessorLexer.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/ScratchBuffer.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/TokenConcatenation.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/TokenLexer.cpp > /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:1110:10: > fatal error: > 'emmintrin.h' file not found > #include > ^ > 1 error generated. > mkdep: compile failed > *** Error code 1 > > Stop in /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex. > *** Error code 1 > > Stop in /usr/home/rene/freebsd/clangbsd/lib/clang. > *** Error code 1 > > Stop in /usr/home/rene/freebsd/clangbsd/lib. > *** Error code 1 > > Stop in /usr/home/rene/freebsd/clangbsd. > *** Error code 1 > > Stop in /usr/home/rene/freebsd/clangbsd. > *** Error code 1 > > Stop in /usr/home/rene/freebsd/clangbsd. > *** Error code 1 > > Stop in /usr/home/rene/freebsd/clangbsd. > > I do have CPUTYPE=nocona in /etc/make.conf, but apart from that /etc/make.conf > only contains port-related stuff. /etc/src.conf only contains the two > WERROR lines. > > acer# locate emmintrin.h > /usr/home/rene/freebsd/clangbsd/contrib/gcc/config/i386/.svn/prop-base/emmintrin.h.svn-base > /usr/home/rene/freebsd/clangbsd/contrib/gcc/config/i386/.svn/text-base/emmintrin.h.svn-base > /usr/home/rene/freebsd/clangbsd/contrib/gcc/config/i386/emmintrin.h > /usr/home/rene/freebsd/clangbsd/contrib/llvm/tools/clang/lib/Headers/.svn/text-base/emmintrin.h.svn-base > /usr/home/rene/freebsd/clangbsd/contrib/llvm/tools/clang/lib/Headers/emmintrin.h > /usr/include/clang/2.0/emmintrin.h > /usr/include/gcc/4.2/emmintrin.h > /usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd9.0/4.4.5/include/emmintrin.h > /usr/obj/usr/src/tmp/usr/include/clang/2.0/emmintrin.h > /usr/obj/usr/src/tmp/usr/include/gcc/4.2/emmintrin.h > acer# ls -l /usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/include/*/*/emmintrin.h > -rwxr-xr-x 1 root wheel 36913 Jul 15 11:24 > /usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/include/clang/2.8/emmintrin.h > -rwxr-xr-x 1 root wheel 42617 Oct 14 2009 > /usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/include/gcc/4.2/emmintrin.h > > acer# uname -a > FreeBSD acer 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r209980M: Tue Jul 13 > 11:48:03 CEST 2010 rene@acer:/usr/obj/usr/src/sys/GENERIC amd64 > > Regards, > Rene > _______________________________________________ > 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 Jul 15 18:03:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1634B1065670 for ; Thu, 15 Jul 2010 18:03:02 +0000 (UTC) (envelope-from staalebk@ifi.uio.no) Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by mx1.freebsd.org (Postfix) with ESMTP id BAA2D8FC21 for ; Thu, 15 Jul 2010 18:02:56 +0000 (UTC) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1OZSbi-0006YH-RK; Thu, 15 Jul 2010 19:52:26 +0200 Received: from putsch.kolbu.ws ([158.36.191.193]) by mail-mx1.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OZSbi-0007XW-BN; Thu, 15 Jul 2010 19:52:26 +0200 Received: from chiller by putsch.kolbu.ws with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OZSbh-000EJV-Tf; Thu, 15 Jul 2010 19:52:25 +0200 Date: Thu, 15 Jul 2010 19:52:25 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Marius Strobl Message-ID: <20100715175225.GA52693@putsch.kolbu.ws> References: <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100715160048.GA61891@alchemy.franken.de> User-Agent: Mutt/1.5.18 (2008-05-17) X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 68 max rcpts/h 13 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0CF8773B64956FDFD4A8916EF8859904BD0F8066 X-UiO-SPAM-Test: remote_host: 158.36.191.193 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1697 max/h 11 blacklist 0 greylist 0 ratelimit 0 X-Mailman-Approved-At: Thu, 15 Jul 2010 18:40:42 +0000 Cc: freebsd-current@freebsd.org, =?iso-8859-1?Q?St=E5le?= Kristoffersen Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2010 18:03:02 -0000 On 2010-07-15 at 18:00, Marius Strobl wrote: > On Thu, Jul 15, 2010 at 02:34:23PM +0200, Stle Kristoffersen wrote: > > Upgraded to from stable to current yesterday and very quickly received a > > panic. It did however not dump it's core, so I was unable to debug it. > > Today it did panic again, and I took a picture: (Sorry about the bad > > quality) > > > > http://folk.uio.no/stalk/mpt/IMG_1403.JPG > > > > And from the backtrace: > > http://folk.uio.no/stalk/mpt/IMG_1404.JPG > > > > Both times I hade the mpt0: request timed out just before the panic. > > > > I'm not sure why it's not dumping it's core (It was working under stable, > > and I have dumpdev="AUTO" and dumpdir="/var/crash" in rc.conf) > > What revision were you using? Not sure exactly what revision I was using, is there an easy way to figure that out? I ran cvsupdate around 13:00 CEST yesterday. > Does using current as of r209598 make a difference? Downgrading now... -- Ståle Kristoffersen staalebk@ifi.uio.no From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 22:07:31 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2FF01065676 for ; Thu, 15 Jul 2010 22:07:31 +0000 (UTC) (envelope-from philip@taximagic.com) Received: from exhub015-2.exch015.msoutlookonline.net (exhub015-2.exch015.msoutlookonline.net [207.5.72.94]) by mx1.freebsd.org (Postfix) with ESMTP id C17748FC22 for ; Thu, 15 Jul 2010 22:07:31 +0000 (UTC) Received: from [192.168.1.3] (71.246.240.70) by smtpx15.msoutlookonline.net (207.5.72.103) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 15 Jul 2010 14:57:26 -0700 Message-ID: <4C3F8442.6070809@ridecharge.com> Date: Thu, 15 Jul 2010 17:57:22 -0400 From: "Philip M. Gollucci" Organization: RideCharge Inc, TaxiMagic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 15 Jul 2010 22:49:42 +0000 Cc: Subject: can't checkout svn on cygwin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2010 22:07:31 -0000 ssA and ssa conflict $ ~/repos/fbsd/base/head/share/doc/psd> svn up A 15.yacc A 15.yacc/ss.. A 15.yacc/ssA A 15.yacc/ssa A 15.yacc/ssb A 15.yacc/ssB A 15.yacc/ssc A 15.yacc/ssd A 15.yacc/ss0 A 15.yacc/ss1 A 15.yacc/ref.bib A 15.yacc/ss2 A 15.yacc/ss3 A 15.yacc/ss4 A 15.yacc/ss5 A 15.yacc/ss6 A 15.yacc/ss7 A 15.yacc/ss8 A 15.yacc/Makefile A 15.yacc/ss9 svn: In directory '15.yacc' svn: Can't open file '15.yacc/.svn/tmp/text-base/ssa.svn-base': No such file or directory -- ------------------------------------------------------------------------ Philip M. Gollucci (pgollucci@ridecharge.com) p: 703.549.2050x206, did: 703.579.6947 Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 23:17:54 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A44FA1065672 for ; Thu, 15 Jul 2010 23:17:54 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 573858FC0C for ; Thu, 15 Jul 2010 23:17:53 +0000 (UTC) Received: by qwg5 with SMTP id 5so484189qwg.13 for ; Thu, 15 Jul 2010 16:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=NZmRN4Oc1xmDATFFoKP7Sl+4LffFE82K3PBJATIXT4s=; b=VkRCzKRYlTU89FIH0ZVg1ony7c/yW3AF2ddFAxh/0jRiOy3ZEziI6r/Aahz9MPeX/8 lbNXmTsm/5+gHGr1hpiiFQfaAyZnROcGfb3ql0XQGNhTu8cpj+PncgN6dcFUYbix8b6A kjgQ6MzpYRNp5TE0bJYNLmwejzzRXFtQyOgXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=jvwHnE6pVmgNzR7nlhfxbQVJR8/+iLpa3Ld3ZbrBFAX2zdYOsicViAEUFIQa3oyy0W c7+sAIWLNwC9SBoRCb0Vfmbcj2vkxZKp3VEuUPqTr68dVe29/bFPXdasFDYqSplJeGW1 F0zSG0XvZCMYAeyREhvsbB2FLGVx5muk/u4zE= Received: by 10.224.89.11 with SMTP id c11mr173949qam.182.1279235872688; Thu, 15 Jul 2010 16:17:52 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id h41sm6945231qcz.1.2010.07.15.16.17.51 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 16:17:51 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C3F971E.5000001@dataix.net> Date: Thu, 15 Jul 2010 19:17:50 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: "Philip M. Gollucci" References: <4C3F8442.6070809@ridecharge.com> In-Reply-To: <4C3F8442.6070809@ridecharge.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: can't checkout svn on cygwin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2010 23:17:54 -0000 On 07/15/2010 17:57, Philip M. Gollucci wrote: > ssA and ssa conflict > > > > $ ~/repos/fbsd/base/head/share/doc/psd> svn up > A 15.yacc > A 15.yacc/ss.. > A 15.yacc/ssA > A 15.yacc/ssa > A 15.yacc/ssb > A 15.yacc/ssB > A 15.yacc/ssc > A 15.yacc/ssd > A 15.yacc/ss0 > A 15.yacc/ss1 > A 15.yacc/ref.bib > A 15.yacc/ss2 > A 15.yacc/ss3 > A 15.yacc/ss4 > A 15.yacc/ss5 > A 15.yacc/ss6 > A 15.yacc/ss7 > A 15.yacc/ss8 > A 15.yacc/Makefile > A 15.yacc/ss9 > svn: In directory '15.yacc' > svn: Can't open file '15.yacc/.svn/tmp/text-base/ssa.svn-base': No such > file or directory > Looks to be a problem with your local .svn directory. Run the following in the psd directory. rm -rf 15.yacc svn update This should fix it up for whatever happened. If not then backup one directory rm that directory and repeat. The base repository is clean. Regards, -- jhell,v From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 00:08:38 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D111065675 for ; Fri, 16 Jul 2010 00:08:38 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8BFCB8FC1C for ; Fri, 16 Jul 2010 00:08:38 +0000 (UTC) Received: by gxk24 with SMTP id 24so1220436gxk.13 for ; Thu, 15 Jul 2010 17:08:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.4 with SMTP id f4mr759459ybe.79.1279238916829; Thu, 15 Jul 2010 17:08:36 -0700 (PDT) Received: by 10.151.109.4 with HTTP; Thu, 15 Jul 2010 17:08:36 -0700 (PDT) X-Originating-IP: [71.1.132.95] Date: Thu, 15 Jul 2010 17:08:36 -0700 Message-ID: From: Rob Farmer To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Clock not moving in virtual machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 00:08:39 -0000 Hi, I have a VPS from rootbsd.net which is running current, though I don't update it very often. I just built and installed a new world and kernel and now the clock will not move from the time the system was booted, ie: # date Thu Jul 15 16:15:58 PDT 2010 # date Thu Jul 15 16:15:58 PDT 2010 I have an old kernel from May 27 which doesn't have this problem. I noticed some clock related stuff changing in current in the last couple of weeks and suspect that their VM setup doesn't play well with these changes (their site says they use Xen, but several boot messages refer to QEMU). Officially, I think they only support running 8.0 so I thought I would ask here if anyone has any ideas before putting in a support request. Here's a diff of the dmesgs - I can post full copies if needed but didn't want to start with a ridicously long message: --- dmesg.old 2010-07-15 17:45:20.000000000 -0700 +++ dmesg.new 2010-07-15 17:46:45.000000000 -0700 @@ -2,10 +2,9 @@ Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. -FreeBSD 9.0-CURRENT #0: Thu May 27 01:26:08 PDT 2010 +FreeBSD 9.0-CURRENT #0: Thu Jul 15 16:13:28 PDT 2010 rfarmer@peridot.predatorlabs.net:/usr/obj/usr/src/sys/PERIDOT i386 -Timecounter "i8254" frequency 1193182 Hz quality 0 -CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2261.02-MHz 686-class CPU) +CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2261.59-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0x1781fbff Features2=0x80182201> @@ -13,9 +12,10 @@ AMD Features2=0x1 TSC: P-state invariant real memory = 268435456 (256 MB) -avail memory = 252473344 (240 MB) -ACPI Error: A valid RSDP was not found (20100428/tbxfroot-309) +avail memory = 252444672 (240 MB) +ACPI Error: A valid RSDP was not found (20100702/tbxfroot-309) MPTable: <_HVMCPU_ XEN > +Event timer "LAPIC" frequency 0 Hz quality 500 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 0 package(s) x 16 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 @@ -26,7 +26,7 @@ ioapic0: Assuming intbase of 0 ioapic0 irqs 0-47 on motherboard kbd1 at kbdmux0 -ACPI Error: A valid RSDP was not found (20100428/tbxfroot-309) +ACPI Error: A valid RSDP was not found (20100702/tbxfroot-309) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. pcib0: pcibus 0 on motherboard @@ -81,7 +81,10 @@ ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 -atrtc0: at port 0x70 irq 8 on isa0 +atrtc0: at port 0x70 irq 8 on isa0 +atrtc0: [FILTER] +Event timer "RTC" frequency 32768 Hz quality 0 +Starting kernel event timers: LAPIC @ 200Hz, RTC @ 128Hz Timecounters tick every 5.000 msec ad0: 10240MB at ata0-master WDMA2 SMP: AP CPU #1 Launched! Thanks, -- Rob Farmer From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 00:35:32 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BB32106566C for ; Fri, 16 Jul 2010 00:35:32 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id BB7768FC08 for ; Fri, 16 Jul 2010 00:35:31 +0000 (UTC) Received: by gyd8 with SMTP id 8so1222006gyd.13 for ; Thu, 15 Jul 2010 17:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=u0jI4bAVeRAnp+QqLFrq9k+RoJFZpD+XEBqLY6QdCOY=; b=n1r4e/mYyW1kS0TgMlA1c+LrXkiO9tfHV8NtCDa8KR0w6KF0dFtnTbmZN/SZMNr8hd xe/os9hM4SZsilyP+hasonm6JLHCV65nUEe2Q9FJKADNmhjvnvna7/cgMUfz077beR2p 4TflKeOx+3GVMAqrFmwjSTHh5dUe7IHTZq9DY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=kGyO0c2hy7TUv9h4Gy/D4+SBOHzENbB+2PxuLa6w5LkaJoYxbz8QwjU0MEt97mpsIo bXzl5nsvOpQgapUyhg9hZTYg5GxIxkZLSEPogDCKYlx9NlOxHQZV4P/PwH0mLnDt4agW Ey5UoQpEFofESlV4AsB2C0HG4IJDP1gQhoBhs= Received: by 10.101.153.29 with SMTP id f29mr477934ano.114.1279240530463; Thu, 15 Jul 2010 17:35:30 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id r7sm17728220anb.35.2010.07.15.17.35.29 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 17:35:29 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C3FA950.2050905@dataix.net> Date: Thu, 15 Jul 2010 20:35:28 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: "Philip M. Gollucci" References: <4C3F8442.6070809@ridecharge.com> <4C3F971E.5000001@dataix.net> <4C3FA34C.9080804@ridecharge.com> In-Reply-To: <4C3FA34C.9080804@ridecharge.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Philip M. Gollucci" , "current@freebsd.org" Subject: Re: can't checkout svn on cygwin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 00:35:32 -0000 On 07/15/2010 20:09, Philip M. Gollucci wrote: > On 7/15/2010 7:17 PM, jhell wrote: >> >> Looks to be a problem with your local .svn directory. >> >> Run the following in the psd directory. >> rm -rf 15.yacc >> svn update >> >> This should fix it up for whatever happened. If not then backup one >> directory rm that directory and repeat. > I did this long before I sent the e-mail. > > Makes no difference. > How far up the tree did you go back ? Example: cd ../ rm -rf ./* svn update My guess is that this has perpetuated all the way to the root of checkout and it might just be best to checkout the entire source once more. As more information. I can checkout that part of the tree and the entire contents for each one of the directories and there was no problem. have you run svn cleanup ? -- jhell,v From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 00:57:47 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5045F1065670 for ; Fri, 16 Jul 2010 00:57:47 +0000 (UTC) (envelope-from pgollucci@p6m7g8.com) Received: from EXHUB015-3.exch015.msoutlookonline.net (exhub015-3.exch015.msoutlookonline.net [207.5.72.95]) by mx1.freebsd.org (Postfix) with ESMTP id 374A08FC18 for ; Fri, 16 Jul 2010 00:57:46 +0000 (UTC) Received: from [192.168.1.3] (71.246.240.70) by smtpx15.msoutlookonline.net (207.5.72.103) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 15 Jul 2010 17:57:46 -0700 Message-ID: <4C3FAE83.8010702@p6m7g8.com> Date: Thu, 15 Jul 2010 20:57:39 -0400 From: "Philip M. Gollucci" Organization: P6M7G8 Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: jhell References: <4C3F8442.6070809@ridecharge.com> <4C3F971E.5000001@dataix.net> <4C3FA34C.9080804@ridecharge.com> <4C3FA950.2050905@dataix.net> In-Reply-To: <4C3FA950.2050905@dataix.net> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig87E2A0A6C505E221D0ACD0EC" Cc: "Philip M. Gollucci" , "current@freebsd.org" Subject: Re: can't checkout svn on cygwin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 00:57:47 -0000 --------------enig87E2A0A6C505E221D0ACD0EC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/15/2010 8:35 PM, jhell wrote: > How far up the tree did you go back ? The whole way, and I've re-checked out the whole tree again. > As more information. I can checkout that part of the tree and the entir= e > contents for each one of the directories and there was no problem. Are you doing this on a cygwin install on vista ? It works fine on *Unix > have you run svn cleanup ? of course Lets pretend I'm one of the admins of svn.apache.org -- I know how to use svn. --=20 ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. --------------enig87E2A0A6C505E221D0ACD0EC 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.10 (MingW32) iEUEARECAAYFAkw/roUACgkQdbiP+9ubjBwZxQCfY0WxB+uIjC+ixaqJLEcti7lH 8gEAl3Su2M3ITx2mPxJwKYSVhMO4vZQ= =xfIC -----END PGP SIGNATURE----- --------------enig87E2A0A6C505E221D0ACD0EC-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 01:57:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73EDC106566B for ; Fri, 16 Jul 2010 01:57:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 514BA8FC14 for ; Fri, 16 Jul 2010 01:57:06 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o6G1v1ub012782; Thu, 15 Jul 2010 18:57:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o6G1uxex012781; Thu, 15 Jul 2010 18:56:59 -0700 (PDT) (envelope-from sgk) Date: Thu, 15 Jul 2010 18:56:59 -0700 From: Steve Kargl To: "Philip M. Gollucci" Message-ID: <20100716015659.GA12758@troutmask.apl.washington.edu> References: <4C3F8442.6070809@ridecharge.com> <4C3F971E.5000001@dataix.net> <4C3FA34C.9080804@ridecharge.com> <4C3FA950.2050905@dataix.net> <4C3FAE83.8010702@p6m7g8.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C3FAE83.8010702@p6m7g8.com> User-Agent: Mutt/1.4.2.3i Cc: "Philip M. Gollucci" , "current@freebsd.org" Subject: Re: can't checkout svn on cygwin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 01:57:06 -0000 On Thu, Jul 15, 2010 at 08:57:39PM -0400, Philip M. Gollucci wrote: > On 7/15/2010 8:35 PM, jhell wrote: > > How far up the tree did you go back ? > The whole way, and I've re-checked out the whole tree again. > > > As more information. I can checkout that part of the tree and the entire > > contents for each one of the directories and there was no problem. > Are you doing this on a cygwin install on vista ? > It works fine on *Unix > Then, it's not a FreeBSD problem. Try asking microsoft and the cygwin developers for help. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 01:58:56 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F0DD1065670 for ; Fri, 16 Jul 2010 01:58:56 +0000 (UTC) (envelope-from pgollucci@p6m7g8.com) Received: from EXHUB015-3.exch015.msoutlookonline.net (exhub015-3.exch015.msoutlookonline.net [207.5.72.95]) by mx1.freebsd.org (Postfix) with ESMTP id E82438FC1B for ; Fri, 16 Jul 2010 01:58:55 +0000 (UTC) Received: from [192.168.1.3] (71.246.240.70) by smtpx15.msoutlookonline.net (207.5.72.103) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 15 Jul 2010 18:58:54 -0700 Message-ID: <4C3FBCD8.5080507@p6m7g8.com> Date: Thu, 15 Jul 2010 21:58:48 -0400 From: "Philip M. Gollucci" Organization: P6M7G8 Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Steve Kargl References: <4C3F8442.6070809@ridecharge.com> <4C3F971E.5000001@dataix.net> <4C3FA34C.9080804@ridecharge.com> <4C3FA950.2050905@dataix.net> <4C3FAE83.8010702@p6m7g8.com> <20100716015659.GA12758@troutmask.apl.washington.edu> In-Reply-To: <20100716015659.GA12758@troutmask.apl.washington.edu> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEC1D689FA2D01684637D7B4C" Cc: "Philip M. Gollucci" , "current@freebsd.org" Subject: Re: can't checkout svn on cygwin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 01:58:56 -0000 --------------enigEC1D689FA2D01684637D7B4C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/15/2010 9:56 PM, Steve Kargl wrote: > Then, it's not a FreeBSD problem. Try asking microsoft > and the cygwin developers for help. I didn't say it was a freebsd problem. I know there have been time in the past where we try to keep this working on Case Insensitive systems. --=20 ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. --------------enigEC1D689FA2D01684637D7B4C 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.10 (MingW32) iEYEARECAAYFAkw/vNoACgkQdbiP+9ubjBwKBgCfUX983/MOqM1zUh6Y0t4WGZ3R /SgAniiCZxi+txiTZhIIP7Ss/9UA6gR8 =T/Ka -----END PGP SIGNATURE----- --------------enigEC1D689FA2D01684637D7B4C-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 01:59:35 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D52EF1065679 for ; Fri, 16 Jul 2010 01:59:35 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.162]) by mx1.freebsd.org (Postfix) with ESMTP id 728AC8FC17 for ; Fri, 16 Jul 2010 01:59:35 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Thu, 15 Jul 2010 21:59:25 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 628D333C00; Thu, 15 Jul 2010 21:59:34 -0400 (EDT) Date: Thu, 15 Jul 2010 21:59:34 -0400 From: Ed Maste To: "Philip M. Gollucci" Message-ID: <20100716015934.GA72850@sandvine.com> Mail-Followup-To: Ed Maste , "Philip M. Gollucci" , current@freebsd.org References: <4C3F8442.6070809@ridecharge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4C3F8442.6070809@ridecharge.com> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: can't checkout svn on cygwin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 01:59:35 -0000 On Thu, Jul 15, 2010 at 05:57:22PM -0400, Philip M. Gollucci wrote: > ssA and ssa conflict Yeah, there used to be at least 7 examples of files differing only in case in our repository. Several of these have been fixed but it looks like there's still the following: share/doc/psd/15.yacc/ssa share/doc/psd/15.yacc/ssA share/doc/psd/15.yacc/ssb share/doc/psd/15.yacc/ssB share/man/man9/vfs_mount.9 share/man/man9/VFS_MOUNT.9 For the first two I'd propose renaming ss.. to ss_, ssA to ss10 and ssB to ss11. Index: Makefile =================================================================== --- Makefile (revision 210153) +++ Makefile (working copy) @@ -2,8 +2,8 @@ # $FreeBSD$ VOLUME= psd/15.yacc -SRCS= stubs ss.. ss0 ss1 ss2 ss3 ss4 ss5 ss6 ss7 ss8 ss9 \ - ssA ssB ssa ssb ssc ssd +SRCS= stubs ss_ ss0 ss1 ss2 ss3 ss4 ss5 ss6 ss7 ss8 ss9 \ + ss10 ss11 ssa ssb ssc ssd EXTRA= ref.bib MACROS= -ms USE_REFER= I'm not sure if there's an easy way to deal with vfs_mount.9 vs VFS_MOUNT.9 though. -Ed From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 03:12:17 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0B7A106566C for ; Fri, 16 Jul 2010 03:12:17 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id B29118FC15 for ; Fri, 16 Jul 2010 03:12:17 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o6G3CF89064484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Jul 2010 22:12:16 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id o6G3CFUm018950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Jul 2010 22:12:15 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o6G3CBZ3018941; Thu, 15 Jul 2010 22:12:11 -0500 (CDT) (envelope-from dan) Date: Thu, 15 Jul 2010 22:12:11 -0500 From: Dan Nelson To: "Philip M. Gollucci" Message-ID: <20100716031211.GE5485@dan.emsphone.com> References: <4C3F8442.6070809@ridecharge.com> <4C3F971E.5000001@dataix.net> <4C3FA34C.9080804@ridecharge.com> <4C3FA950.2050905@dataix.net> <4C3FAE83.8010702@p6m7g8.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C3FAE83.8010702@p6m7g8.com> X-OS: FreeBSD 8.1-PRERELEASE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Thu, 15 Jul 2010 22:12:16 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: "Philip M. Gollucci" , "current@freebsd.org" Subject: Re: can't checkout svn on cygwin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 03:12:18 -0000 In the last episode (Jul 15), Philip M. Gollucci said: > On 7/15/2010 8:35 PM, jhell wrote: > > How far up the tree did you go back ? > The whole way, and I've re-checked out the whole tree again. > > > As more information. I can checkout that part of the tree and the entire > > contents for each one of the directories and there was no problem. > Are you doing this on a cygwin install on vista ? > It works fine on *Unix > > > have you run svn cleanup ? > of course > > Lets pretend I'm one of the admins of svn.apache.org -- I know how to > use svn. Until the offending files get fixed, you can try enabling NTFS case sensitivity on your Windows system: http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 03:47:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD4D81065672; Fri, 16 Jul 2010 03:47:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 612058FC08; Fri, 16 Jul 2010 03:47:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o6G3lsSv089985; Thu, 15 Jul 2010 23:47:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o6G3lsqW089969; Fri, 16 Jul 2010 03:47:54 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 16 Jul 2010 03:47:54 GMT Message-Id: <201007160347.o6G3lsqW089969@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips 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, 16 Jul 2010 03:47:55 -0000 TB --- 2010-07-16 03:20:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-16 03:20:35 - starting HEAD tinderbox run for mips/mips TB --- 2010-07-16 03:20:35 - cleaning the object tree TB --- 2010-07-16 03:20:35 - cvsupping the source tree TB --- 2010-07-16 03:20:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-07-16 03:21:09 - building world TB --- 2010-07-16 03:21:09 - MAKEOBJDIRPREFIX=/obj TB --- 2010-07-16 03:21:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-07-16 03:21:09 - TARGET=mips TB --- 2010-07-16 03:21:09 - TARGET_ARCH=mips TB --- 2010-07-16 03:21:09 - TZ=UTC TB --- 2010-07-16 03:21:09 - __MAKE_CONF=/dev/null TB --- 2010-07-16 03:21:09 - cd /src TB --- 2010-07-16 03:21:09 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 16 03:21:10 UTC 2010 >>> 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 [...] ===> lib/libalias/modules/cuseeme (all) cc -O -pipe -EL -G0 -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -c /src/lib/libalias/modules/cuseeme/../../../../sys/netinet/libalias/alias_cuseeme.c cc1: warnings being treated as errors In file included from /src/lib/libalias/modules/cuseeme/../../../../sys/netinet/libalias/alias_sctp.h:83, from /src/lib/libalias/modules/cuseeme/../../../../sys/netinet/libalias/alias_local.h:63, from /src/lib/libalias/modules/cuseeme/../../../../sys/netinet/libalias/alias_cuseeme.c:52: /obj/mips.mips/src/tmp/usr/include/machine/cpu.h: In function 'get_cyclecount': /obj/mips.mips/src/tmp/usr/include/machine/cpu.h:84: warning: implicit declaration of function 'mips_rd_count' *** Error code 1 Stop in /src/lib/libalias/modules/cuseeme. *** Error code 1 Stop in /src/lib/libalias/modules. *** Error code 1 Stop in /src/lib/libalias. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-07-16 03:47:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-07-16 03:47:54 - ERROR: failed to build world TB --- 2010-07-16 03:47:54 - 1129.48 user 289.05 system 1638.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 00:09:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09F481065673 for ; Fri, 16 Jul 2010 00:09:55 +0000 (UTC) (envelope-from philip@taximagic.com) Received: from exhub015-2.exch015.msoutlookonline.net (exhub015-2.exch015.msoutlookonline.net [207.5.72.94]) by mx1.freebsd.org (Postfix) with ESMTP id EADE08FC1C for ; Fri, 16 Jul 2010 00:09:53 +0000 (UTC) Received: from [192.168.1.3] (71.246.240.70) by smtpx15.msoutlookonline.net (207.5.72.103) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 15 Jul 2010 17:09:52 -0700 Message-ID: <4C3FA34C.9080804@ridecharge.com> Date: Thu, 15 Jul 2010 20:09:48 -0400 From: "Philip M. Gollucci" Organization: RideCharge Inc, TaxiMagic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: jhell References: <4C3F8442.6070809@ridecharge.com> <4C3F971E.5000001@dataix.net> In-Reply-To: <4C3F971E.5000001@dataix.net> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Jul 2010 05:16:13 +0000 Cc: "Philip M. Gollucci" , "current@freebsd.org" Subject: Re: can't checkout svn on cygwin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 00:09:55 -0000 On 7/15/2010 7:17 PM, jhell wrote: > > Looks to be a problem with your local .svn directory. > > Run the following in the psd directory. > rm -rf 15.yacc > svn update > > This should fix it up for whatever happened. If not then backup one > directory rm that directory and repeat. I did this long before I sent the e-mail. Makes no difference. -- ------------------------------------------------------------------------ Philip M. Gollucci (pgollucci@ridecharge.com) p: 703.549.2050x206, did: 703.579.6947 Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 06:34:41 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36FA81065672 for ; Fri, 16 Jul 2010 06:34:41 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id B7F6D8FC0A for ; Fri, 16 Jul 2010 06:34:40 +0000 (UTC) Received: by fxm13 with SMTP id 13so936129fxm.13 for ; Thu, 15 Jul 2010 23:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=EBu+sdS9wVg03SJ1CR1txDgs0iryvhRmFRl8do+gPkA=; b=Hq+Zp+7j0m8g2el7Yosg7Wp3m6jV8JDl/0RMfRRBTiOYJQj574u6dFuel6YXQWZFbV vSUiYfSgqXzNAqRs+1/EdkghuuBhSCAiBYa2WdkqQPIBgidvbRCi3VtMVkTqI5xxiBvu 0awrbcqc8v2m8P3Nt+0lHzqQheOOHwA7RnWBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=GdEcXhW7s+d2GP6/X13DAO0thzsrnvdpNQV9aGeWmA/lI5Jcm0c5SjMa/uf/mgOTkR o2Dqvuoopqwo/3qy848HcXvYpUe1sqtPR1hSFd07HhL20o5qsW3oYwmST+a/TBkh8U9A wbPG+uTnc+bZVR+G0zc4m5Z/KQKmS4wDAQ+p8= Received: by 10.223.107.137 with SMTP id b9mr276006fap.17.1279262079599; Thu, 15 Jul 2010 23:34:39 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id a9sm633725faa.27.2010.07.15.23.34.38 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 23:34:38 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C3FFD3F.7060909@FreeBSD.org> Date: Fri, 16 Jul 2010 09:33:35 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Rob Farmer , current References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Clock not moving in virtual machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 06:34:41 -0000 Rob Farmer wrote: > I have a VPS from rootbsd.net which is running current, though I don't > update it very often. I just built and installed a new world and > kernel and now the clock will not move from the time the system was > booted, ie: > # date > Thu Jul 15 16:15:58 PDT 2010 > > # date > Thu Jul 15 16:15:58 PDT 2010 > > I have an old kernel from May 27 which doesn't have this problem. I > noticed some clock related stuff changing in current in the last > couple of weeks and suspect that their VM setup doesn't play well with > these changes (their site says they use Xen, but several boot messages > refer to QEMU). Officially, I think they only support running 8.0 so I > thought I would ask here if anyone has any ideas before putting in a > support request. > > Here's a diff of the dmesgs - I can post full copies if needed but > didn't want to start with a ridicously long message: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 0 package(s) x 16 core(s) x 2 SMT threads > cpu0 (BSP): APIC ID: 0 Probably not related, but funny. :) So you have two CPUs? > @@ -81,7 +81,10 @@ > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppc0: [ITHREAD] > ppbus0: on ppc0 > -atrtc0: at port 0x70 irq 8 on isa0 > +atrtc0: at port 0x70 irq 8 on isa0 > +atrtc0: [FILTER] > +Event timer "RTC" frequency 32768 Hz quality 0 > +Starting kernel event timers: LAPIC @ 200Hz, RTC @ 128Hz > Timecounters tick every 5.000 msec Everything seems reasonable there. Try to collect more information: sysctl kern.timecounter sysctl kern.eventtimer vmstat -ia systat -vm 1 (presence and frequencies of interrupts) It could be a bug in emulation of some timers or bug in respective timer driver, which was not triggered before last changes. You may try switch to different timecounter by setting kern.timecounter.hardware, or different eventtimers by setting kern.eventtimer.timer1 and kern.eventtimer.timer2 sysctls. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 07:48:31 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 043A81065680 for ; Fri, 16 Jul 2010 07:48:31 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A8E0C8FC19 for ; Fri, 16 Jul 2010 07:48:30 +0000 (UTC) Received: by vws19 with SMTP id 19so2725222vws.13 for ; Fri, 16 Jul 2010 00:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=M1GJJGaD/QsM34UeBbWbDtJEwqpPmAB5ylIVndFVidI=; b=EMI49VbOwVj/fmdIrEepdqjmn1PUTXj2ZB/TsS+wNewFvyjxX5Xr1qVFrB7tJAd7Nd iVDSLgKVk2Bpkc+v0hreCbfTRJd8U3mRjEyt9a+VHl3IiivAxOvJ5zHOti/bu6wwuNVI sRCLx8gQQjLe+lLeDMtkWcIHsm2DqnAIJgcRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X7KZ8d0RTIC4/bfdg9naCPHzsmgDjTudcHT8TUTh52R6KlIkST/ob3zEI8o8HK3bfK mr5mt3VpPYUrjWR9AvaGpeT4P0PsyRrImrubnu0Q7fpnLLi+HLWFvFIo2/TheSBsi5GU ZePjPXa3n0Uzirk8hQlGSswnpB8/Y3pBToV3E= MIME-Version: 1.0 Received: by 10.224.65.147 with SMTP id j19mr581948qai.189.1279264828317; Fri, 16 Jul 2010 00:20:28 -0700 (PDT) Received: by 10.229.239.129 with HTTP; Fri, 16 Jul 2010 00:20:28 -0700 (PDT) In-Reply-To: <20100716031211.GE5485@dan.emsphone.com> References: <4C3F8442.6070809@ridecharge.com> <4C3F971E.5000001@dataix.net> <4C3FA34C.9080804@ridecharge.com> <4C3FA950.2050905@dataix.net> <4C3FAE83.8010702@p6m7g8.com> <20100716031211.GE5485@dan.emsphone.com> Date: Fri, 16 Jul 2010 15:20:28 +0800 Message-ID: From: Jiawei Ye To: Dan Nelson Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Philip M. Gollucci" , "Philip M. Gollucci" , "current@freebsd.org" Subject: Re: can't checkout svn on cygwin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 07:48:31 -0000 On Fri, Jul 16, 2010 at 11:12 AM, Dan Nelson wrote: > > Are you doing this on a cygwin install on vista ? > > It works fine on *Unix > > > > > have you run svn cleanup ? > > of course > > > > Lets pretend I'm one of the admins of svn.apache.org -- I know how to > > use svn. > > Until the offending files get fixed, you can try enabling NTFS case > sensitivity on your Windows system: > > http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive > > I got bitten by the same thing a while ago and I was working on OS/X. So it is indeed the case-sensitivity issue. CW -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 10:31:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B639D106566B for ; Fri, 16 Jul 2010 10:31:28 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from mail-forward.uio.no (mail-forward.uio.no [129.240.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6A1C38FC0A for ; Fri, 16 Jul 2010 10:31:28 +0000 (UTC) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1OZiCU-0008HE-Tj; Fri, 16 Jul 2010 12:31:26 +0200 Received: from putsch.kolbu.ws ([158.36.191.193]) by mail-mx4.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OZiCU-00043M-GU; Fri, 16 Jul 2010 12:31:26 +0200 Received: from chiller by putsch.kolbu.ws with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OZiCU-0008LE-2R; Fri, 16 Jul 2010 12:31:26 +0200 Date: Fri, 16 Jul 2010 12:31:26 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Marius Strobl Message-ID: <20100716103125.GA73878@putsch.kolbu.ws> References: <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> <20100715175225.GA52693@putsch.kolbu.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100715175225.GA52693@putsch.kolbu.ws> User-Agent: Mutt/1.5.18 (2008-05-17) X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 91DCF0E571BFB92A0E5EF84955B2750F59B598DF X-UiO-SPAM-Test: remote_host: 158.36.191.193 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1710 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: freebsd-current@freebsd.org, =?iso-8859-1?Q?St=E5le?= Kristoffersen Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 10:31:28 -0000 On 2010-07-15 at 19:52, Ståle Kristoffersen wrote: > On 2010-07-15 at 18:00, Marius Strobl wrote: > > On Thu, Jul 15, 2010 at 02:34:23PM +0200, Stle Kristoffersen wrote: > > > Upgraded to from stable to current yesterday and very quickly received a > > > panic. It did however not dump it's core, so I was unable to debug it. > > > Today it did panic again, and I took a picture: (Sorry about the bad > > > quality) > > > > > > http://folk.uio.no/stalk/mpt/IMG_1403.JPG > > > > > > And from the backtrace: > > > http://folk.uio.no/stalk/mpt/IMG_1404.JPG > > > > > > Both times I hade the mpt0: request timed out just before the panic. > > > > > > I'm not sure why it's not dumping it's core (It was working under stable, > > > and I have dumpdev="AUTO" and dumpdir="/var/crash" in rc.conf) > > > > What revision were you using? > > Not sure exactly what revision I was using, is there an easy way to figure > that out? I ran cvsupdate around 13:00 CEST yesterday. > > > Does using current as of r209598 make a difference? > > Downgrading now... And it crashed again, with current from r209598... -- Ståle Kristoffersen From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 13:58:40 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A982D1065673 for ; Fri, 16 Jul 2010 13:58:40 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 66FCD8FC0C for ; Fri, 16 Jul 2010 13:58:40 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 9AAAA14D8181 for ; Fri, 16 Jul 2010 15:58:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qoxTULS2YCSe for ; Fri, 16 Jul 2010 15:58:35 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 7AA8E14D2C9B for ; Fri, 16 Jul 2010 15:58:35 +0200 (CEST) Message-ID: <4C406589.7030705@FreeBSD.org> Date: Fri, 16 Jul 2010 15:58:33 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: periodic script in base system to run csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 13:58:40 -0000 Hi folks, Steven Kreuzer wrote a periodic script to run csup updates with periodic daily. I've reviewed it and added support for multiple supfiles. I'd like to commit this to head. http://kovesdan.org/files/600.csup Is there any objection? Gabor From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 14:15:28 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5FF51065672; Fri, 16 Jul 2010 14:15:28 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 9F31C8FC1A; Fri, 16 Jul 2010 14:15:28 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 818B31DD65C; Fri, 16 Jul 2010 16:15:27 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 75AC0172E3; Fri, 16 Jul 2010 16:15:27 +0200 (CEST) Date: Fri, 16 Jul 2010 16:15:27 +0200 From: Jilles Tjoelker To: Gabor Kovesdan Message-ID: <20100716141527.GA83410@stack.nl> References: <4C406589.7030705@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C406589.7030705@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: periodic script in base system to run csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 14:15:28 -0000 On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: > Steven Kreuzer wrote a periodic script to run csup updates with periodic > daily. I've reviewed it and added support for multiple supfiles. I'd > like to commit this to head. > http://kovesdan.org/files/600.csup > Is there any objection? Hmm, /usr/src/Makefile has an 'update' target that can run csup and other updating tools. Perhaps it should call that instead? -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 14:24:57 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D27A91065670 for ; Fri, 16 Jul 2010 14:24:57 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from hosting.nash.net.ua (hosting.nash.net.ua [193.151.252.10]) by mx1.freebsd.org (Postfix) with SMTP id 6592B8FC12 for ; Fri, 16 Jul 2010 14:24:55 +0000 (UTC) Received: (qmail 25367 invoked by uid 509); 16 Jul 2010 14:23:57 -0000 Received: from ravenloft.kiev.ua (94.244.131.95) by hosting.nash.net.ua with SMTP; 16 Jul 2010 14:23:58 -0000 Date: Fri, 16 Jul 2010 17:23:27 +0300 From: Alex Kozlov To: Gabor Kovesdan , freebsd-current@FreeBSD.org, spam@rm-rf.kiev.ua Message-ID: <20100716142327.GA8774@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: periodic script in base system to run csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 14:24:57 -0000 On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: Thousands pc simultaneously try to access cvsup servers? Sound like a ddos to me. Btw, if You have time, can You please check conf/124641? Thanks. -- Adios From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 14:25:23 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D6761065689 for ; Fri, 16 Jul 2010 14:25:23 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id BA1388FC1E for ; Fri, 16 Jul 2010 14:25:22 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id C9A9F14D90BD; Fri, 16 Jul 2010 16:25:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id M60JawtIPB58; Fri, 16 Jul 2010 16:25:19 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 6ECCB14D8ADE; Fri, 16 Jul 2010 16:25:19 +0200 (CEST) Message-ID: <4C406BCD.6000204@FreeBSD.org> Date: Fri, 16 Jul 2010 16:25:17 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jilles Tjoelker References: <4C406589.7030705@FreeBSD.org> <20100716141527.GA83410@stack.nl> In-Reply-To: <20100716141527.GA83410@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: periodic script in base system to run csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 14:25:23 -0000 Em 2010.07.16. 16:15, Jilles Tjoelker escreveu: > Hmm, /usr/src/Makefile has an 'update' target that can run csup and > other updating tools. Perhaps it should call that instead? > It is not just for updating your src tree but your ports tree, doc tree or eventually your local CVS repo. That's why you can specify multiple supfiles. Gabor From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 14:27:43 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 898BD106564A for ; Fri, 16 Jul 2010 14:27:43 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 461EF8FC1B for ; Fri, 16 Jul 2010 14:27:43 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 8638014D8A7F; Fri, 16 Jul 2010 16:27:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id peq8WEzvEWIm; Fri, 16 Jul 2010 16:27:40 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 5697814D2C9B; Fri, 16 Jul 2010 16:27:40 +0200 (CEST) Message-ID: <4C406C5B.3050406@FreeBSD.org> Date: Fri, 16 Jul 2010 16:27:39 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Alex Kozlov References: <20100716142327.GA8774@ravenloft.kiev.ua> In-Reply-To: <20100716142327.GA8774@ravenloft.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: periodic script in base system to run csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 14:27:43 -0000 Em 2010.07.16. 16:23, Alex Kozlov escreveu: > On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: > > Thousands pc simultaneously try to access cvsup servers? > Sound like a ddos to me. > Yes, this was the only concern and that's why I started this discussion. > Btw, if You have time, can You please check conf/124641? Thanks. > Ok, looks interesting, will take a look. Gabor From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 14:36:26 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82A91106564A for ; Fri, 16 Jul 2010 14:36:26 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from hosting.nash.net.ua (hosting.nash.net.ua [193.151.252.10]) by mx1.freebsd.org (Postfix) with SMTP id C113C8FC1F for ; Fri, 16 Jul 2010 14:36:25 +0000 (UTC) Received: (qmail 7448 invoked by uid 509); 16 Jul 2010 14:36:21 -0000 Received: from ravenloft.kiev.ua (94.244.131.95) by hosting.nash.net.ua with SMTP; 16 Jul 2010 14:36:21 -0000 Date: Fri, 16 Jul 2010 17:36:21 +0300 From: Alex Kozlov To: Gabor Kovesdan , freebsd-current@FreeBSD.org, spam@rm-rf.kiev.ua Message-ID: <20100716143621.GA9281@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: Re: periodic script in base system to run csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 14:36:26 -0000 On Fri, Jul 16, 2010 at 04:27:39PM +0200, Gabor Kovesdan wrote: > Em 2010.07.16. 16:23, Alex Kozlov escreveu: > > On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: > > > > Thousands pc simultaneously try to access cvsup servers? > > Sound like a ddos to me. > Yes, this was the only concern and that's why I started this discussion. And because its periodic, We can't use portsnap solution (random delay before csup start). -- Adios From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 19:31:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DE59106566B; Fri, 16 Jul 2010 19:31:11 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id D29EE8FC0A; Fri, 16 Jul 2010 19:31:10 +0000 (UTC) Received: by gyd8 with SMTP id 8so1813267gyd.13 for ; Fri, 16 Jul 2010 12:31:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.132.4 with SMTP id f4mr2005312ybd.337.1279308670215; Fri, 16 Jul 2010 12:31:10 -0700 (PDT) Received: by 10.151.109.4 with HTTP; Fri, 16 Jul 2010 12:31:10 -0700 (PDT) X-Originating-IP: [71.1.135.50] In-Reply-To: <4C3FFD3F.7060909@FreeBSD.org> References: <4C3FFD3F.7060909@FreeBSD.org> Date: Fri, 16 Jul 2010 12:31:10 -0700 Message-ID: From: Rob Farmer To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current Subject: Re: Clock not moving in virtual machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 19:31:11 -0000 On Thu, Jul 15, 2010 at 11:33 PM, Alexander Motin wrote: > Rob Farmer wrote: >> I have a VPS from rootbsd.net which is running current, though I don't >> update it very often. I just built and installed a new world and >> kernel and now the clock will not move from the time the system was >> booted, ie: >> # date >> Thu Jul 15 16:15:58 PDT 2010 >> >> # date >> Thu Jul 15 16:15:58 PDT 2010 >> >> I have an old kernel from May 27 which doesn't have this problem. I >> noticed some clock related stuff changing in current in the last >> couple of weeks and suspect that their VM setup doesn't play well with >> these changes (their site says they use Xen, but several boot messages >> refer to QEMU). Officially, I think they only support running 8.0 so I >> thought I would ask here if anyone has any ideas before putting in a >> support request. >> >> Here's a diff of the dmesgs - I can post full copies if needed but >> didn't want to start with a ridicously long message: > >> =A0FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> =A0FreeBSD/SMP: 0 package(s) x 16 core(s) x 2 SMT threads >> =A0 cpu0 (BSP): APIC ID: =A00 > > Probably not related, but funny. :) So you have two CPUs? Yes, there's 2 CPUs. It also gives the non uniform processors warning, but it has been like that forever. > >> @@ -81,7 +81,10 @@ >> =A0ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode >> =A0ppc0: [ITHREAD] >> =A0ppbus0: on ppc0 >> -atrtc0: at port 0x70 irq 8 on isa0 >> +atrtc0: at port 0x70 irq 8 on isa0 >> +atrtc0: [FILTER] >> +Event timer "RTC" frequency 32768 Hz quality 0 >> +Starting kernel event timers: LAPIC @ 200Hz, RTC @ 128Hz >> =A0Timecounters tick every 5.000 msec > > Everything seems reasonable there. Try to collect more information: > sysctl kern.timecounter > sysctl kern.eventtimer > vmstat -ia > systat -vm 1 (presence and frequencies of interrupts) > > It could be a bug in emulation of some timers or bug in respective timer > driver, which was not triggered before last changes. You may try switch > to different timecounter by setting kern.timecounter.hardware, or > different eventtimers by setting kern.eventtimer.timer1 and > kern.eventtimer.timer2 sysctls. > > -- > Alexander Motin > This is all on the new (not-working) kernel in single user mode: # sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) dummy(-1000000) kern.timecounter.hardware: dummy kern.timecounter.stepwarnings: 0 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 205772785 kern.timecounter.tc.TSC.frequency: 2261052646 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 kern.timecounter.tc.TSC.counter changes everytime (205772785, 3200717147, 1205899870, ...) but I can't see any pattern. # sysctl kern.eventtimer kern.eventtimer.choice: LAPIC(500) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 50001404 kern.eventtimer.et.LAPIC.quality: 500 kern.eventtimer.et.RTC.flags: 1 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.timer2: RTC kern.eventtimer.timer1: LAPIC kern.eventtimer.singlemul: 4 # vmstat -ia interrupt total rate ??? 0 0 irq1: atkbd0 339 339 stray irq1 0 0 irq0: 0 0 stray irq0 0 0 irq3: 0 0 stray irq3 0 0 irq4: uart0 0 0 stray irq4 0 0 irq5: re0 0 0 stray irq5 0 0 irq6: 0 0 stray irq6 0 0 irq7: ppc0 0 0 stray irq7 0 0 irq8: atrtc0 24463 24463 stray irq8 0 0 irq9: 0 0 stray irq9 0 0 irq10: re1 0 0 stray irq10 0 0 irq11: 0 0 stray irq11 0 0 irq12: psm0 0 0 stray irq12 0 0 irq13: 0 0 stray irq13 0 0 irq14: ata0 224 224 stray irq14 0 0 irq15: ata1 0 0 stray irq15 0 0 irq16: 0 0 stray irq16 0 0 irq17: 0 0 stray irq17 0 0 irq18: 0 0 stray irq18 0 0 irq19: 0 0 stray irq19 0 0 irq20: 0 0 stray irq20 0 0 irq21: 0 0 stray irq21 0 0 irq22: 0 0 stray irq22 0 0 irq23: 0 0 stray irq23 0 0 irq24: 0 0 stray irq24 0 0 irq25: 0 0 stray irq25 0 0 irq26: 0 0 stray irq26 0 0 irq27: 0 0 stray irq27 0 0 irq28: 0 0 stray irq28 0 0 irq29: 0 0 stray irq29 0 0 irq30: 0 0 stray irq30 0 0 irq31: 0 0 stray irq31 0 0 irq32: 0 0 stray irq32 0 0 irq33: 0 0 stray irq33 0 0 irq34: 0 0 stray irq34 0 0 irq35: 0 0 stray irq35 0 0 irq36: 0 0 stray irq36 0 0 irq37: 0 0 stray irq37 0 0 irq38: 0 0 stray irq38 0 0 irq39: 0 0 stray irq39 0 0 irq40: 0 0 stray irq40 0 0 irq41: 0 0 stray irq41 0 0 irq42: 0 0 stray irq42 0 0 irq43: 0 0 stray irq43 0 0 irq44: 0 0 stray irq44 0 0 irq45: 0 0 stray irq45 0 0 irq46: 0 0 stray irq46 0 0 irq47: 0 0 stray irq47 0 0 cpu0:timer 38223 38223 cpu1:timer 38220 38220 Total 101469 101469 systat -ia cycles between: 526 total atkbd0 1 128 atrtc0 8 ata0 irq14 199 cpu0:timer 199 cpu1:timer 530 total atkbd0 1 128 atrtc0 8 ata0 irq14 201 cpu0:timer 201 cpu1:timer If I set kern.eventtimer.timer1=3D"RTC", dmesg says: Starting kernel event timers: RTC @ 200Hz, LAPIC @ 128Hz Event timer "LAPIC" is dead. Starting kernel event timers: RTC @ 800Hz, NONE @ 0Hz The clock still doesn't move though. On the old kernel I had i8254 in the dmesg and that appears to be what was = used: kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) i8254(0) dummy(-1000000) kern.timecounter.hardware: i8254 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 51889 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 266155055 kern.timecounter.tc.TSC.frequency: 2261010847 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 Also, in the old kernel, there was nothing on irq8 in vmstat: irq8: 0 0 stray irq8 0 0 At the loader prompt I tried entering set kern.timecounter.hardware=3D"i8254" and set kern.timecounter.hardware=3D"TSC" and they appear set correctly if I type show, but when I boot, the sysctl is back to dummy. I have zero knowledge of this kind of thing, but I looks to me like I need to be using i8254 and the new kernel is not detecting this device. Is there a hint or something I can set to try and pick up this device again? Thanks, --=20 Rob Farmer From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 20:47:30 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEA1010656E7 for ; Fri, 16 Jul 2010 20:47:29 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6993C8FC1C for ; Fri, 16 Jul 2010 20:47:28 +0000 (UTC) Received: by fxm13 with SMTP id 13so1482131fxm.13 for ; Fri, 16 Jul 2010 13:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=E5rno1n0oQFmgj2ovHBQZ4zBwBuEIZ4AYbBKIsMyHrI=; b=fm8jeQs/iDmEJvOTLTAFCivrFazfoF+Juzy5C/rrE+opI7g43X1Uy2l0aswHrxnRmg w0A2sFtuto/f2L86Q0jSN3GuzE87eWVuUAYCvOEVVLL1hdYt+xKRJAJ23gKIK10cRXjM RQqLi3FNjcSi0VOKz2EnbCXKGEmNgPNS3N9Sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=PCJ0ZFvngDEd9R6tH0G6h5oecBfYTqPWeqplwRF11biBQ4sYszRJuTu4pfKUQN5BAe 95EYDNX44GnM+IvUSIfaFL+8KKe2WWPJbz9ROT8XYBCQNjUz0OByk6pLCZDAIpVjYsje A06EuO2NLFGi4xJ1RV5nKyO1UbDlwvXgpWCvA= Received: by 10.223.119.133 with SMTP id z5mr1118755faq.62.1279313248132; Fri, 16 Jul 2010 13:47:28 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y2sm894858fau.36.2010.07.16.13.47.26 (version=SSLv3 cipher=RC4-MD5); Fri, 16 Jul 2010 13:47:27 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C40C55B.8040508@FreeBSD.org> Date: Fri, 16 Jul 2010 23:47:23 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Rob Farmer References: <4C3FFD3F.7060909@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current Subject: Re: Clock not moving in virtual machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 20:47:30 -0000 Rob Farmer wrote: >>> @@ -81,7 +81,10 @@ >>> ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode >>> ppc0: [ITHREAD] >>> ppbus0: on ppc0 >>> -atrtc0: at port 0x70 irq 8 on isa0 >>> +atrtc0: at port 0x70 irq 8 on isa0 >>> +atrtc0: [FILTER] >>> +Event timer "RTC" frequency 32768 Hz quality 0 >>> +Starting kernel event timers: LAPIC @ 200Hz, RTC @ 128Hz >>> Timecounters tick every 5.000 msec >> Everything seems reasonable there. Try to collect more information: >> sysctl kern.timecounter >> sysctl kern.eventtimer >> vmstat -ia >> systat -vm 1 (presence and frequencies of interrupts) >> >> It could be a bug in emulation of some timers or bug in respective timer >> driver, which was not triggered before last changes. You may try switch >> to different timecounter by setting kern.timecounter.hardware, or >> different eventtimers by setting kern.eventtimer.timer1 and >> kern.eventtimer.timer2 sysctls. > > This is all on the new (not-working) kernel in single user mode: > > # sysctl kern.timecounter > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) dummy(-1000000) > kern.timecounter.hardware: dummy > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.TSC.mask: 4294967295 > kern.timecounter.tc.TSC.counter: 205772785 > kern.timecounter.tc.TSC.frequency: 2261052646 > kern.timecounter.tc.TSC.quality: -100 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > > kern.timecounter.tc.TSC.counter changes everytime (205772785, > 3200717147, 1205899870, ...) but I can't see any pattern. It is probably hard to see pattern due to to very high clock frequency. But TSC timecounter is unreliable even on real SMP systems. What it counts on virtual SMP - even bigger question. As system seems never uses timecounters with negative quality - you've left with kern.timecounter.hardware=dummy - that's why time is not going. As last resort you may try to set sysctl kern.timecounter.hardware=TSC in run time. Previously you were using i8254 timecounter, but now you lost it as your virtual machine PnP BIOS doesn't announce it. QEMU does the same, but instead it gives HPET which your emulator seems also doesn't. To force i8254 presence add to the /boot/device.hints lines: hint.attimer.0.at="isa" hint.attimer.0.port="0x40" hint.attimer.0.irq="0" -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 21:21:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38D691065687 for ; Fri, 16 Jul 2010 21:21:55 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id B64C58FC13 for ; Fri, 16 Jul 2010 21:21:54 +0000 (UTC) Received: by fxm13 with SMTP id 13so1494699fxm.13 for ; Fri, 16 Jul 2010 14:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=zjsyjUukhVWIe17C6m+Ymqt6dTYHOL9FeNCu3X7CJxQ=; b=Mg2p+6jfDnLiOKPzILetx4F85RIalq6KqVdJmLVXSswxNxaJKeIssHCfIfyfUJHqTh 01t7uuybb0/dbg6gU5kl3aAfkPJIzV2LicRJm3zSvXi0bMlja1A0qboEjrmTe8xR3lXK ylcUg+Nis2i2VuqPM5WRXms6L8/WpOvfonAHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=XB6dyF71BcErBv21gySiEfzLyrlgamkRGNTF1UN6fr9GQMbHVcjoQpAGUtHqWxJu/u YqXKVsKEAqCfA7i9rp+uD9U3jXqU0NUaFLoCX06hNzcG723k+NlUmB6p84iY7svVqjIi 7RYGW4u39xPZ+PFNXqjLKJ0EUkAafM+gOmL6A= Received: by 10.223.113.12 with SMTP id y12mr1145575fap.36.1279315313502; Fri, 16 Jul 2010 14:21:53 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id e20sm332616fak.23.2010.07.16.14.21.51 (version=SSLv3 cipher=RC4-MD5); Fri, 16 Jul 2010 14:21:52 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C40CD2F.6050604@FreeBSD.org> Date: Sat, 17 Jul 2010 00:20:47 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Bruce Cran References: <4C3FFD3F.7060909@FreeBSD.org> <4C40C55B.8040508@FreeBSD.org> <20100716210500.GA13257@muon.cran.org.uk> In-Reply-To: <20100716210500.GA13257@muon.cran.org.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rob Farmer , current Subject: Re: Clock not moving in virtual machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 21:21:55 -0000 Bruce Cran wrote: > On Fri, Jul 16, 2010 at 11:47:23PM +0300, Alexander Motin wrote: >> It is probably hard to see pattern due to to very high clock frequency. >> But TSC timecounter is unreliable even on real SMP systems. What it >> counts on virtual SMP - even bigger question. As system seems never uses >> timecounters with negative quality - you've left with >> kern.timecounter.hardware=dummy - that's why time is not going. As last >> resort you may try to set sysctl kern.timecounter.hardware=TSC in run time. > > I came across the same problem on rootbsd a few days ago, and set the TSC > as the timecounter in /etc/sysctl.conf - I've since found it should be > possible to also set kern.timecounter.smp_tsc=1 in /boot/loader.conf to let > the TSC be chosen. The system's now been running for a day and I've not had > any warnings about the clock going backward, and since the time has > remained correct I guess Xen synchronises with the host? I have no idea about TSC in XEN, but QEMU just passes TSC from the physical CPU. So if host' TSCs are not synchronized - value may jump accidentally when QEMU process migrates between CPUs. > Should I still switch back to using the i8254? I would say it depends. i8254 frequency is always known, while TSC depends on calibration. Calibration on virtual machine I think much less precise then on physical. Same time, if i8254 also used as event timer, timestamp calculation algorithm is not very trivial there and I am not sure it is absolutely reliable. So I would probably used i8254 as time counter and LAPIC+RTC as event timers. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 21:27:50 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E361106567A; Fri, 16 Jul 2010 21:27:50 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id D7A848FC22; Fri, 16 Jul 2010 21:27:47 +0000 (UTC) Received: by gxk24 with SMTP id 24so1895905gxk.13 for ; Fri, 16 Jul 2010 14:27:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.76.9 with SMTP id d9mr1951996ybl.231.1279315664851; Fri, 16 Jul 2010 14:27:44 -0700 (PDT) Received: by 10.151.109.4 with HTTP; Fri, 16 Jul 2010 14:27:44 -0700 (PDT) X-Originating-IP: [71.1.135.50] In-Reply-To: <20100716210500.GA13257@muon.cran.org.uk> References: <4C3FFD3F.7060909@FreeBSD.org> <4C40C55B.8040508@FreeBSD.org> <20100716210500.GA13257@muon.cran.org.uk> Date: Fri, 16 Jul 2010 14:27:44 -0700 Message-ID: From: Rob Farmer To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , current Subject: Re: Clock not moving in virtual machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 21:27:50 -0000 On Fri, Jul 16, 2010 at 2:05 PM, Bruce Cran wrote: > On Fri, Jul 16, 2010 at 11:47:23PM +0300, Alexander Motin wrote: >> >> It is probably hard to see pattern due to to very high clock frequency. >> But TSC timecounter is unreliable even on real SMP systems. What it >> counts on virtual SMP - even bigger question. As system seems never uses >> timecounters with negative quality - you've left with >> kern.timecounter.hardware=dummy - that's why time is not going. As last >> resort you may try to set sysctl kern.timecounter.hardware=TSC in run time. > > I came across the same problem on rootbsd a few days ago, and set the TSC > as the timecounter in /etc/sysctl.conf - I've since found it should be > possible to also set kern.timecounter.smp_tsc=1 in /boot/loader.conf to let > the TSC be chosen. The system's now been running for a day and I've not had > any warnings about the clock going backward, and since the time has > remained correct I guess Xen synchronises with the host? Should I still > switch back to using the i8254? > > -- > Bruce Cran > Setting kern.timecounter.smp_tsc=1 works for me. I put it in /boot/loader.conf so it would automatically work for single user mode too. I don't think the host automatically synchronizes the clock - their website recommends running ntp and I saw the clock drift a fair amount before I started doing that. Thanks for the tip. -- Rob Farmer From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 21:55:38 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B991065672; Fri, 16 Jul 2010 21:55:38 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 88FD68FC08; Fri, 16 Jul 2010 21:55:36 +0000 (UTC) Received: by ewy26 with SMTP id 26so1058150ewy.13 for ; Fri, 16 Jul 2010 14:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=jZ8C+cV0Z5A+ijDOrCgKHMhBGg+OEhxDagjkIyatMg0=; b=XEik48jUd/7OJImRyZBXkf9WleRXcnB3sO517AeCRvcpEfOvis/y3uqDQ2QI14Lzy1 j5DMqjxIHPUckkcUd4+agoGGz2L14y3TKZPbSIqlMVAFj5/7zBo9+YTieiFo35BJJZar ZnafO8LKTTpqgEGxDyH80bI+ceN1X+3TOcZlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=HR6G63FK6M4u1cgC3P8RMsQxFUTjuOf91FOaSwNPOGwdcdrLwwH3NBTmNg2t/MZaUD 2ucnPPnftF0cywl5uVIuVH1K2iyy/mNK1u3q1W/e1IDNik6+bWGD0WrbpWisydYfCjLc jK2HwxvU8BRCEcubiqd1jyXr2mH3JaqhENFoQ= Received: by 10.213.3.83 with SMTP id 19mr1652538ebm.5.1279317336015; Fri, 16 Jul 2010 14:55:36 -0700 (PDT) Received: from [192.168.1.70] (ip4da3ae31.direct-adsl.nl [77.163.174.49]) by mx.google.com with ESMTPS id a48sm21617333eei.13.2010.07.16.14.55.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Jul 2010 14:55:34 -0700 (PDT) Sender: =?UTF-8?Q?Ren=C3=A9_Ladan?= Message-ID: <4C40D554.7010301@freebsd.org> Date: Fri, 16 Jul 2010 23:55:32 +0200 From: Rene Ladan Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; nl-NL; rv:1.9.1.10) Gecko/20100627 Thunderbird/3.0.5 MIME-Version: 1.0 To: Roman Divacky References: <20100714183834.GA19684@freebsd.org> <20100715174222.GA79771@freebsd.org> In-Reply-To: <20100715174222.GA79771@freebsd.org> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [TESTING]: updated clang/LLVM needs testing in ClangBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 21:55:38 -0000 On 15-07-2010 19:42, Roman Divacky wrote: > I updated clang/LLVM in clangbsd to a newer version which I believe > will fix thas. can you rene (and everyone else) please retest with > updated ClangBSD and report back? > The updated version builds and installs fine, I'm now running the clangbsd kernel. The clangbsd world (chrooted with "make distribution DESTDIR=/usr/clangbsd" and "mount -t devfs devfs /usr/clangbsd/dev") seems to work fine, some basic commands work. Using a clang kernel with gcc kernel modules also works fine :) Regards, Rene > > On Thu, Jul 15, 2010 at 01:33:04PM +0200, Ren? Ladan wrote: >> 2010/7/14 Roman Divacky : >>> hi, >>> >>> ClangBSD was updated to LLVM/clang revision r108243 which we plan to >>> merge into HEAD. We would like that revision to be tested as much as possible >>> and therefore we ask you to test ClangBSD to assure that the revision >>> we are updating to does not have some really embarassing bugs. >>> >>> How to do it (on i386 and amd64): >>> >>> 0) install fresh devel/llvm-devel port >>> >>> 1) svn co http://svn.freebsd.org/base/projects/clangbsd src >>> >>> 2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf >>> >>> 3) cd src && make buildworld >>> >> And here my buildworld fails with: >> >> ===> lib/clang/libclanglex (depend) >> tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex >> -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic >> -gen-clang-diags-defs -clang-component=Common >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td >>> DiagnosticCommonKinds.inc.h >> tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex >> -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic >> -gen-clang-diags-defs -clang-component=Lex >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td >>> DiagnosticLexKinds.inc.h >> rm -f .depend >> CC='clang -isysroot /usr/obj/usr/home/rene/freebsd/clangbsd/tmp >> -B/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/ >> -L/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/' mkdep -f >> .depend -a -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include >> -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex >> -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include >> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS >> -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" >> -DCLANG_VENDOR=\"FreeBSD\ \" -DSVN_REVISION=\"108243\" >> -DCLANG_VENDOR_SUFFIX=\"\ 20100713\" >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/LiteralSupport.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroArgs.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroInfo.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPCaching.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPDirectives.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPExpressions.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPLexerChange.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPMacroExpansion.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PTHLexer.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Pragma.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessingRecord.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Preprocessor.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessorLexer.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/ScratchBuffer.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/TokenConcatenation.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/TokenLexer.cpp >> /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:1110:10: >> fatal error: >> 'emmintrin.h' file not found >> #include >> ^ >> 1 error generated. >> mkdep: compile failed >> *** Error code 1 >> >> Stop in /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex. >> *** Error code 1 >> >> Stop in /usr/home/rene/freebsd/clangbsd/lib/clang. >> *** Error code 1 >> >> Stop in /usr/home/rene/freebsd/clangbsd/lib. >> *** Error code 1 >> >> Stop in /usr/home/rene/freebsd/clangbsd. >> *** Error code 1 >> >> Stop in /usr/home/rene/freebsd/clangbsd. >> *** Error code 1 >> >> Stop in /usr/home/rene/freebsd/clangbsd. >> *** Error code 1 >> >> Stop in /usr/home/rene/freebsd/clangbsd. >> >> I do have CPUTYPE=nocona in /etc/make.conf, but apart from that /etc/make.conf >> only contains port-related stuff. /etc/src.conf only contains the two >> WERROR lines. >> >> acer# locate emmintrin.h >> /usr/home/rene/freebsd/clangbsd/contrib/gcc/config/i386/.svn/prop-base/emmintrin.h.svn-base >> /usr/home/rene/freebsd/clangbsd/contrib/gcc/config/i386/.svn/text-base/emmintrin.h.svn-base >> /usr/home/rene/freebsd/clangbsd/contrib/gcc/config/i386/emmintrin.h >> /usr/home/rene/freebsd/clangbsd/contrib/llvm/tools/clang/lib/Headers/.svn/text-base/emmintrin.h.svn-base >> /usr/home/rene/freebsd/clangbsd/contrib/llvm/tools/clang/lib/Headers/emmintrin.h >> /usr/include/clang/2.0/emmintrin.h >> /usr/include/gcc/4.2/emmintrin.h >> /usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd9.0/4.4.5/include/emmintrin.h >> /usr/obj/usr/src/tmp/usr/include/clang/2.0/emmintrin.h >> /usr/obj/usr/src/tmp/usr/include/gcc/4.2/emmintrin.h >> acer# ls -l /usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/include/*/*/emmintrin.h >> -rwxr-xr-x 1 root wheel 36913 Jul 15 11:24 >> /usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/include/clang/2.8/emmintrin.h >> -rwxr-xr-x 1 root wheel 42617 Oct 14 2009 >> /usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/include/gcc/4.2/emmintrin.h >> >> acer# uname -a >> FreeBSD acer 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r209980M: Tue Jul 13 >> 11:48:03 CEST 2010 rene@acer:/usr/obj/usr/src/sys/GENERIC amd64 >> -- http://www.rene-ladan.nl/ GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net) From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 21:05:05 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B545C1065677; Fri, 16 Jul 2010 21:05:05 +0000 (UTC) (envelope-from brucec@muon.cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [204.109.60.94]) by mx1.freebsd.org (Postfix) with ESMTP id 953CE8FC1B; Fri, 16 Jul 2010 21:05:05 +0000 (UTC) Received: by muon.cran.org.uk (Postfix, from userid 1002) id ADCE9613C; Fri, 16 Jul 2010 21:05:00 +0000 (UTC) Date: Fri, 16 Jul 2010 21:05:00 +0000 From: Bruce Cran To: Alexander Motin Message-ID: <20100716210500.GA13257@muon.cran.org.uk> References: <4C3FFD3F.7060909@FreeBSD.org> <4C40C55B.8040508@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C40C55B.8040508@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Fri, 16 Jul 2010 22:51:34 +0000 Cc: Rob Farmer , current Subject: Re: Clock not moving in virtual machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 21:05:05 -0000 On Fri, Jul 16, 2010 at 11:47:23PM +0300, Alexander Motin wrote: > > It is probably hard to see pattern due to to very high clock frequency. > But TSC timecounter is unreliable even on real SMP systems. What it > counts on virtual SMP - even bigger question. As system seems never uses > timecounters with negative quality - you've left with > kern.timecounter.hardware=dummy - that's why time is not going. As last > resort you may try to set sysctl kern.timecounter.hardware=TSC in run time. I came across the same problem on rootbsd a few days ago, and set the TSC as the timecounter in /etc/sysctl.conf - I've since found it should be possible to also set kern.timecounter.smp_tsc=1 in /boot/loader.conf to let the TSC be chosen. The system's now been running for a day and I've not had any warnings about the clock going backward, and since the time has remained correct I guess Xen synchronises with the host? Should I still switch back to using the i8254? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 23:04:47 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BFF61065672 for ; Fri, 16 Jul 2010 23:04:47 +0000 (UTC) (envelope-from freebsd-current-local@be-well.ilk.org) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.49]) by mx1.freebsd.org (Postfix) with ESMTP id 338968FC0A for ; Fri, 16 Jul 2010 23:04:46 +0000 (UTC) Received: (qmail 16141 invoked from network); 16 Jul 2010 23:04:46 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Jul 2010 23:04:46 -0000 Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.6]) by be-well.ilk.org (Postfix) with ESMTP id 4E55650829; Fri, 16 Jul 2010 19:04:38 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id 7F2E21CC8A; Fri, 16 Jul 2010 19:04:38 -0400 (EDT) From: Lowell Gilbert To: Alex Kozlov References: <20100716143621.GA9281@ravenloft.kiev.ua> Date: Fri, 16 Jul 2010 19:04:38 -0400 In-Reply-To: <20100716143621.GA9281@ravenloft.kiev.ua> (Alex Kozlov's message of "Fri, 16 Jul 2010 17:36:21 +0300") Message-ID: <44k4ov6nax.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, Gabor Kovesdan Subject: Re: periodic script in base system to run csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2010 23:04:47 -0000 Alex Kozlov writes: > On Fri, Jul 16, 2010 at 04:27:39PM +0200, Gabor Kovesdan wrote: >> Em 2010.07.16. 16:23, Alex Kozlov escreveu: >> > On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: >> > >> > Thousands pc simultaneously try to access cvsup servers? >> > Sound like a ddos to me. >> Yes, this was the only concern and that's why I started this discussion. > And because its periodic, We can't use portsnap solution (random delay > before csup start). It's not completely impossible; periodic could spin off a separate shell for it, with a random delay. It's not clear what the best way to deal with the output would be, although several approaches present themselves. It would be a lot more complicated than Gabor's approach, though. From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 07:17:16 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5114A1065675 for ; Sat, 17 Jul 2010 07:17:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id D92A18FC18 for ; Sat, 17 Jul 2010 07:17:15 +0000 (UTC) Received: (qmail 17071 invoked by uid 399); 17 Jul 2010 07:17:13 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Jul 2010 07:17:13 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sat, 17 Jul 2010 00:17:11 -0700 (PDT) From: Doug Barton To: freebsd-current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 07:17:16 -0000 This is happening after I open a flash video in firefox and watch it for > 15 minutes: root 20 -80 - 0K 160K WAIT 0 3:38 14.08% intr After this happens, my system goes into a death spiral and I have to shut it down. vmstat -i interrupt total rate irq1: atkbd0 10384 0 irq9: acpi0 5 0 irq14: ata0 153410 7 irq15: ata1 58 0 irq17: wpi0 534038 27 irq20: hpet0 uhci0+ 2496833 129 irq22: uhci2 66485 3 cpu0:timer 19238037 999 irq256: hdac0 189713 9 cpu1:timer 19236431 999 Total 41925394 2178 Any suggestions? current (r210135), i386 smp. Dell C2D laptop. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 08:00:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17C7810656D7; Sat, 17 Jul 2010 08:00:21 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 942718FC16; Sat, 17 Jul 2010 08:00:20 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o6H80EZn042495 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 17 Jul 2010 09:00:14 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <4C416307.9000001@infracaninophile.co.uk> Date: Sat, 17 Jul 2010 09:00:07 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Lowell Gilbert References: <20100716143621.GA9281@ravenloft.kiev.ua> <44k4ov6nax.fsf@lowell-desk.lan> In-Reply-To: <44k4ov6nax.fsf@lowell-desk.lan> X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1542F6D7EF7AAA6124ED2888" X-Virus-Scanned: clamav-milter 0.96.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_20,DKIM_ADSP_ALL, SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-current@freebsd.org, Alex Kozlov , Gabor Kovesdan Subject: Re: periodic script in base system to run csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 08:00:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1542F6D7EF7AAA6124ED2888 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17/07/2010 24:04:38, Lowell Gilbert wrote: > Alex Kozlov writes: >=20 >> On Fri, Jul 16, 2010 at 04:27:39PM +0200, Gabor Kovesdan wrote: >>> Em 2010.07.16. 16:23, Alex Kozlov escreveu: >>>> On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: >>>> >>>> Thousands pc simultaneously try to access cvsup servers? >>>> Sound like a ddos to me. >>> Yes, this was the only concern and that's why I started this discussi= on. >> And because its periodic, We can't use portsnap solution (random delay= >> before csup start). >=20 > It's not completely impossible; periodic could spin off a separate shel= l > for it, with a random delay. It's not clear what the best way to deal > with the output would be, although several approaches present themselve= s. > It would be a lot more complicated than Gabor's approach, though. Simply ensuring the csup periodic job is the last one to run (/etc/periodic/daily/1000.csup ?) should give you the best of both worlds. You can insert a random delay of up to an hour and still deal with csup as a foreground job. All of the other periodic jobs will run as normal (and should help with randomising the time distribution of the csup runs too) -- you'll just have to wait a bit longer for the nightly e-mail to be produced. Even so, I think this is still likely to upset the cvsup servers: a whole timezone worth of machines hitting a small number of servers within one or two hours might be doable with portsnap / freebsd-update but cvsup requires a lot more effort server-side. Cheers Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig1542F6D7EF7AAA6124ED2888 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxBYw4ACgkQ8Mjk52CukIx/ZQCfWMuiyGsoD77lllg/aaF9dPaY j6sAn30E/jk37O4y+gR2Fqmn0Th5kvf4 =P5QY -----END PGP SIGNATURE----- --------------enig1542F6D7EF7AAA6124ED2888-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 08:16:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B854C1065670 for ; Sat, 17 Jul 2010 08:16:17 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 49C478FC16 for ; Sat, 17 Jul 2010 08:16:17 +0000 (UTC) Received: (qmail invoked by alias); 17 Jul 2010 08:16:15 -0000 Received: from e180219246.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [85.180.219.246] by mail.gmx.com (mp-eu002) with SMTP; 17 Jul 2010 10:16:15 +0200 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX1/UF24EOtzUSw/oFZXQM0Euvk4VHMMNytH7EpHVCx W6MjidrTVCrqzO Received: by myhost.mydomain.de (Postfix, from userid 1001) id E157A97D8; Sat, 17 Jul 2010 10:16:14 +0200 (CEST) From: Christof Schulze To: freebsd-current@freebsd.org Date: Sat, 17 Jul 2010 10:15:55 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RC1; KDE/4.4.5; amd64; ; ) References: <20100716143621.GA9281@ravenloft.kiev.ua> <44k4ov6nax.fsf@lowell-desk.lan> <4C416307.9000001@infracaninophile.co.uk> In-Reply-To: <4C416307.9000001@infracaninophile.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4182512.5POp726C8H"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007171016.14467.christof.schulze@gmx.com> X-Y-GMX-Trusted: 0 Cc: Matthew Seaman , Alex Kozlov , Gabor Kovesdan , Lowell Gilbert Subject: Re: periodic script in base system to run csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 08:16:17 -0000 --nextPart4182512.5POp726C8H Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable > [periodic updating source] Besides technical feasibility: What is the use case behind it? Regards Christof Am Saturday 17 July 2010 10:00:07 schrieb Matthew Seaman: > On 17/07/2010 24:04:38, Lowell Gilbert wrote: > > Alex Kozlov writes: > >> On Fri, Jul 16, 2010 at 04:27:39PM +0200, Gabor Kovesdan wrote: > >>> Em 2010.07.16. 16:23, Alex Kozlov escreveu: > >>>> On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan=20 wrote: > >>>>=20 > >>>> Thousands pc simultaneously try to access cvsup servers? > >>>> Sound like a ddos to me. > >>>=20 > >>> Yes, this was the only concern and that's why I started this > >>> discussion. > >>=20 > >> And because its periodic, We can't use portsnap solution=20 (random delay > >> before csup start). > >=20 > > It's not completely impossible; periodic could spin off a=20 separate shell > > for it, with a random delay. It's not clear what the best way=20 to deal > > with the output would be, although several approaches present=20 themselves. > > It would be a lot more complicated than Gabor's approach,=20 though. >=20 > Simply ensuring the csup periodic job is the last one to run > (/etc/periodic/daily/1000.csup ?) should give you the best of both > worlds. You can insert a random delay of up to an hour and still=20 deal > with csup as a foreground job. All of the other periodic jobs=20 will run > as normal (and should help with randomising the time distribution=20 of the > csup runs too) -- you'll just have to wait a bit longer for the=20 nightly > e-mail to be produced. >=20 > Even so, I think this is still likely to upset the cvsup servers:=20 a > whole timezone worth of machines hitting a small number of servers > within one or two hours might be doable with portsnap / freebsd- update > but cvsup requires a lot more effort server-side. >=20 > Cheers >=20 > Matthew =2D-=20 () ascii ribbon campaign - against html e-mail=20 /\ www.asciiribbon.org - against proprietary attachments --nextPart4182512.5POp726C8H Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEABECAAYFAkxBZs4ACgkQpZfyPAmdZJkCpQCeMA6P33DNZtbMsTkdKaPO+o3f gdIAoLPhwjpy9cFABjSV9bJI3SkGVhBV =H9om -----END PGP SIGNATURE----- --nextPart4182512.5POp726C8H-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 10:15:01 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B96F81065678 for ; Sat, 17 Jul 2010 10:15:01 +0000 (UTC) (envelope-from marco+freebsd-current@lordsith.net) Received: from maul.lordsith.net (unknown [IPv6:2001:7b8:330::1]) by mx1.freebsd.org (Postfix) with ESMTP id 321678FC0C for ; Sat, 17 Jul 2010 10:15:00 +0000 (UTC) Received: by maul.lordsith.net (Postfix, from userid 1001) id 5AB63575471; Sat, 17 Jul 2010 12:14:59 +0200 (CEST) Date: Sat, 17 Jul 2010 12:14:59 +0200 From: Marco van Lienen To: freebsd-current@FreeBSD.org Message-ID: <20100717101459.GA13626@lordsith.net> Mail-Followup-To: Marco van Lienen , freebsd-current@FreeBSD.org References: <4C3C7202.7090103@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <4C3C7202.7090103@FreeBSD.org> Organization: LordSith.Net X-Operating-System: FreeBSD 8.0-RELEASE-p2 X-FreeBSD: RULEZ Them All X-GPG-Fingerprint: A025 D8AA AC1B D2FC 380D 4FC1 8EA0 0BA8 8580 E6CB X-GPG-Key: http://lordsith.net/gpgkey X-Uptime: 11:38AM up 6 days, 12 hrs, 5 users, load averages: 0.00, 0.00, 0.00 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: [HEADSUP] ZFS version 15 committed to head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marco van Lienen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 10:15:01 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 13, 2010 at 04:02:42PM +0200, you (Martin Matuska) sent the fol= lowing to the -current list: > Dear community, >=20 > Feel free to test everything and don't forget to report any bugs found. When I create a raidz pool of 3 equally sized hdd's (3x2Tb WD caviar green = drives) the reported available space by zpool and zfs is VERY different (no= t just the known differences). On a 9.0-CURRENT amd64 box: # uname -a FreeBSD trinity.lordsith.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Tue Jul 13= 21:58:14 UTC 2010 root@trinity.lordsith.net:/usr/obj/usr/src/sys/trini= ty amd64 # zpool create pool1 raidz ada2 ada3 ada4 # zpool list pool1 NAME SIZE USED AVAIL CAP HEALTH ALTROOT pool1 5.44T 147K 5.44T 0% ONLINE - # ada drives dmesg output: ada2 at ahcich4 bus 0 scbus5 target 0 lun 0 ada2: ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3 at ahcich5 bus 0 scbus6 target 0 lun 0 ada3: ATA-8 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4 at ahcich6 bus 0 scbus7 target 0 lun 0 ada4: ATA-8 SATA 2.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: Command Queueing enabled ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) zfs list however only shows: # zfs list pool1 NAME USED AVAIL REFER MOUNTPOINT pool1 91.9K 3.56T 28.0K /pool1 I just lost the space of an entire hdd! To rule out a possible drive issue I created a raidz pool based on 3 65m fi= les. # dd if=3D/dev/zero of=3D/file1 bs=3D1m count=3D65=20 # dd if=3D/dev/zero of=3D/file2 bs=3D1m count=3D65=20 # dd if=3D/dev/zero of=3D/file3 bs=3D1m count=3D65=20 # zpool create test raidz /file1 /file2 /file3 # # zpool list test NAME SIZE USED AVAIL CAP HEALTH ALTROOT test 181M 147K 181M 0% ONLINE - # zfs list test NAME USED AVAIL REFER MOUNTPOINT test 91.9K 88.5M 28.0K /test When I create a non-redundant storage pool using the same 3 files or 3 driv= es the available space reported by zfs is what I'm expecting to see though = so it looks like creating a raidz storage pool is showing very weird behavi= or. This doesn't have as much to do with the ZFS v15 bits commited to -HEAD sin= ce I have the exact same behavior on a 8.0-RELEASE-p2 i386 box with ZFS v14. A friend of mine is running osol build 117 but he created his raidz pool on= an even older build though. His raidz pool also uses 3 equally-sized drives (3x2Tb) and his raidz pool = is showing: % zfs list -r pool2 NAME USED AVAIL REFER MOUNTPO= INT pool2 3.32T 2.06T 3.18T /export= /pool2 % df -h pool2 Filesystem size used avail capacity Mounted on pool2 5.4T 3.2T 2.1T 61% /export/pool2 To run further tests he also created a test raidz pool using 3 65m files: % zfs list test2 NAME USED AVAIL REFER MOUNTPOINT test2 73.5K 149M 21K /test2 So on osol build 117 the available space is what I'm expecting to see where= as on FreeBSD 9.0-CURRENT amd64 and 8.0-RELEASE-p2 i386=20 Is someone having the same issues? Cheers, marco --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEAREDAAYFAkxBgqMACgkQjqALqIWA5sthiQCguVe/jha27AJ0VTzyP/wW4P/F c1AAn0ABpmxDZGYzVu9lxRVqJm2Pwfxq =yPoG -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 10:26:03 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6537E106566B for ; Sat, 17 Jul 2010 10:26:03 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id E86638FC0A for ; Sat, 17 Jul 2010 10:26:02 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id ED28B65850; Sat, 17 Jul 2010 10:25:57 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20100717101459.GA13626@lordsith.net> Date: Sat, 17 Jul 2010 12:25:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9E4FCF4C-7A69-426E-9F39-B5487D4CB07C@lassitu.de> References: <4C3C7202.7090103@FreeBSD.org> <20100717101459.GA13626@lordsith.net> To: Marco van Lienen X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@FreeBSD.org Subject: Re: [HEADSUP] ZFS version 15 committed to head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 10:26:03 -0000 Am 17.07.2010 um 12:14 schrieb Marco van Lienen: > # zpool list pool1 > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > pool1 5.44T 147K 5.44T 0% ONLINE - ... > zfs list however only shows: > # zfs list pool1 > NAME USED AVAIL REFER MOUNTPOINT > pool1 91.9K 3.56T 28.0K /pool1 >=20 > I just lost the space of an entire hdd! zpool always shows the raw capacity (without redundancy), zfs the actual = available capacity. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 10:51:35 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEB44106564A for ; Sat, 17 Jul 2010 10:51:35 +0000 (UTC) (envelope-from marco+freebsd-current@lordsith.net) Received: from maul.lordsith.net (unknown [IPv6:2001:7b8:330::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1348FC1E for ; Sat, 17 Jul 2010 10:51:35 +0000 (UTC) Received: by maul.lordsith.net (Postfix, from userid 1001) id 9DB35575471; Sat, 17 Jul 2010 12:51:34 +0200 (CEST) Date: Sat, 17 Jul 2010 12:51:34 +0200 From: Marco van Lienen To: Stefan Bethke Message-ID: <20100717105134.GB13626@lordsith.net> Mail-Followup-To: Marco van Lienen , Stefan Bethke , freebsd-current@FreeBSD.org References: <4C3C7202.7090103@FreeBSD.org> <20100717101459.GA13626@lordsith.net> <9E4FCF4C-7A69-426E-9F39-B5487D4CB07C@lassitu.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline In-Reply-To: <9E4FCF4C-7A69-426E-9F39-B5487D4CB07C@lassitu.de> Organization: LordSith.Net X-Operating-System: FreeBSD 8.0-RELEASE-p2 X-FreeBSD: RULEZ Them All X-GPG-Fingerprint: A025 D8AA AC1B D2FC 380D 4FC1 8EA0 0BA8 8580 E6CB X-GPG-Key: http://lordsith.net/gpgkey X-Uptime: 12:21PM up 6 days, 12:43, 5 users, load averages: 0.00, 0.00, 0.00 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: [HEADSUP] ZFS version 15 committed to head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marco van Lienen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 10:51:35 -0000 --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 17, 2010 at 12:25:56PM +0200, you (Stefan Bethke) sent the foll= owing to the -current list: > Am 17.07.2010 um 12:14 schrieb Marco van Lienen: >=20 > > # zpool list pool1 > > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > > pool1 5.44T 147K 5.44T 0% ONLINE - > ... > > zfs list however only shows: > > # zfs list pool1 > > NAME USED AVAIL REFER MOUNTPOINT > > pool1 91.9K 3.56T 28.0K /pool1 > >=20 > > I just lost the space of an entire hdd! >=20 > zpool always shows the raw capacity (without redundancy), zfs the actual = available capacity. I have read many things about those differences, but why then does zfs on o= pensolaris report more available space whereas FreeBSD does not? That would imply that my friend running osol build 117 couldn't fill up his= raidz pool past the 3.56T. marco --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEAREDAAYFAkxBizYACgkQjqALqIWA5ssr3QCbBLho/OGfLhCmBW5wJXxG+EVQ T+YAniB0uBLqY8c0D8jDjSUoXsDSv/yc =5SB4 -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 11:04:54 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF57A1065677 for ; Sat, 17 Jul 2010 11:04:54 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 5FB618FC1A for ; Sat, 17 Jul 2010 11:04:54 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 867CF85B6C; Sat, 17 Jul 2010 11:04:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20100717105134.GB13626@lordsith.net> Date: Sat, 17 Jul 2010 13:04:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86DB038E-D49B-4793-B966-6B5D29FA3B84@lassitu.de> References: <4C3C7202.7090103@FreeBSD.org> <20100717101459.GA13626@lordsith.net> <9E4FCF4C-7A69-426E-9F39-B5487D4CB07C@lassitu.de> <20100717105134.GB13626@lordsith.net> To: Marco van Lienen X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@FreeBSD.org Subject: RAIDZ capacity (was ZFS version 15 committed to head) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 11:04:55 -0000 Am 17.07.2010 um 12:51 schrieb Marco van Lienen: > On Sat, Jul 17, 2010 at 12:25:56PM +0200, you (Stefan Bethke) sent the = following to the -current list: >> Am 17.07.2010 um 12:14 schrieb Marco van Lienen: >>=20 >>> # zpool list pool1 >>> NAME SIZE USED AVAIL CAP HEALTH ALTROOT >>> pool1 5.44T 147K 5.44T 0% ONLINE - >> ... >>> zfs list however only shows: >>> # zfs list pool1 >>> NAME USED AVAIL REFER MOUNTPOINT >>> pool1 91.9K 3.56T 28.0K /pool1 >>>=20 >>> I just lost the space of an entire hdd! >>=20 >> zpool always shows the raw capacity (without redundancy), zfs the = actual available capacity. >=20 > I have read many things about those differences, but why then does zfs = on opensolaris report more available space whereas FreeBSD does not? > That would imply that my friend running osol build 117 couldn't fill = up his raidz pool past the 3.56T. You didn't show us how your friends pool is set up. With RAIDZ1, the capacity of one of the devices in the pool is used for = redundancy, with RAIDZ2 it's two disks worth. So three 2TB disks with = RAIDZ1 gives you 4TB net capacity. If you don't care about redundancy, = use a simple concatenation, i. e. don't specify mirror, raidz or raidz2 = when creating the pool. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 11:05:13 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 420261065702 for ; Sat, 17 Jul 2010 11:05:13 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from hosting.nash.net.ua (hosting.nash.net.ua [193.151.252.10]) by mx1.freebsd.org (Postfix) with SMTP id 7DC348FC19 for ; Sat, 17 Jul 2010 11:05:12 +0000 (UTC) Received: (qmail 25422 invoked by uid 509); 17 Jul 2010 11:05:10 -0000 Received: from ravenloft.kiev.ua (94.244.131.95) by hosting.nash.net.ua with SMTP; 17 Jul 2010 11:05:10 -0000 Date: Sat, 17 Jul 2010 14:04:39 +0300 From: Alex Kozlov To: Lowell Gilbert , Gabor Kovesdan , freebsd-current@FreeBSD.org, spam@rm-rf.kiev.ua Message-ID: <20100717110439.GA47960@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: Re: periodic script in base system to run csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 11:05:13 -0000 On Fri, Jul 16, 2010 at 07:04:38PM -0400, Lowell Gilbert wrote: > Alex Kozlov writes: > > On Fri, Jul 16, 2010 at 04:27:39PM +0200, Gabor Kovesdan wrote: > >> Em 2010.07.16. 16:23, Alex Kozlov escreveu: > >> > On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: > >> > > >> > Thousands pc simultaneously try to access cvsup servers? > >> > Sound like a ddos to me. > >> Yes, this was the only concern and that's why I started this discussion. > > And because its periodic, We can't use portsnap solution (random delay > > before csup start). > It's not completely impossible; periodic could spin off a separate shell > for it, with a random delay. It's not clear what the best way to deal > with the output would be, although several approaches present themselves. > It would be a lot more complicated than Gabor's approach, though. I think this is overengineering. I personally just put few lines in root's crontab: ? ? * * * * make -C /usr/src update' >/dev/null and /etc/make.conf: SUPHOST=cvsup?.xx.FreeBSD.org SUP_UPDATE= true SUPFILE= /etc/site/supfile-rel #PORTSSUPFILE= /etc/site/supfile-port DOCSUPFILE= /etc/site/supfile-doc -- Adios From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 13:40:42 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AAAD106566B for ; Sat, 17 Jul 2010 13:40:42 +0000 (UTC) (envelope-from michael.gusek@web.de) Received: from fmmailgate04.web.de (fmmailgate04.web.de [217.72.192.242]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB6D8FC19 for ; Sat, 17 Jul 2010 13:40:41 +0000 (UTC) Received: from mwmweb017 ( [172.20.18.26]) by fmmailgate04.web.de (Postfix) with ESMTP id B1F5A684358D for ; Sat, 17 Jul 2010 15:40:40 +0200 (CEST) Received: from [77.184.93.232] by mwmweb017 with HTTP; Sat Jul 17 15:40:40 CEST 2010 Date: Sat, 17 Jul 2010 15:40:40 +0200 (CEST) From: Michael Gusek To: freebsd-current@FreeBSD.org Message-ID: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: normal Sensitivity: Normal X-Provags-ID: V01U2FsdGVkX19Xbg+nh2QURka1X10Pbb/DMAfyAHaJowZPlJ6zpU2J6h2ZUKWcOTPm DEcJ7sh27SVUluPxwebxhbxyyy+wrdTl Cc: Subject: Problem with ZFS version 15 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 13:40:42 -0000 Hi, i updated my 8.1-PRERELEASE to ZFS version 15. The patch http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch applies fine and after reboot i upgrade my pool successfully to version 15. Now, after a new reboot the bootloader can't boot from version 15, it supports only 13. Well, i build a bootable usb pen with 8.1-PRERELEASE and ZFS version 15, boot from it and apply a new bootloader: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0|ad1. After this, i've lost my gpt scheme ! gpart show ad0 says "gpart: No such geom: ad0". How can i recover my gpt on ad0 and ad1 ? I'm running a zfs mirror on ad0 and ad1. Michael ___________________________________________________________ Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 14:25:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AED2A106566B; Sat, 17 Jul 2010 14:25:07 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B4CD48FC13; Sat, 17 Jul 2010 14:25:06 +0000 (UTC) Received: by wyf22 with SMTP id 22so3367673wyf.13 for ; Sat, 17 Jul 2010 07:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=IMyDKc6LgTTM4AYgcgRvP3w7K1k85hldECmOSIhARuA=; b=tzh04YNJ1mVvr/RCLzMI8mVn+fM7xsYmHQbc8h1RaVDzkuF6fSPsdblf7zf+Pa3tlx DfNrDGZGVUO+v4T7QjAzCES1IV+tHO0F9rlg1XT6UmIXhUW4lPSO1vk94+G8YVPGQJr6 B2pUi0tLIOTZ8/uAXkO6cVCYVL3kctnnwk7GE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=o8kZvjH3ViWXrkiSeDPhgwNUZgdUGvHQczTQu2Qe27rv65RNULQuM5gAjye0Bx/FkB /GKCk02osF0nBtRV5rEosPlf8fbBTu9E9AjX1JcKCPzP4FvE8tgVy+/5R+1pV4/po2aL 4YoNys8molOhLQehGRzarWFmpInV7feHAK5yQ= Received: by 10.216.59.131 with SMTP id s3mr1853824wec.71.1279376705443; Sat, 17 Jul 2010 07:25:05 -0700 (PDT) Received: from dragon.dg (41-132-92-33.dsl.mweb.co.za [41.132.92.33]) by mx.google.com with ESMTPS id k46sm1267992weq.10.2010.07.17.07.24.55 (version=SSLv3 cipher=RC4-MD5); Sat, 17 Jul 2010 07:25:03 -0700 (PDT) From: David Naylor Organization: Private To: Doug Barton Date: Sat, 17 Jul 2010 16:24:54 +0200 User-Agent: KMail/1.13.3 (FreeBSD/9.0-CURRENT; KDE/4.4.3; amd64; ; ) References: <201007021146.46542.naylor.b.david@gmail.com> <4C36488A.6030203@freebsd.org> <4C3A2634.5050003@FreeBSD.org> In-Reply-To: <4C3A2634.5050003@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1866925.R1uP5nKUTG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007171624.58434.naylor.b.david@gmail.com> Cc: danfe@freebsd.org, Christian Zander , Yuri Pankov , freebsd-current@freebsd.org, Rene Ladan Subject: Re: nvidia-driver crashing kernel on head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 14:25:07 -0000 --nextPart1866925.R1uP5nKUTG Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sunday 11 July 2010 22:14:44 Doug Barton wrote: > On 07/08/10 14:52, Rene Ladan wrote: > > On 08-07-2010 22:09, Doug Barton wrote: > >> On Thu, 8 Jul 2010, John Baldwin wrote: > >>> These freezes and panics are due to the driver using a spin mutex > >>> instead of a > >>> regular mutex for the per-file descriptor event_mtx. If you patch the > >>> driver > >>> to change it to be a regular mutex I think that should fix the > >>> problems. > >>=20 > >> Can you give an example? :) I don't mind creating a patch for all of > >> them if you can illustrate what needs to be changed. > >=20 > > See the attached patch >=20 > In order to use 195.36.15 it was necessary to use the patch Rene sent, > the suggestion from jhb previously to remove some locks, plus a bit > more. The patch that got it working on HEAD for me (specifically > r209633) is attached. With that patch I could start X, and run it for a > while, but performance was very poor, even in comparison with the stock > nv driver, and it crashed a couple times (although not nearly as bad as > previously). >=20 > So based on other suggestions I tried the newest release version at > nvidia, 256.35. Some of the same locking stuff was needed to patch it, a > patch for the port which includes the locking patch is also attached. If > you are running an amd64 system you'll have to type 'make makesum' after > applying this patch to the port. I'm not sure this patch is complete, or > what Alexey might want to do with the update, but it does create an > accurate plist which means you can cleanly deinstall/pkg_delete when > you're done. >=20 > With 256.35 performance and stability have both been quite good, > comparable even to before the the drama started. The only concern I have > at this point is that I'm periodically getting a strange sort of "flash" > popping up on my screen that I didn't get while I was running the nv > driver recently. It looks sort of like the default X background (the > tiny gray crosshatch) is popping through for just a split second. I've been getting these messages on the console: NVRM: Xid (0001:00): 16, Head 00000000 Count 000218d5 NVRM: Xid (0001:00): 8, Channel 00000000 NVRM: Xid (0001:00): 16, Head 00000000 Count 000218d6 NVRM: Xid (0001:00): 8, Channel 00000002 This is preceded by X locking hard. I cannot VT switch to a normal console= =20 and sometimes the computer needs a hard reset (i.e. does not respond to pow= er=20 button). It appears to only trigger when under heavy load. eg=20 make -C /usr/src -j8 buildworld This seems to be messing with interrupts with other subsystems as my networ= k=20 drivers are less than reliable of late. (Watchdog timeouts). =20 This happens with 195.36.15 unpatched and 256.35 patched. =20 I have not checked if booting with WITNESS enabled works. =20 Regards --nextPart1866925.R1uP5nKUTG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEABECAAYFAkxBvToACgkQUaaFgP9pFrIYJwCeMtleLMXuUh7fadKf7+VtCw56 xZ4Anj/7MWX5TvsTcv5o0n40E/DQqp1v =pbS6 -----END PGP SIGNATURE----- --nextPart1866925.R1uP5nKUTG-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 14:41:49 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73965106566C for ; Sat, 17 Jul 2010 14:41:49 +0000 (UTC) (envelope-from marco+freebsd-current@lordsith.net) Received: from smtp-out3.tiscali.nl (smtp-out3.tiscali.nl [195.241.79.178]) by mx1.freebsd.org (Postfix) with ESMTP id F2F6E8FC16 for ; Sat, 17 Jul 2010 14:41:47 +0000 (UTC) Received: from [82.168.152.67] (helo=lordsith.net) by smtp-out3.tiscali.nl with esmtp (Exim) (envelope-from ) id 1Oa8PB-0003Qd-Q3; Sat, 17 Jul 2010 16:30:17 +0200 Date: Sat, 17 Jul 2010 16:30:03 +0200 From: Marco van Lienen To: Stefan Bethke Message-ID: <20100717143003.GB62874@lordsith.net> Mail-Followup-To: Marco van Lienen , Stefan Bethke , freebsd-current@FreeBSD.org References: <4C3C7202.7090103@FreeBSD.org> <20100717101459.GA13626@lordsith.net> <9E4FCF4C-7A69-426E-9F39-B5487D4CB07C@lassitu.de> <20100717105134.GB13626@lordsith.net> <86DB038E-D49B-4793-B966-6B5D29FA3B84@lassitu.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <86DB038E-D49B-4793-B966-6B5D29FA3B84@lassitu.de> Organization: LordSith.Net X-Operating-System: FreeBSD 8.0-RELEASE-p2 X-FreeBSD: RULEZ Them All X-GPG-Fingerprint: A025 D8AA AC1B D2FC 380D 4FC1 8EA0 0BA8 8580 E6CB X-GPG-Key: http://lordsith.net/gpgkey X-Uptime: 4:24PM up 6 days, 16:46, 7 users, load averages: 0.00, 0.14, 0.12 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: RAIDZ capacity (was ZFS version 15 committed to head) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marco van Lienen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 14:41:49 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 17, 2010 at 01:04:52PM +0200, you (Stefan Bethke) sent the foll= owing to the -current list: > >=20 > > I have read many things about those differences, but why then does zfs = on opensolaris report more available space whereas FreeBSD does not? > > That would imply that my friend running osol build 117 couldn't fill up= his raidz pool past the 3.56T. >=20 > You didn't show us how your friends pool is set up. >=20 > With RAIDZ1, the capacity of one of the devices in the pool is used for r= edundancy, with RAIDZ2 it's two disks worth. So three 2TB disks with RAIDZ= 1 gives you 4TB net capacity. If you don't care about redundancy, use a si= mple concatenation, i. e. don't specify mirror, raidz or raidz2 when creati= ng the pool. My friend created his raidz pool just the same way as I did: zpool create p= ool2 raidz c0d0 c0d1 c0d2 So just 3 dedicated drives. I also posted the example of creating a test raidz pool based on 3 65Mb fil= es. On osol there is more available space being reported by 'zfs list' on that = test raidz pool When I created a similar test raidz pool also based on 3 65Mb files, 'zfs l= ist' on my FreeBSD boxes (9.0-CURRENT amd64 and 8.0-RELEASE-p2 i386) is sho= wing much less available space. So regardless whether we use whole disks or simply files for testing purpos= es, 'zfs list' on the osol system is reporting more available space. cheers, marco --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEAREDAAYFAkxBvmsACgkQjqALqIWA5ssw3ACeNKD0FwbqH9uUrdkDTC4vZlXH CyAAn0VvVciyU0M5/WJ4PBsH38hdiQVl =v0HX -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 17:12:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67AE9106566C for ; Sat, 17 Jul 2010 17:12:12 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7DF8FC14 for ; Sat, 17 Jul 2010 17:12:11 +0000 (UTC) Received: by iwn35 with SMTP id 35so4022986iwn.13 for ; Sat, 17 Jul 2010 10:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=LVKji5m8ycS6zEE5m+Bk+zvHnFimMDmRP6khPBqHij0=; b=TwzcP8hK80bSqiYUvxYEeB/IGZIXr6hrRijdBv82JUEX1904VSn1blyKD0O+o313DA 3++3A/hepsOIpfyjzY//ATjQiLKxbVDeGeMOEgeCZ/bARgYiwrlDmiNAxNFxoE3tgCO4 QPuGJA/T+GUL03IA4zuoHuk0VfnNx+rpGd0qc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=UI6Hr9bVkoTgjLafMDKN1HqOCZiCatnL9s9XiNaJMjXSDidI6elDIytR6orQ/1UWXv dQ3OR6aqOM12QggrXdS0a/b+QUVyDPYgTu2JpVhWXZgpbFnLoJCKSBwuX4xcQeLGBAO8 FbHmF1kK5sHQCQZyo7jieEAZJRo+hitAi3IHw= MIME-Version: 1.0 Received: by 10.231.36.9 with SMTP id r9mr2771373ibd.105.1279386730959; Sat, 17 Jul 2010 10:12:10 -0700 (PDT) Received: by 10.231.12.129 with HTTP; Sat, 17 Jul 2010 10:12:10 -0700 (PDT) In-Reply-To: <20100717105134.GB13626@lordsith.net> References: <4C3C7202.7090103@FreeBSD.org> <20100717101459.GA13626@lordsith.net> <9E4FCF4C-7A69-426E-9F39-B5487D4CB07C@lassitu.de> <20100717105134.GB13626@lordsith.net> Date: Sat, 17 Jul 2010 10:12:10 -0700 Message-ID: From: Freddie Cash To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [HEADSUP] ZFS version 15 committed to head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 17:12:12 -0000 On Sat, Jul 17, 2010 at 3:51 AM, Marco van Lienen wrote: > On Sat, Jul 17, 2010 at 12:25:56PM +0200, you (Stefan Bethke) sent the fo= llowing to the -current list: >> Am 17.07.2010 um 12:14 schrieb Marco van Lienen: >> >> > # zpool list pool1 >> > NAME =C2=A0 =C2=A0SIZE =C2=A0 USED =C2=A0AVAIL =C2=A0 =C2=A0CAP =C2=A0= HEALTH =C2=A0ALTROOT >> > pool1 =C2=A05.44T =C2=A0 147K =C2=A05.44T =C2=A0 =C2=A0 0% =C2=A0ONLIN= E =C2=A0- >> ... >> > zfs list however only shows: >> > # zfs list pool1 >> > NAME =C2=A0 =C2=A0USED =C2=A0AVAIL =C2=A0REFER =C2=A0MOUNTPOINT >> > pool1 =C2=A091.9K =C2=A03.56T =C2=A028.0K =C2=A0/pool1 >> > >> > I just lost the space of an entire hdd! >> >> zpool always shows the raw capacity (without redundancy), zfs the actual= available capacity. > > I have read many things about those differences, but why then does zfs on= opensolaris report more available space whereas FreeBSD does not? > That would imply that my friend running osol build 117 couldn't fill up h= is raidz pool past the 3.56T. You used different commands to check the disk space on OSol (zpool vs df). Try the same commands on both FreeBSD and OSol (zpool and zfs) and you'll see the same results. df works differently on OSol than it does on FreeBSD, you can't compare the= m. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 18:04:36 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E49821065670 for ; Sat, 17 Jul 2010 18:04:34 +0000 (UTC) (envelope-from gavin@ury.york.ac.uk) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id 9857F8FC19 for ; Sat, 17 Jul 2010 18:04:34 +0000 (UTC) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id o6HHWjqY025514 for ; Sat, 17 Jul 2010 18:32:45 +0100 (BST) Received: from gavin (helo=localhost) by ury.york.ac.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1OaBFl-0000VF-Mo for freebsd-current@FreeBSD.org; Sat, 17 Jul 2010 18:32:45 +0100 Date: Sat, 17 Jul 2010 18:32:45 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: freebsd-current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@ury.york.ac.uk Cc: Subject: Filesystem wedge, SUJ-related? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 18:04:37 -0000 Hi guys, Semi-regularly (every two-three days) I'm seeing what appears to be some sort of filesystem wedge. I usually see it initially with web browsers, but it's possible that's only because it's what produces most disk activity on this machine. I've seen it with both Opera and Firefox. What happens is that the process will just wedge. A "procstat -kk" on it shows the following stack backtrace: 9012 100243 firefox-bin initial thread mi_switch+0x21d sleepq_switch+0x123 sleepq_wait+0x4d _sleep+0x357 getdirtybuf+0x21e flush_deplist+0x6f softdep_sync_metadata+0x153 ffs_syncvnode+0x213 ffs_fsync+0x43 fsync+0x148 syscallenter+0x1b5 syscall+0x4c Xfast_syscall+0xe2 8954 100231 opera initial thread mi_switch+0x21d sleepq_switch+0x123 sleepq_wait+0x4d _sleep+0x357 getdirtybuf+0x21e flush_deplist+0x6f softdep_sync_metadata+0x153 ffs_syncvnode+0x213 ffs_fsync+0x43 fsync+0x148 syscallenter+0x1b5 syscall+0x4c Xfast_syscall+0xe2 Reading from the disk is fine, indeed writing to the disk seems to work fine for other applications, even once a browser has wedged. I've included the output of "sysctl -a | grep debug.softdep" later in the email, in case it gives any clues. This was taken while the system was idle, about an hour after both Firefox and Opera had wedged. As I say, this happens every few days, so please let me know what further information can be useful to diagnose this. I can get info from the debugger too - but as I don't have much experience diagnosing FS issues somebody needs to tell me which info to obtain other than the standard (alltrace, ps, etc). Thanks, Gavin debug.softdep.jwait_newblk: 3 debug.softdep.jwait_inode: 44 debug.softdep.jwait_freeblks: 115 debug.softdep.jwait_filepage: 181 debug.softdep.journal_wait: 15488 debug.softdep.journal_min: 0 debug.softdep.journal_low: 0 debug.softdep.jnewblk_rollback: 27953 debug.softdep.jaddref_rollback: 1811 debug.softdep.dir_entry: 23248 debug.softdep.direct_blk_ptrs: 5975 debug.softdep.inode_bitmap: 8631 debug.softdep.indir_blk_ptrs: 7670 debug.softdep.sync_limit_hit: 0 debug.softdep.ino_limit_hit: 0 debug.softdep.blk_limit_hit: 0 debug.softdep.ino_limit_push: 0 debug.softdep.blk_limit_push: 0 debug.softdep.worklist_push: 0 debug.softdep.maxindirdeps: 50 debug.softdep.tickdelay: 2 debug.softdep.max_softdeps: 400000 debug.softdep.current.jtrunc: 0 debug.softdep.current.sbdep: 0 debug.softdep.current.jsegdep: 5218 debug.softdep.current.jseg: 3921 debug.softdep.current.jfreefrag: 0 debug.softdep.current.jfreeblk: 0 debug.softdep.current.jnewblk: 0 debug.softdep.current.jmvref: 0 debug.softdep.current.jremref: 0 debug.softdep.current.jaddref: 11 debug.softdep.current.freedep: 18 debug.softdep.current.freework: 4666 debug.softdep.current.newdirblk: 0 debug.softdep.current.dirrem: 122 debug.softdep.current.mkdir: 0 debug.softdep.current.diradd: 132 debug.softdep.current.freefile: 2 debug.softdep.current.freeblks: 4198 debug.softdep.current.freefrag: 0 debug.softdep.current.allocindir: 0 debug.softdep.current.indirdep: 4 debug.softdep.current.allocdirect: 0 debug.softdep.current.newblk: 255 debug.softdep.current.bmsafemap: 3 debug.softdep.current.inodedep: 284 debug.softdep.current.pagedep: 119 debug.softdep.total.jtrunc: 114 debug.softdep.total.sbdep: 6109 debug.softdep.total.jsegdep: 489669 debug.softdep.total.jseg: 23468 debug.softdep.total.jfreefrag: 67993 debug.softdep.total.jfreeblk: 53638 debug.softdep.total.jnewblk: 180654 debug.softdep.total.jmvref: 160 debug.softdep.total.jremref: 95199 debug.softdep.total.jaddref: 92071 debug.softdep.total.freedep: 1044 debug.softdep.total.freework: 57287 debug.softdep.total.newdirblk: 267 debug.softdep.total.dirrem: 95173 debug.softdep.total.mkdir: 490 debug.softdep.total.diradd: 91573 debug.softdep.total.freefile: 67115 debug.softdep.total.freeblks: 38486 debug.softdep.total.freefrag: 67993 debug.softdep.total.allocindir: 0 debug.softdep.total.indirdep: 3798 debug.softdep.total.allocdirect: 0 debug.softdep.total.newblk: 180654 debug.softdep.total.bmsafemap: 11319 debug.softdep.total.inodedep: 197151 debug.softdep.total.pagedep: 89352 From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 18:04:49 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7C3E1065745 for ; Sat, 17 Jul 2010 18:04:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC208FC18 for ; Sat, 17 Jul 2010 18:04:47 +0000 (UTC) Received: (qmail 3849 invoked by uid 399); 17 Jul 2010 18:04:47 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Jul 2010 18:04:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sat, 17 Jul 2010 11:04:44 -0700 (PDT) From: Doug Barton To: Rui Paulo In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 18:04:49 -0000 On Sat, 17 Jul 2010, Rui Paulo wrote: > > On 17 Jul 2010, at 08:17, Doug Barton wrote: > >> This is happening after I open a flash video in firefox and watch it for >>> 15 minutes: >> >> root 20 -80 - 0K 160K WAIT 0 3:38 14.08% intr >> >> After this happens, my system goes into a death spiral and I have to shut it down. >> >> vmstat -i >> interrupt total rate >> irq1: atkbd0 10384 0 >> irq9: acpi0 5 0 >> irq14: ata0 153410 7 >> irq15: ata1 58 0 >> irq17: wpi0 534038 27 >> irq20: hpet0 uhci0+ 2496833 129 >> irq22: uhci2 66485 3 >> cpu0:timer 19238037 999 >> irq256: hdac0 189713 9 >> cpu1:timer 19236431 999 >> Total 41925394 2178 >> >> >> Any suggestions? current (r210135), i386 smp. Dell C2D laptop. > > What's vmstat -i before the event happens? Here is the output after a clean boot: interrupt total rate irq1: atkbd0 424 4 irq9: acpi0 2 0 irq14: ata0 3266 30 irq15: ata1 58 0 irq17: wpi0 2012 18 irq20: hpet0 uhci0+ 13763 129 irq22: uhci2 16 0 cpu0:timer 105150 991 irq256: hdac0 10 0 cpu1:timer 103716 978 Total 228417 2154 Thanks for the response, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 18:21:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F1541065673 for ; Sat, 17 Jul 2010 18:21:35 +0000 (UTC) (envelope-from marco+freebsd-current@lordsith.net) Received: from maul.lordsith.net (maul.lordsith.net [IPv6:2001:7b8:330::1]) by mx1.freebsd.org (Postfix) with ESMTP id 306EA8FC1E for ; Sat, 17 Jul 2010 18:21:35 +0000 (UTC) Received: by maul.lordsith.net (Postfix, from userid 1001) id E7122575477; Sat, 17 Jul 2010 20:21:33 +0200 (CEST) Date: Sat, 17 Jul 2010 20:21:33 +0200 From: Marco van Lienen To: Freddie Cash Message-ID: <20100717182133.GA63078@lordsith.net> Mail-Followup-To: Marco van Lienen , Freddie Cash , freebsd-current@freebsd.org References: <4C3C7202.7090103@FreeBSD.org> <20100717101459.GA13626@lordsith.net> <9E4FCF4C-7A69-426E-9F39-B5487D4CB07C@lassitu.de> <20100717105134.GB13626@lordsith.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: LordSith.Net X-Operating-System: FreeBSD 8.0-RELEASE-p2 X-FreeBSD: RULEZ Them All X-GPG-Fingerprint: A025 D8AA AC1B D2FC 380D 4FC1 8EA0 0BA8 8580 E6CB X-GPG-Key: http://lordsith.net/gpgkey X-Uptime: 8:16PM up 6 days, 20:38, 6 users, load averages: 0.03, 0.01, 0.00 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] ZFS version 15 committed to head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marco van Lienen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 18:21:35 -0000 On Sat, Jul 17, 2010 at 10:12:10AM -0700, you (Freddie Cash) sent the following to the -current list: > > > > I have read many things about those differences, but why then does zfs on opensolaris report more available space whereas FreeBSD does not? > > That would imply that my friend running osol build 117 couldn't fill up his raidz pool past the 3.56T. > > You used different commands to check the disk space on OSol (zpool vs df). > > Try the same commands on both FreeBSD and OSol (zpool and zfs) and > you'll see the same results. I guess you missed my original mail of this thread in which I also showed the output of 'zfs list -r pool2' on osol where clearly there is more available space shown then on FreeBSD. % zfs list -r pool2 NAME USED AVAIL REFER MOUNTPOINT pool2 3.32T 2.06T 3.18T /export/pool2 > > df works differently on OSol than it does on FreeBSD, you can't compare them. HTH From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 18:24:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39998106566B; Sat, 17 Jul 2010 18:24:38 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id F093C8FC08; Sat, 17 Jul 2010 18:24:37 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id EA5C7157548; Sat, 17 Jul 2010 13:24:36 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id AXJXBIBJ8J7B; Sat, 17 Jul 2010 13:24:36 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Sat, 17 Jul 2010 19:24:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Doug Barton X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@FreeBSD.org Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 18:24:38 -0000 On 17 Jul 2010, at 19:04, Doug Barton wrote: > On Sat, 17 Jul 2010, Rui Paulo wrote: >=20 >>=20 >> On 17 Jul 2010, at 08:17, Doug Barton wrote: >>=20 >>> This is happening after I open a flash video in firefox and watch it = for >>>> 15 minutes: >>>=20 >>> root 20 -80 - 0K 160K WAIT 0 3:38 14.08% intr >>>=20 >>> After this happens, my system goes into a death spiral and I have to = shut it down. >>>=20 >>> vmstat -i >>> interrupt total rate >>> irq1: atkbd0 10384 0 >>> irq9: acpi0 5 0 >>> irq14: ata0 153410 7 >>> irq15: ata1 58 0 >>> irq17: wpi0 534038 27 >>> irq20: hpet0 uhci0+ 2496833 129 >>> irq22: uhci2 66485 3 >>> cpu0:timer 19238037 999 >>> irq256: hdac0 189713 9 >>> cpu1:timer 19236431 999 >>> Total 41925394 2178 >>>=20 >>>=20 >>> Any suggestions? current (r210135), i386 smp. Dell C2D laptop. >>=20 >> What's vmstat -i before the event happens? >=20 > Here is the output after a clean boot: >=20 > interrupt total rate > irq1: atkbd0 424 4 > irq9: acpi0 2 0 > irq14: ata0 3266 30 > irq15: ata1 58 0 > irq17: wpi0 2012 18 > irq20: hpet0 uhci0+ 13763 129 > irq22: uhci2 16 0 > cpu0:timer 105150 991 > irq256: hdac0 10 0 > cpu1:timer 103716 978 > Total 228417 2154 >=20 > Thanks for the response, This doesn't indicate any problem. I suggest you try to figure out what = interrupt is causing this by adding printfs or disabling drivers one by = one. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 15:19:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13A9C1065677; Sat, 17 Jul 2010 15:19:55 +0000 (UTC) (envelope-from rpaulo@lavabit.com) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id DAD328FC12; Sat, 17 Jul 2010 15:19:54 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 033DB11BADC; Sat, 17 Jul 2010 10:19:54 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id FZND69FXCUCW; Sat, 17 Jul 2010 10:19:53 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=CdQEVcxqItHOsAPHuDe2sD8a+goJwPLQjiyVJs86rOLM2HImI96UojNx7xTQxEpVlNlI05VW7TcHOb99pQGK4xIZFlO2DjWZABi/FINzS16TUtGE6860tb0x4x8yrJ26dQKxud0X2VSg2nClRWGFSzmThQcq0d38e16iAy79aag=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Sat, 17 Jul 2010 16:19:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Doug Barton X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sat, 17 Jul 2010 18:45:36 +0000 Cc: freebsd-current@FreeBSD.org Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 15:19:55 -0000 On 17 Jul 2010, at 08:17, Doug Barton wrote: > This is happening after I open a flash video in firefox and watch it = for=20 >> 15 minutes: >=20 > root 20 -80 - 0K 160K WAIT 0 3:38 14.08% intr >=20 > After this happens, my system goes into a death spiral and I have to = shut it down. >=20 > vmstat -i > interrupt total rate > irq1: atkbd0 10384 0 > irq9: acpi0 5 0 > irq14: ata0 153410 7 > irq15: ata1 58 0 > irq17: wpi0 534038 27 > irq20: hpet0 uhci0+ 2496833 129 > irq22: uhci2 66485 3 > cpu0:timer 19238037 999 > irq256: hdac0 189713 9 > cpu1:timer 19236431 999 > Total 41925394 2178 >=20 >=20 > Any suggestions? current (r210135), i386 smp. Dell C2D laptop. What's vmstat -i before the event happens? Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 18:46:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A3031065674 for ; Sat, 17 Jul 2010 18:46:28 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id F22088FC0C for ; Sat, 17 Jul 2010 18:46:27 +0000 (UTC) Received: by iwn35 with SMTP id 35so4088206iwn.13 for ; Sat, 17 Jul 2010 11:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=l0mqB5BsQ010qkcp20rncfpDRElNQwu6s1K8h7GN+Jo=; b=EYAyN7KWEh3I8ZM9oLm4zcUV+TGQMT7WKviAeUQrjq1Pg+eNKiaLeAVmN8iw7IKA20 zDrA/azcRRxFldAyfztSYnoGaFi0UjnHoSfnDA75k3JT0in6Losm8tOf/IwfiR9r0PiF jHqD7mHfWSReBOyeWvbqMBa/srW3LGddCXZEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=FQvQt/0FqxrKIbkpdKBXQmdUnCcF5Pp9GkueNdAkYckL5nt8x4AOt3lGXM+823xedv SGDhjA6ZRiAbOcVD50oc3cMsQ2yeF6W2rwCfDdLeO0lq7z+5m6XAqoNw+Gn+zP6ijpbU vzrC8bfD9MoseSUoKs8P/N2dezlybZVDThZJs= MIME-Version: 1.0 Received: by 10.231.157.143 with SMTP id b15mr3027069ibx.113.1279392387260; Sat, 17 Jul 2010 11:46:27 -0700 (PDT) Received: by 10.231.12.129 with HTTP; Sat, 17 Jul 2010 11:46:27 -0700 (PDT) In-Reply-To: <20100717182133.GA63078@lordsith.net> References: <4C3C7202.7090103@FreeBSD.org> <20100717101459.GA13626@lordsith.net> <9E4FCF4C-7A69-426E-9F39-B5487D4CB07C@lassitu.de> <20100717105134.GB13626@lordsith.net> <20100717182133.GA63078@lordsith.net> Date: Sat, 17 Jul 2010 11:46:27 -0700 Message-ID: From: Freddie Cash To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [HEADSUP] ZFS version 15 committed to head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 18:46:28 -0000 On Sat, Jul 17, 2010 at 11:21 AM, Marco van Lienen wrote: > On Sat, Jul 17, 2010 at 10:12:10AM -0700, you (Freddie Cash) sent the fol= lowing to the -current list: >> > >> > I have read many things about those differences, but why then does zfs= on opensolaris report more available space whereas FreeBSD does not? >> > That would imply that my friend running osol build 117 couldn't fill u= p his raidz pool past the 3.56T. >> >> You used different commands to check the disk space on OSol (zpool vs df= ). >> >> Try the same commands on both FreeBSD and OSol (zpool and zfs) and >> you'll see the same results. > > I guess you missed my original mail of this thread in which I also showed= the output of 'zfs list -r pool2' on osol where clearly there is more avai= lable space shown then on FreeBSD. > > % zfs list -r pool2 > NAME =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0USED =C2=A0AVAIL =C2=A0REFER =C2=A0MOUNTPOINT > pool2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A03.32T =C2=A02.06T =C2=A03.18T =C2=A0/export/pool2 No, I saw that. But you compared zpool and zfs output on FreeBSD, and zfs and df output on OSol. IOW, you didn't compare the same things. Compare the output of zpool and zfs on both FreeBSD and OSol, it should be the same. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 19:10:29 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 957AD106564A for ; Sat, 17 Jul 2010 19:10:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 223CE8FC16 for ; Sat, 17 Jul 2010 19:10:28 +0000 (UTC) Received: (qmail 24149 invoked by uid 399); 17 Jul 2010 19:10:28 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Jul 2010 19:10:28 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sat, 17 Jul 2010 12:10:26 -0700 (PDT) From: Doug Barton To: Rui Paulo In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 19:10:29 -0000 On Sat, 17 Jul 2010, Rui Paulo wrote: > This doesn't indicate any problem. I suggest you try to figure out what interrupt is causing this by adding printfs or disabling drivers one by one. I've no idea where to even begin on something like that. Given that there are other -current users who are also having problems (particularly with the nvidia drivers) I'm wondering if some sort of systemic debugging isn't in order here? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 19:11:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81F3D106568F; Sat, 17 Jul 2010 19:11:16 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 5819A8FC18; Sat, 17 Jul 2010 19:11:16 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id A7BDC157548; Sat, 17 Jul 2010 14:11:15 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id MUX4PVPC74S6; Sat, 17 Jul 2010 14:11:15 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Sat, 17 Jul 2010 20:11:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Doug Barton X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@FreeBSD.org Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 19:11:16 -0000 On 17 Jul 2010, at 20:10, Doug Barton wrote: > On Sat, 17 Jul 2010, Rui Paulo wrote: >=20 >> This doesn't indicate any problem. I suggest you try to figure out = what interrupt is causing this by adding printfs or disabling drivers = one by one. >=20 > I've no idea where to even begin on something like that. Given that = there are other -current users who are also having problems = (particularly with the nvidia drivers) I'm wondering if some sort of = systemic debugging isn't in order here? You can try bisecting the faulty revision. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 19:18:07 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FCCC1065674 for ; Sat, 17 Jul 2010 19:18:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id D049D8FC15 for ; Sat, 17 Jul 2010 19:18:06 +0000 (UTC) Received: (qmail 2321 invoked by uid 399); 17 Jul 2010 19:18:05 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Jul 2010 19:18:05 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sat, 17 Jul 2010 12:18:04 -0700 (PDT) From: Doug Barton To: Rui Paulo In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 19:18:07 -0000 On Sat, 17 Jul 2010, Rui Paulo wrote: > You can try bisecting the faulty revision. The problem has been going on for months, the primary symptom for a long time was the nvidia driver, so I stopped using it for a while hoping that a solution would magically appear. As of the last 6 weeks or so the problem has started happening even without using the nvidia driver, and more users are reporting similar symptoms. So in short, no, I won't be doing that, as there is way too much history to slog back through at this point. What I would like to see is some sort of effort on the part of those who've made the changes to help debug what's wrong with them. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 19:21:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42135106564A; Sat, 17 Jul 2010 19:21:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AA2558FC0A; Sat, 17 Jul 2010 19:21:32 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o6HJLSbG054127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Jul 2010 22:21:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o6HJLSnq005169; Sat, 17 Jul 2010 22:21:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6HJLSUY005168; Sat, 17 Jul 2010 22:21:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 17 Jul 2010 22:21:28 +0300 From: Kostik Belousov To: Doug Barton Message-ID: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Jaerp9zHWz52Eeko" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 19:21:33 -0000 --Jaerp9zHWz52Eeko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 17, 2010 at 12:10:26PM -0700, Doug Barton wrote: > On Sat, 17 Jul 2010, Rui Paulo wrote: >=20 > >This doesn't indicate any problem. I suggest you try to figure out what= =20 > >interrupt is causing this by adding printfs or disabling drivers one by= =20 > >one. >=20 > I've no idea where to even begin on something like that. Given that=20 > there are other -current users who are also having problems=20 > (particularly with the nvidia drivers) I'm wondering if some sort of=20 > systemic debugging isn't in order here? >=20 Note that intr time most likely come from the interrupt threads chewing the CPU, not from the real interrupt handlers doing something, and definite= ly not due to the high interrupt rate, as your vmstat -i output already shown. Run top in the mode where all system threads are shown separately (e.g. top -HS seems to do it), then watch what thread eats the processor. --Jaerp9zHWz52Eeko Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxCArgACgkQC3+MBN1Mb4i/6wCfQ1RzUrMRGCNqHJrzYjD+cdu9 hMUAoJPUz/3Y17X8GDufNYEMJSBmEAQL =GvvQ -----END PGP SIGNATURE----- --Jaerp9zHWz52Eeko-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 19:23:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 224A11065670 for ; Sat, 17 Jul 2010 19:23:26 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id A1F078FC12 for ; Sat, 17 Jul 2010 19:23:25 +0000 (UTC) Received: (qmail 10486 invoked by uid 399); 17 Jul 2010 19:23:24 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Jul 2010 19:23:24 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sat, 17 Jul 2010 12:23:23 -0700 (PDT) From: Doug Barton To: Kostik Belousov In-Reply-To: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> Message-ID: References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 19:23:26 -0000 On Sat, 17 Jul 2010, Kostik Belousov wrote: > Note that intr time most likely come from the interrupt threads chewing > the CPU, not from the real interrupt handlers doing something, and definitely > not due to the high interrupt rate, as your vmstat -i output already shown. > > Run top in the mode where all system threads are shown separately > (e.g. top -HS seems to do it), then watch what thread eats the processor. Ok, thanks, I'll definitely do that next time and report the results. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 20:53:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956E8106566B for ; Sat, 17 Jul 2010 20:53:39 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 490A58FC14 for ; Sat, 17 Jul 2010 20:53:38 +0000 (UTC) Received: by gxk24 with SMTP id 24so2208034gxk.13 for ; Sat, 17 Jul 2010 13:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=EOOzkuCVJNMnZ6yJfCGjvoj5fOwD08gvVfdV6hEXlNM=; b=cww8tiV47sxSVSi37RVGbKFZKrkIkUQx2YbsGU96/3auqrCkZ/f5wqkALsY2uLyPEt f6tnepojYf0v1kLjt/hxdhdMEtdzEo1GDcecjDf7gwLWQ9LK4F8g4je5aEMSwuu4+kLF 523b03jH66feRB1KsYr+mxhu31murQg5m/HU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=GFI0ct8cMox4Eob6hcxQg+M0mQI5MEFvBcibCN1jqhRN0tuavapqXve0YUmsMpHgkH knj7mY/iqDOrmd/TSrblluYPRwuISwSLiPzv0d/Yr4wwiKAv9qADyDBUII8mEWy9OfIC +Rtw0OdPySAkEqXtrvjaI+e7AQJ0VQQcQPrVs= Received: by 10.150.210.14 with SMTP id i14mr2797319ybg.423.1279400017012; Sat, 17 Jul 2010 13:53:37 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id q21sm3730565ybk.11.2010.07.17.13.53.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Jul 2010 13:53:34 -0700 (PDT) Sender: "J. Hellenthal" Date: Sat, 17 Jul 2010 16:53:26 -0400 From: jhell To: Gabor Kovesdan In-Reply-To: <4C406589.7030705@FreeBSD.org> Message-ID: References: <4C406589.7030705@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current Subject: Re: periodic script in base system to run csup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 20:53:39 -0000 On Fri, 16 Jul 2010 09:58, Gabor Kovesdan wrote: In Message-Id: <4C406589.7030705@FreeBSD.org> > Hi folks, > > Steven Kreuzer wrote a periodic script to run csup updates with periodic > daily. I've reviewed it and added support for multiple supfiles. I'd like to > commit this to head. > : http://kovesdan.org/files/600.csup : : Is there any objection? In a message listed in this thread someone has mentioned that this can already be done from cron. ( make -C /usr/src update ) at your own preferred time of updating. No offense but including something like this into the periodic system without a way to randomize the time at which it will actually run would be irresponsible while wreaking havoc on the source servers and I would strongly advise against it. *** If a way to randomize the time at which this is run is conceived and you wish to proceed I would also strongly advise that it is moved to a periodic weekly location instead. *** Personally I see updating your source tree as a interactive process unless for the use of a mirroring server which is not needed on every machine this would end up on. Adding this I only see results of blatant enabling the controls creating pointless mirrors. Maybe adding this to src/tools would be a better place or creating a port for this. With all do respect & Regards, -- jhell,v From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 21:03:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C76B9106566B; Sat, 17 Jul 2010 21:03:35 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 4BCD88FC08; Sat, 17 Jul 2010 21:03:34 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-8-131.flashcable.ch [91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id o6HL3WQE055820; Sat, 17 Jul 2010 23:03:32 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4C421AA4.3050304@fgznet.ch> Date: Sat, 17 Jul 2010 23:03:32 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: Edward Tomasz Napierala , freebsd-current References: <201007171545.o6HFjKex070603@svn.freebsd.org> In-Reply-To: <201007171545.o6HFjKex070603@svn.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Subject: Re: svn commit: r210194 - head/sys/fs/unionfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 21:03:35 -0000 On 17.07.10 17:45, Edward Tomasz Napierala wrote: > Author: trasz > Date: Sat Jul 17 15:45:20 2010 > New Revision: 210194 > URL: http://svn.freebsd.org/changeset/base/210194 > > Log: > Remove updating process count by unionfs. It serves no purpose, unionfs just > needs root credentials for a moment. > > Modified: > head/sys/fs/unionfs/union_subr.c > > Modified: head/sys/fs/unionfs/union_subr.c > ============================================================================== > --- head/sys/fs/unionfs/union_subr.c Sat Jul 17 13:34:01 2010 (r210193) > +++ head/sys/fs/unionfs/union_subr.c Sat Jul 17 15:45:20 2010 (r210194) > @@ -50,7 +50,6 @@ > #include > #include > #include > -#include > > #include > > @@ -775,7 +774,6 @@ unionfs_mkshadowdir(struct unionfs_mount > /* Authority change to root */ > rootinfo = uifind((uid_t)0); > cred = crdup(cnp->cn_cred); > - chgproccnt(cred->cr_ruidinfo, 1, 0); > change_euid(cred, rootinfo); > change_ruid(cred, rootinfo); > change_svuid(cred, (uid_t)0); > @@ -825,7 +823,6 @@ unionfs_mkshadowdir_free_out: > > unionfs_mkshadowdir_abort: > cnp->cn_cred = credbk; > - chgproccnt(cred->cr_ruidinfo, -1, 0); > crfree(cred); > > return (error); > _______________________________________________ > svn-src-head@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscribe@freebsd.org" > > cc1: warnings being treated as errors /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c: In function 'unionfs_mkshadowdir': /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:775: warning: implicit declaration of function 'uifind' /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:775: warning: nested extern declaration of 'uifind' /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:775: warning: assignment makes pointer from integer without a cast /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:780: warning: implicit declaration of function 'uifree' /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:780: warning: nested extern declaration of 'uifree' Hm, I'd like to include this one again: [tc:fbsd/head/src] andreast% svn diff sys/fs/unionfs/union_subr.c Index: sys/fs/unionfs/union_subr.c =================================================================== --- sys/fs/unionfs/union_subr.c (revision 210200) +++ sys/fs/unionfs/union_subr.c (working copy) @@ -50,6 +50,7 @@ #include #include #include +#include #include Gruss, Andreas