From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 00:04:01 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F39F106566B; Sun, 10 Jul 2011 00:04:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1AC388FC16; Sun, 10 Jul 2011 00:04:01 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p6A028KC010589 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 9 Jul 2011 18:02:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201107080919.58210.jhb@freebsd.org> Date: Sat, 9 Jul 2011 18:02:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7CC3B2A2-C372-4E11-9782-19691FD58850@bsdimp.com> References: <4E100086.7080105@FreeBSD.org> <201107071720.50203.jhb@freebsd.org> <4E16C463.9020604@FreeBSD.org> <201107080919.58210.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 09 Jul 2011 18:02:09 -0600 (MDT) Cc: freebsd-current@FreeBSD.org, Doug Barton Subject: Re: cardbus panic: end address is not aligned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2011 00:04:01 -0000 I'm also interested in this problem too if it is in the CardBus layer. = This sounds like a problem with jhb's latest pci resource stuff, since = that code is shared with CardBus... Another alternative to crashdups is a serial console :) I've not seen this, but haven't tried two ATH cards in a laptop in about = three years... Chances are really good, however, that it has nothing to = do with ath, other than the specific sizes and numbers of resources it = tries to allocate... Warner On Jul 8, 2011, at 7:19 AM, John Baldwin wrote: > On Friday, July 08, 2011 4:48:35 am Doug Barton wrote: >> On 07/07/2011 14:20, John Baldwin wrote: >>> On Sunday, July 03, 2011 1:39:18 am Doug Barton wrote: >>>> I have 2 ath-based pc-card adapters. If I put either one of them in = the=20 >>>> slot while the system is up, or if I try booting with them in the = slot,=20 >>>> I get an instant panic. The cards previously worked in -current, = and=20 >>>> continue to work in 8-stable and windows xp. I don't have any other=20= >>>> pc-cards to compare with. Full core.txt.0 file is in my home = directory=20 >>>> on freefall. >>>>=20 >>>> This problem persists on r223732 but happened to me for the first = time a=20 >>>> week or 2 ago (haven't had time to report it previously, = apologies). It=20 >>>> likely originated a while before though, I don't use these cards = very=20 >>>> often. >>>>=20 >>>> panic: end address is not aligned >>>>=20 >>>> #1 0xffffffff80426a8a in kern_reboot (howto=3D260) >>>> at /home/svn/head/sys/kern/kern_shutdown.c:430 >>>> #2 0xffffffff80426521 in panic (fmt=3DVariable "fmt" is not = available. >>>> ) >>>> at /home/svn/head/sys/kern/kern_shutdown.c:604 >>>> #3 0xffffffff8032c648 in pcib_grow_window (sc=3D0xfffffe0002603400, >>>> w=3D0xfffffe0002603498, type=3D3, start=3D0, end=3D4294967295, = count=3D65536,=20 >>>> flags=3DVariable "flags" is not available. >>>=20 >>> The line is here: >>>=20 >>> KASSERT((w->limit & ((1ul << w->step) - 1)) =3D=3D (1ul << = w->step) - 1, >>> ("end address is not aligned")); >>>=20 >>> Can you run kgdb and do 'frame 3' and 'p/x *w'? >>=20 >> (kgdb) frame 3 >> #3 0xffffffff8032c648 in pcib_grow_window (sc=3D0xfffffe0002603400, >> w=3D0xfffffe0002603498, type=3D3, start=3D0, end=3D4294967295, = count=3D65536, >> flags=3DVariable "flags" is not available. >> ) >> at /home/svn/head/sys/dev/pci/pci_pci.c:1018 >> 1018 KASSERT((w->limit & ((1ul << w->step) - 1)) =3D=3D (1ul = << w->step) - 1, >> (kgdb) p/x *w >> $1 =3D {base =3D 0x80000000, limit =3D 0x8800ffff, rman =3D {rm_list = =3D { >> tqh_first =3D 0xfffffe0002702a00, tqh_last =3D = 0xfffffe0002702a98}, >> rm_mtx =3D 0xfffffe00024e20e0, rm_link =3D {tqe_next =3D = 0xfffffe0002603520, >> tqe_prev =3D 0xfffffe0002603448}, rm_start =3D 0x0, rm_end =3D = 0xffffffff, >> rm_type =3D 0x2, rm_descr =3D 0xfffffe0002608060}, res =3D >> 0xfffffe0002702b00, >> reg =3D 0x20, valid =3D 0x1, mask =3D 0x2, step =3D 0x14, name =3D >> 0xffffffff8071b77c} >=20 > Hmm, well that's odd. It didn't grow it enough it seems. >=20 >>> Also, can you boot your machine, then do 'sysctl = debug.bootverbose=3D1', insert=20 >>> the card and record the messages in dmesg when it does? (You can = likely get=20 >>> those out of kgdb.) >>=20 >> The system panics instantly when I insert the cards. Would a verbose >> dmesg entry from 8.2-stable work? I can do that on the same hardware. >> If not I can try it on -current and see if anything gets logged. >=20 > Err, if you can get a crashdump, you can use 'printf "%s", = msgbufp->msg_ptr' > in kgdb to output all of dmseg. You can also use the 'dmesg' command = against > a crash dump directly, and if you have crashinfo enabled, the tail of = the > core.txt.N file in /var/crash will have the full dmesg in it as well. >=20 > The real messages I will want to see are in the dmesg. Also, getting = the > output of 'devinfo -r' before you insert the card would also be = helpful so > I can see what it is growing from. >=20 > Actually, forgo all that. Try this patch: >=20 > Index: pci_pci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- pci_pci.c (revision 223847) > +++ pci_pci.c (working copy) > @@ -954,7 +954,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci > if (bootverbose) > printf("\tback candidate range: = %#lx-%#lx\n", > start_free, back); > - back =3D roundup2(back + 1, w->step) - 1; > + back =3D roundup2(back + 1, 1ul << w->step) - 1; > back -=3D rman_get_end(w->res); > } else > back =3D 0; >=20 > --=20 > John Baldwin > _______________________________________________ > 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 >=20 From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 00:04:08 2011 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 CA897106564A for ; Sun, 10 Jul 2011 00:04:08 +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 8A2A58FC14 for ; Sun, 10 Jul 2011 00:04:08 +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 0AFE846B2A for ; Sat, 9 Jul 2011 20:04:08 -0400 (EDT) Received: from [192.168.1.55] (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7C94F8A02C for ; Sat, 9 Jul 2011 20:04:07 -0400 (EDT) From: John Baldwin Date: Sat, 9 Jul 2011 20:04:07 -0400 Message-Id: <4CE54A1B-B0EF-4907-88BE-124FC4FF236D@FreeBSD.org> To: current@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Sat, 09 Jul 2011 20:04:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: [PATCH] Make x86 Host-PCI bridge drivers honor decoded ranges X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2011 00:04:08 -0000 This patch adds a new API (pcib_host_res_*) that Host-PCI bridge drivers = can=20 use to restrict allocations for child devices to a known subset of = address=20 ranges that the bridge decodes. Originally I tried to allocate the full=20= ranges and use rmans just as we now do for PCI-PCI bridge windows. = However,=20 this broke due to the fact that all of our ACPI LPC/ISA devices attach = at the=20 "wrong" place in the tree (they aren't behind the host-PCI bridges) and = a=20 typical ACPI BIOS will allocate the full I/O port range to the host-PCI=20= bridge. We could perhaps fix this later if we relocate all the ACPI = devices=20 that are actually ISA devices down onto an ACPI-aware ISA bus (i.e. an = ISA bus=20 that uses ACPI to enumerate devices). Anyway, I punted on that for now. = =20 Instead, the current API works by using a resource_list to keep track of = all=20 the valid address ranges. When an allocation request is made, it simply = tries=20 all the address ranges in turn. I still made it honor = hw.pci.host_mem_start=20 since the ACPI BIOSes I have seen will optionally include option ROM = space=20 below 1MB if any ROMs are active, but we don't want to allocate that = space for=20 a wildcard BAR operation. I've changed the ACPI and MPTable Host-PCI bridge drivers to use this = helper=20 API. For ACPI we claim that bridges decode any "producer" address = ranges in=20 the bridges _CRS. For the MPTable I had to add logic to walk the = extended=20 MPTable entries and use those extended entries to find the list of = decoded=20 ranges. I'd like to get this into 9.0 and would appreciate folks = testing it out. http://www.FreeBSD.org/~jhb/patches/pci_host_res.patch --=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 00:08:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C8E5106566C for ; Sun, 10 Jul 2011 00:08:51 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 02BE88FC14 for ; Sun, 10 Jul 2011 00:08:51 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id AC44C60E5; Sat, 9 Jul 2011 20:08:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1310256529; bh=QZ6jykHAF8eR73RyMQB0sT6YHbFL61aM2e6c7gdjJFw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=gFeqnQQaJVT5nUpoxD+n9JsVTxm6eNGrgRCsw1x6X3fw8shbTHB7T5KEKsGVVAsTF vPW4vQtrYq2Fqs6+T6IC/Dcs50PYLk4xJU1jh0GH6ZGeNpRqCkhydcLFiqmFY0c DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type; b=CVWGitJCRKCSbNmqZCoxdavUl/RYRo+vc8Hd4FAo5aNDppOKNrnFfaoD3rUpJfWpS spxh7F/aGmxmJCWmsVjwKojiyS3sb2iZlHimVaXeyb8DJINjMtgY4fjiSo7z3ba Message-ID: <4E18ED8F.2040301@protected-networks.net> Date: Sat, 09 Jul 2011 20:08:47 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110709 Thunderbird/5.0 MIME-Version: 1.0 To: Tim Gustafson References: <1427345072.163222.1309540223239.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: <1427345072.163222.1309540223239.JavaMail.root@mail-01.cse.ucsc.edu> Content-Type: multipart/mixed; boundary="------------060703080004090204070801" Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 00:08:51 -0000 This is a multi-part message in MIME format. --------------060703080004090204070801 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 07/01/11 13:10, Tim Gustafson wrote: > At any rate, 9 is working for now, except for the net-snmp compilation problem which I got around by using the binary package. A rather quick hack to get this to compile is attached; it is decidedly in need of more care .. imb --------------060703080004090204070801 Content-Type: text/plain; name="net-snmp-9-patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="net-snmp-9-patch" KioqIC4vYWdlbnQvbWliZ3JvdXAvbWliSUkvdGNwVGFibGUuY34JRnJpIEp1bCAgOCAyMDoy MjoxNyAyMDExCi0tLSAuL2FnZW50L21pYmdyb3VwL21pYklJL3RjcFRhYmxlLmMJRnJpIEp1 bCAgOCAyMDoyMjozNyAyMDExCioqKioqKioqKioqKioqKgoqKiogMTcsMjMgKioqKgogICNp bmNsdWRlIDxuZXQtc25tcC9uZXQtc25tcC1jb25maWcuaD4KICAjaW5jbHVkZSAibWliSUlf Y29tbW9uLmgiCiAgCiEgI2luY2x1ZGUgPGluX3BjYi5oPgogIAogICNpZiBIQVZFX05FVElO RVRfVENQX0gKICAjaW5jbHVkZSA8bmV0aW5ldC90Y3AuaD4KLS0tIDE3LDIzIC0tLS0KICAj aW5jbHVkZSA8bmV0LXNubXAvbmV0LXNubXAtY29uZmlnLmg+CiAgI2luY2x1ZGUgIm1pYklJ X2NvbW1vbi5oIgogIAohICNpbmNsdWRlIDxuZXRpbmV0L2luX3BjYi5oPgogIAogICNpZiBI QVZFX05FVElORVRfVENQX0gKICAjaW5jbHVkZSA8bmV0aW5ldC90Y3AuaD4KKioqIC4vYWdl bnQvbWliZ3JvdXAvbWliSUkvaXB2Ni5jfglGcmkgSnVsICA4IDIwOjA1OjA2IDIwMTEKLS0t IC4vYWdlbnQvbWliZ3JvdXAvbWliSUkvaXB2Ni5jCUZyaSBKdWwgIDggMjA6MjQ6NDkgMjAx MQoqKioqKioqKioqKioqKioKKioqIDk1LDEwMiAqKioqCiAgIyBpbmNsdWRlIDxuZXRpbmV0 Ni9pcDZfdmFyLmg+CiAgI2VuZGlmCiAgI2luY2x1ZGUgPG5ldC9yb3V0ZS5oPgohICNpZiBP U19GUkVFQlNEX09SX0RBUldJTgohICMgaWYgSEFWRV9ORVRJTkVUX0lOX1BDQl9ICiAgIyAg aW5jbHVkZSA8bmV0aW5ldC9pbl9wY2IuaD4KICAjIGVuZGlmCiAgI2VuZGlmCi0tLSA5NSwx MDIgLS0tLQogICMgaW5jbHVkZSA8bmV0aW5ldDYvaXA2X3Zhci5oPgogICNlbmRpZgogICNp bmNsdWRlIDxuZXQvcm91dGUuaD4KISAjaWYgMSAvKiBPU19GUkVFQlNEX09SX0RBUldJTiAq LwohICMgaWYgMSAvKiBIQVZFX05FVElORVRfSU5fUENCX0ggKi8KICAjICBpbmNsdWRlIDxu ZXRpbmV0L2luX3BjYi5oPgogICMgZW5kaWYKICAjZW5kaWYKKioqIC4vYWdlbnQvbWliZ3Jv dXAvbWliSUkvdWRwVGFibGUuY34JU2F0IE1heSAxMCAwNTo1MTozNyAyMDA4Ci0tLSAuL2Fn ZW50L21pYmdyb3VwL21pYklJL3VkcFRhYmxlLmMJRnJpIEp1bCAgOCAyMDoyNTo0NiAyMDEx CioqKioqKioqKioqKioqKgoqKiogMTcsMjIgKioqKgotLS0gMTcsMjQgLS0tLQogICNpbmNs dWRlIDxuZXQtc25tcC9uZXQtc25tcC1jb25maWcuaD4KICAjaW5jbHVkZSAibWliSUlfY29t bW9uLmgiCiAgCisgI2luY2x1ZGUgPG5ldGluZXQvaW5fcGNiLmg+CisgCiAgI2lmIEhBVkVf TkVUSU5FVF9VRFBfSAogICNpbmNsdWRlIDxuZXRpbmV0L3VkcC5oPgogICNlbmRpZgo= --------------060703080004090204070801-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 02:14:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98E1F106566B for ; Sun, 10 Jul 2011 02:14:54 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 54C1A8FC13 for ; Sun, 10 Jul 2011 02:14:54 +0000 (UTC) Received: by vxg33 with SMTP id 33so2860637vxg.13 for ; Sat, 09 Jul 2011 19:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QsRGhRIWBP6U9EhnU8OCVfIE47STiwbVH8ghg2M8kq0=; b=hyz3fc9uG4zb4ZZCHNaA7Af0kqCQdhvovcaLd3JsbLeFuFN7dU9UQqzrDtMSdtP1Vh zgMrF8MTwJPzFCawhS7sko62SwbsvhM+Yfg8MyO6APeRdVJvVSqqXClfrwy2Su1GOnVB g/xvwMdkPYsp6Bf4cyHu+si50Aym7tbhe3AD4= MIME-Version: 1.0 Received: by 10.52.89.240 with SMTP id br16mr1025563vdb.401.1310264093536; Sat, 09 Jul 2011 19:14:53 -0700 (PDT) Received: by 10.220.74.144 with HTTP; Sat, 9 Jul 2011 19:14:53 -0700 (PDT) In-Reply-To: <4E18ED8F.2040301@protected-networks.net> References: <1427345072.163222.1309540223239.JavaMail.root@mail-01.cse.ucsc.edu> <4E18ED8F.2040301@protected-networks.net> Date: Sat, 9 Jul 2011 19:14:53 -0700 Message-ID: From: Garrett Cooper To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 Cc: Tim Gustafson , freebsd-current@freebsd.org Subject: Re: FreeBSD 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 02:14:54 -0000 On Sat, Jul 9, 2011 at 5:08 PM, Michael Butler wrote: > On 07/01/11 13:10, Tim Gustafson wrote: > >> At any rate, 9 is working for now, except for the net-snmp compilation >> problem which I got around by using the binary package. > > A rather quick hack to get this to compile is attached; it is decidedly in > need of more care .. Or you could try out http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/158714 . It fixes ports/158266 too. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 02:21:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A96FB1065670 for ; Sun, 10 Jul 2011 02:21:53 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 70C998FC0C for ; Sun, 10 Jul 2011 02:21:53 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 371FA60E5; Sat, 9 Jul 2011 22:21:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1310264512; bh=0uEE9bqvYqA1MZ3UtBr8870Hr1MvBbq9c55I85AYJwI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pSWd2xicZPE4YzYvPwUoUJ30U5TxavzOYF+kpShOO+VqsrfXnALhURJUocIvO9Vtx liUHUOlkxn6xFqvLt1Hc2jCyPpcCRVKebgvD9kld2XX8TN5X7mZTxDIusBaLr37 DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=hFkHTwYIibDgPHz602ytXm8UTdDxb++5JBBrlgGVuG/6pVPEU1abwYmoikePAyF/d H3kEy0DX07pU3l2ruSlkwbIYEHUZe0nyzBC516R0oKGVEYWnH3Blt0hDC+TbR0l Message-ID: <4E190CBE.50406@protected-networks.net> Date: Sat, 09 Jul 2011 22:21:50 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110709 Thunderbird/5.0 MIME-Version: 1.0 To: Garrett Cooper References: <1427345072.163222.1309540223239.JavaMail.root@mail-01.cse.ucsc.edu> <4E18ED8F.2040301@protected-networks.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Gustafson , freebsd-current@freebsd.org Subject: Re: FreeBSD 9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 02:21:53 -0000 On 07/09/11 22:14, Garrett Cooper wrote: >> >> A rather quick hack to get this to compile is attached; it is decidedly in >> need of more care .. > > Or you could try out > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/158714 . It fixes > ports/158266 too. Awesome - Thanks! imb From owner-freebsd-current@FreeBSD.ORG Sun Jul 10 06:45:40 2011 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 C1A10106564A; Sun, 10 Jul 2011 06:45:40 +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 9513B8FC14; Sun, 10 Jul 2011 06:45:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6A6jdWo063516; Sun, 10 Jul 2011 02:45:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6A6jdWb063491; Sun, 10 Jul 2011 06:45:39 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 10 Jul 2011 06:45:39 GMT Message-Id: <201107100645.p6A6jdWb063491@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 amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 06:45:40 -0000 TB --- 2011-07-10 03:40:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-10 03:40:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-07-10 03:40:01 - cleaning the object tree TB --- 2011-07-10 03:40:46 - cvsupping the source tree TB --- 2011-07-10 03:40:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-07-10 03:46:10 - building world TB --- 2011-07-10 03:46:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-10 03:46:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-10 03:46:10 - TARGET=amd64 TB --- 2011-07-10 03:46:10 - TARGET_ARCH=amd64 TB --- 2011-07-10 03:46:10 - TZ=UTC TB --- 2011-07-10 03:46:10 - __MAKE_CONF=/dev/null TB --- 2011-07-10 03:46:10 - cd /src TB --- 2011-07-10 03:46:10 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 10 03:46:11 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Jul 10 06:13:31 UTC 2011 TB --- 2011-07-10 06:13:31 - generating LINT kernel config TB --- 2011-07-10 06:13:31 - cd /src/sys/amd64/conf TB --- 2011-07-10 06:13:31 - /usr/bin/make -B LINT TB --- 2011-07-10 06:13:31 - building LINT kernel TB --- 2011-07-10 06:13:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-10 06:13:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-10 06:13:31 - TARGET=amd64 TB --- 2011-07-10 06:13:31 - TARGET_ARCH=amd64 TB --- 2011-07-10 06:13:31 - TZ=UTC TB --- 2011-07-10 06:13:31 - __MAKE_CONF=/dev/null TB --- 2011-07-10 06:13:31 - cd /src TB --- 2011-07-10 06:13:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 10 06:13:31 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Jul 10 06:41:20 UTC 2011 TB --- 2011-07-10 06:41:20 - cd /src/sys/amd64/conf TB --- 2011-07-10 06:41:20 - /usr/sbin/config -m GENERIC TB --- 2011-07-10 06:41:20 - building GENERIC kernel TB --- 2011-07-10 06:41:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-10 06:41:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-10 06:41:20 - TARGET=amd64 TB --- 2011-07-10 06:41:20 - TARGET_ARCH=amd64 TB --- 2011-07-10 06:41:20 - TZ=UTC TB --- 2011-07-10 06:41:20 - __MAKE_CONF=/dev/null TB --- 2011-07-10 06:41:20 - cd /src TB --- 2011-07-10 06:41:20 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jul 10 06:41:20 UTC 2011 >>> 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 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /src/sys/dev/aic7xxx/ahd_pci.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /src/sys/dev/aic7xxx/aic7770.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /src/sys/dev/aic7xxx/aic79xx.c /src/sys/dev/aic7xxx/aic79xx.c: In function 'ahd_flush_qoutfifo': /src/sys/dev/aic7xxx/aic79xx.c:380: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /obj/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-10 06:45:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-10 06:45:38 - ERROR: failed to build GENERIC kernel TB --- 2011-07-10 06:45:38 - 8319.79 user 1662.01 system 11137.85 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 12:10:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E830106566C; Mon, 11 Jul 2011 12:10:50 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF408FC0A; Mon, 11 Jul 2011 12:10:50 +0000 (UTC) Received: by pzk27 with SMTP id 27so3991412pzk.13 for ; Mon, 11 Jul 2011 05:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P00Ajg8+0xPx8LpW7mHmO4Ekz3YNJcltzAhIaXRmESI=; b=PChi7n91aadME3g8ft/2+Dt8M3urEHNG/6YCU7uqDlFt7LNsubxou5hQ8uHvVOnFDI 3jljXZ9B+obL8SJyb6atq5OkFnokmJ2fTKL02rA6HEU64THDJqphDgYEgeOWhob+lbRo lkT4h6WQ8Zty3+in1CBKRGF1MTnJlCR5UZkp4= MIME-Version: 1.0 Received: by 10.68.52.196 with SMTP id v4mr7701801pbo.508.1310386249741; Mon, 11 Jul 2011 05:10:49 -0700 (PDT) Received: by 10.68.62.97 with HTTP; Mon, 11 Jul 2011 05:10:49 -0700 (PDT) In-Reply-To: <20110708193236.GB95673@alchemy.franken.de> References: <20110629134140.GF14797@alchemy.franken.de> <4E0B8F25.7090107@FreeBSD.org> <20110707100446.GJ14797@alchemy.franken.de> <20110707154958.GK14797@alchemy.franken.de> <20110708181102.GA95673@alchemy.franken.de> <20110708193236.GB95673@alchemy.franken.de> Date: Mon, 11 Jul 2011 16:10:49 +0400 Message-ID: From: KOT MATPOCKuH To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: Doug Barton , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 12:10:50 -0000 2011/7/8 Marius Strobl : > In order to have a result which can be compared with the base BIND. > Whether bind98 works or works without the ISC atomic operations says > nothing about the bind96 port or the base version. Okey... > Oops, sorry, I forgot to revert the previous patch when test-compiling. > Please re-fetch sparc64_isc_atomic.h.diff2 and try again. I started named from ports (dns/bind96) at Sat Jul 9 10:08:41 MSD, and it worked properly till Sun Jul 10 22:25:41 MSD. At 22:25:41 I restarted bind from base system with your sparc64_isc_atomic.h.diff2. >From this moment till today, 15:57:05 he crashed 3 times: Jul 10 23:19:19 sunrise kernel: pid 45352 (named), uid 53: exited on signal 6 Jul 11 14:52:20 sunrise kernel: pid 52032 (named), uid 53: exited on signal 6 Jul 11 15:14:15 sunrise kernel: pid 71300 (named), uid 53: exited on signal 6 To make to ensure proper operation of bind from ports, I ran it again at 15:57:05, and, I think, we need to wait several days. -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 13:33:52 2011 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 7BF21106564A; Mon, 11 Jul 2011 13:33:52 +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 012F08FC08; Mon, 11 Jul 2011 13:33:51 +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 p6BDXhNC087374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 16:33:43 +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 p6BDXhcW009843; Mon, 11 Jul 2011 16:33:43 +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 p6BDXhRP009841; Mon, 11 Jul 2011 16:33:43 +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, 11 Jul 2011 16:33:42 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711133342.GT43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="skzcsJvRJWOW8YcK" 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 13:33:52 -0000 --skzcsJvRJWOW8YcK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 03:27:56PM +0200, Petr Salinger wrote: > >>This patch made by Petr Salinger improves compatibility with > >>LinuxThreads in rfork() syscall. The Linux clone() implementation > >>allows specifying the signal sent to parent when child terminates > >>(instead of SIGCHLD). > >> > >>As the threading implementation in Debian GNU/kFreeBSD is > >>LinuxThreads-based, we had to diverge from upstream kFreeBSD ABI and > >>implement this extension. > >> > >>I hope it is acceptable for you to use the same encoding, this way we > >>would archieve ABI compatibility to run Debian GNU/kFreeBSD inside a > >>chroot/jail on top of a FreeBSD system. > >> > >>Thanks for considering > >> > >>-- > >>Robert Millan > > > >>--- a/sys/kern/kern_fork.c > >>+++ b/sys/kern/kern_fork.c > >>@@ -477,7 +477,13 @@ > >> p2->p_sigacts =3D newsigacts; > >> } > >> if (flags & RFLINUXTHPN) > >>- p2->p_sigparent =3D SIGUSR1; > >>+ { > >>+ int sig; > >>+ sig =3D RFTHPNSIGNUM(flags); > >>+ if (sig =3D=3D 0) sig =3D SIGUSR1; > >>+ if (sig =3D=3D SIGCHLD) sig =3D 0; > >>+ p2->p_sigparent =3D sig; > >>+ } > >> else > >> p2->p_sigparent =3D SIGCHLD; > >> > >>--- a/sys/sys/unistd.h > >>+++ b/sys/sys/unistd.h > >>@@ -182,6 +182,10 @@ > >> #define RFHIGHPID (1<<18) /* use a pid higher than 10=20 > >> (idleproc) */ > >> #define RFPPWAIT (1<<31) /* parent sleeps until child exits=20 > >> (vfork) */ > >> #define RFKERNELONLY (RFSTOPPED | RFHIGHPID | RFPPWAIT) > >>+#define RFTHPNSHIFT 24 /* reserve bits 24-30 */ > >>+#define RFTHPNMASK 0x7F /* for compatibility with=20 > >>linuxthreads/clone() */ > >>+ /* allow to specify "clone exit parent=20 > >>notification" signal */ > >>+#define RFTHPNSIGNUM(flags) (((flags) >> RFTHPNSHIFT) & RFTHPNMASK) > >> > >> #endif /* __BSD_VISIBLE */ > >> > >I looked at this patch some time ago already. > > > >Can you, please, describe the reasoning behind the > >>+ if (sig =3D=3D SIGCHLD) sig =3D 0; > >line ? >=20 > The main reason is backward compatibility. > The original FreeBSD code allows only to select between > SIGUSR1 or SIGCHLD signals. >=20 > The our extension changes meaning of RFLINUXTHPN to select signal based o= n=20 > bits 24-30 of passed flags instead of using SIGUSR1 every time. >=20 > When the passed "signal" number is zero, it should behave identically > on plain FreeBSD and in our environment, therefore SIGUSR1 is selected. > The assumption is (have been) that (yet) undefined bits are zero. > That way we are backward compatible with original FreeBSD. >=20 > We still need an alternative way to select "none signal is sent" > after child exit (under linux #0 is used). >=20 > The SIGCHLD can be "selected" (also on original FreeBSD) by not specifyin= g=20 > RFLINUXTHPN, therefore combination of RFLINUXTHPN and passed "signal"=20 > number SIGCHLD is (have been) used for "none signal". >=20 > BTW, the opposite side is in >=20 > http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/kfreebsd/clo= ne.c?view=3Dmarkup I shall state that the sig =3D=3D SIGCHLD case is ugly. Having the separate flag "do not send signal to the parent" would be much less clumsy. What are the requirements for the ABI stability for Debian/kFreeBSD ? Can this be fixed now, or is it too late ? Would you care to update the rfork(2) man page ? Also, it would be ideal to reformat the kern_fork.c change according to our style(9). --skzcsJvRJWOW8YcK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4a+7YACgkQC3+MBN1Mb4gmgwCfUVmivVjIURnzUngyWGE5P9Mf uEoAn3wVaWVpnufNVnAXpok+rJJWwPzB =dmIw -----END PGP SIGNATURE----- --skzcsJvRJWOW8YcK-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 14:22:41 2011 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 236901065672; Mon, 11 Jul 2011 14:22:41 +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 B78FD8FC20; Mon, 11 Jul 2011 14:22:40 +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 p6BEMXDA091566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 17:22:33 +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 p6BEMXtr016122; Mon, 11 Jul 2011 17:22:33 +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 p6BEMXFN016100; Mon, 11 Jul 2011 17:22:33 +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, 11 Jul 2011 17:22:33 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711142232.GU43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="czRehjsqUdpaVUeF" 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 14:22:41 -0000 --czRehjsqUdpaVUeF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 04:23:36PM +0200, Petr Salinger wrote: > >>>Can you, please, describe the reasoning behind the > >>>>+ if (sig =3D=3D SIGCHLD) sig =3D 0; > >>>line ? > >> > >>The main reason is backward compatibility. > >>The original FreeBSD code allows only to select between > >>SIGUSR1 or SIGCHLD signals. > >> > >>The our extension changes meaning of RFLINUXTHPN to select signal based= on > >>bits 24-30 of passed flags instead of using SIGUSR1 every time. > >> > >>When the passed "signal" number is zero, it should behave identically > >>on plain FreeBSD and in our environment, therefore SIGUSR1 is selected. > >>The assumption is (have been) that (yet) undefined bits are zero. > >>That way we are backward compatible with original FreeBSD. > >> > >>We still need an alternative way to select "none signal is sent" > >>after child exit (under linux #0 is used). > >> > >>The SIGCHLD can be "selected" (also on original FreeBSD) by not specify= ing > >>RFLINUXTHPN, therefore combination of RFLINUXTHPN and passed "signal" > >>number SIGCHLD is (have been) used for "none signal". > >> > >>BTW, the opposite side is in > >> > >>http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/kfreebsd/c= lone.c?view=3Dmarkup > > > >I shall state that the sig =3D=3D SIGCHLD case is ugly. Having the separ= ate > >flag "do not send signal to the parent" would be much less clumsy. > >What are the requirements for the ABI stability for Debian/kFreeBSD ? > >Can this be fixed now, or is it too late ? >=20 > It should be backward compatible with one previous version. >=20 > What about in long term this: >=20 > RFLINUXTHPN bit will be renamed and will have meaning > "select signal based on bits 24-30 of passed flags" >=20 > - zero would mean "no signal" > - SIGCHLD would mean undefined > - SIGUSR1 would mean SIGUSR1 >=20 > It is ABI/API breakage under original FreeBSD. > The question is how frequently RFLINUXTHPN is used under native FreeBSD > and its port collection. RFLINUXPTH was used by the linuxthreads port, that was popular in the time of FreeBSD 4.x and may be 5.x to run mysql. I will object against this breakage. >=20 > And under "Debian GNU/kFreeBSD COMPAT" or 8-COMPAT > - SIGCHLD would mean "no signal" We never user COMPAT to _change_ the meaning of something, only to exclude some functionality, like syscall. >=20 > We do not use SIGUSR1 currently, the eglibc side can detect whether > it runs under new-enough kernel and decide whether use 0 or SIGCHLD > for "no signal". >=20 > The kernel side would be something like: >=20 > if (flags & RFLINUXTHPN) > { > p2->p_sigparent =3D RFTHPNSIGNUM(flags); > #if COMPAT8 > if (p2->p_sigparent =3D=3D SIGCHLD) > p2->p_sigparent =3D 0; > #endif > } No, this is even uglier, and see the note about compat. BTW, it seems that our rfork(2) ignores unknown flags. This should be fixed, might be in the same patch. --czRehjsqUdpaVUeF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4bBygACgkQC3+MBN1Mb4jK3wCfUDTbE+y2thPnkLBRDkRLq53a wWQAnjkr4O8ngWU0FTCHpzsmnMbLAl1Q =yDiE -----END PGP SIGNATURE----- --czRehjsqUdpaVUeF-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 14:41:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1949F1065670 for ; Mon, 11 Jul 2011 14:41:26 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 81B2F8FC18 for ; Mon, 11 Jul 2011 14:41:26 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QgHfo-0006x2-3r for freebsd-current@freebsd.org; Mon, 11 Jul 2011 16:41:24 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jul 2011 16:41:24 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jul 2011 16:41:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 11 Jul 2011 16:41:04 +0200 Lines: 26 Message-ID: References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> <20110707151440.GA75537@troutmask.apl.washington.edu> <4E160C2F.8020001@FreeBSD.org> <20110707200845.GA77049@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <20110707200845.GA77049@troutmask.apl.washington.edu> X-Enigmail-Version: 1.1.2 Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 14:41:27 -0000 On 07/07/2011 22:08, Steve Kargl wrote: > 4BSD kernel gives for N = Ncpu + 1. > > 34 processes: 6 running, 28 sleeping > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND > 1417 kargl 1 71 0 370M 294M RUN 0 1:30 79.39% sasmp > 1416 kargl 1 71 0 370M 294M RUN 0 1:30 79.20% sasmp > 1418 kargl 1 71 0 370M 294M CPU2 0 1:29 78.81% sasmp > 1420 kargl 1 71 0 370M 294M CPU1 2 1:30 78.27% sasmp > 1419 kargl 1 70 0 370M 294M CPU3 0 1:30 77.59% sasmp > ULE kernel gives for N = Ncpu + 1. > > 34 processes: 6 running, 28 sleeping > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND > 1318 kargl 1 103 0 370M 294M CPU0 0 1:31 100.00% sasmp > 1319 kargl 1 103 0 370M 294M RUN 1 1:29 100.00% sasmp > 1322 kargl 1 99 0 370M 294M CPU2 2 1:03 87.26% sasmp > 1320 kargl 1 91 0 370M 294M RUN 3 1:07 60.79% sasmp > 1321 kargl 1 89 0 370M 294M CPU3 3 1:06 55.18% sasmp I can confirm this. Look at the priorities column for the two cases. For some reason (CPU affinity?) the loads get asymmetrical on ULE. From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:06:23 2011 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 63B01106566C; Mon, 11 Jul 2011 15:06:23 +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 CF78B8FC1A; Mon, 11 Jul 2011 15:06:22 +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 p6BF6Fbh095052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 18:06:15 +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 p6BF6FQQ049890; Mon, 11 Jul 2011 18:06:15 +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 p6BF6E4H049889; Mon, 11 Jul 2011 18:06:14 +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, 11 Jul 2011 18:06:14 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711150614.GV43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IX4edXMD7HczJcpd" 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 15:06:23 -0000 --IX4edXMD7HczJcpd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 04:50:44PM +0200, Petr Salinger wrote: > >RFLINUXPTH was used by the linuxthreads port, that was popular in the > >time of FreeBSD 4.x and may be 5.x to run mysql. I will object against > >this breakage. >=20 > Do I understand correctly that API/ABI backward compatibility with=20 > previous FreeBSD releases w.r.t RFLINUXPTH is needed ? Yes, I think so. >=20 > The 1st patch satisfies this. I agree that SIGCHLD part > is not easily readable. The SIGCHLD part is ugly. This is why I am asking about possible ways to overcome this. --IX4edXMD7HczJcpd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4bEWYACgkQC3+MBN1Mb4gP/QCeKk+yrsL0D5YH6TD0NiYlqHeH UxIAoL8ywZCzTIFuvWY3oXoVuXe8QLpc =cYjR -----END PGP SIGNATURE----- --IX4edXMD7HczJcpd-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:07:08 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5DF0106564A for ; Mon, 11 Jul 2011 15:07:07 +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 04B5C8FC17 for ; Mon, 11 Jul 2011 15:07:06 +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 SAA24352; Mon, 11 Jul 2011 18:07:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E1B1198.6090308@FreeBSD.org> Date: Mon, 11 Jul 2011 18:07:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Ivan Voras References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> <20110707151440.GA75537@troutmask.apl.washington.edu> <4E160C2F.8020001@FreeBSD.org> <20110707200845.GA77049@troutmask.apl.washington.edu> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Steve Kargl Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 15:07:08 -0000 on 11/07/2011 17:41 Ivan Voras said the following: > On 07/07/2011 22:08, Steve Kargl wrote: > >> 4BSD kernel gives for N = Ncpu + 1. >> >> 34 processes: 6 running, 28 sleeping >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND >> 1417 kargl 1 71 0 370M 294M RUN 0 1:30 79.39% sasmp >> 1416 kargl 1 71 0 370M 294M RUN 0 1:30 79.20% sasmp >> 1418 kargl 1 71 0 370M 294M CPU2 0 1:29 78.81% sasmp >> 1420 kargl 1 71 0 370M 294M CPU1 2 1:30 78.27% sasmp >> 1419 kargl 1 70 0 370M 294M CPU3 0 1:30 77.59% sasmp > >> ULE kernel gives for N = Ncpu + 1. >> >> 34 processes: 6 running, 28 sleeping >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND >> 1318 kargl 1 103 0 370M 294M CPU0 0 1:31 100.00% sasmp >> 1319 kargl 1 103 0 370M 294M RUN 1 1:29 100.00% sasmp >> 1322 kargl 1 99 0 370M 294M CPU2 2 1:03 87.26% sasmp >> 1320 kargl 1 91 0 370M 294M RUN 3 1:07 60.79% sasmp >> 1321 kargl 1 89 0 370M 294M CPU3 3 1:06 55.18% sasmp > > I can confirm this. Look at the priorities column for the two cases. For some > reason (CPU affinity?) the loads get asymmetrical on ULE. Yeah, but what problem is demonstrated here? Are we confident that non-even workload is inherently bad? E.g.: 79.39 + .. + 77.59 < 5 * 80 = 400 100.00 + ... + 55.18 ~~ 402 which is more than theoretically possible :-) So it would _appear_ that with ULE we get more work out of available CPUs. But it's not clear which of the processes are slaves and which is master. It's also not clear why the master takes so much CPU (on par with the slaves) - from my reading of its description (by Steve) it should be doing only light periodic work. If it does have to do CPU-heavy work, then I'd imagine that it should spawn only Ncpus - 1 slaves. Finally, I agree with Vlad that "logically idle" thread should not use lots of CPU (or even 100%). Scheduler doesn't know which thread uses 100% for useful work and which does it while simply spinning. Also, if with ULE we get less jumping around between CPUs than with 4BSD, that would mean less cache misses and more useful work done. Still not convinced that there is a problem with ULE here. I'd start with the app. P.S. Not saying that this is the case here, but I've seen the following scenario in real life. People add only nominal support for some platform in their software - when they don't know how to properly implement some feature, they just drop that feature or implement it very suboptimally. Then other people use bad performance of that software on that platform as indication that there is something wrong with the platform, not the software. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:11:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47F221065675 for ; Mon, 11 Jul 2011 15:11:54 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [93.95.13.41]) by mx1.freebsd.org (Postfix) with SMTP id 96C778FC2A for ; Mon, 11 Jul 2011 15:11:53 +0000 (UTC) Received: (qmail 5231 invoked from network); 11 Jul 2011 14:45:10 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 11 Jul 2011 14:45:10 -0000 Received: (qmail 5215 invoked by uid 599); 11 Jul 2011 14:45:10 -0000 Received: from unknown (HELO icritical.com) (87.127.43.249) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Mon, 11 Jul 2011 15:45:10 +0100 Message-ID: <4E1B0C72.7030109@icritical.com> Date: Mon, 11 Jul 2011 15:45:06 +0100 From: Matt Burke User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110403 Thunderbird/3.1.9 MIME-Version: 1.0 To: Berczi Gabor References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> In-Reply-To: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2011 14:45:06.0453 (UTC) FILETIME=[2004A450:01CC3FD9] X-Virus-Scanned: by iCritical at mail1.icritical.com Cc: freebsd-current@freebsd.org Subject: Re: ZFS boot fails with two pools X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 15:11:54 -0000 On 07/06/11 16:44, Berczi Gabor wrote: > For some reason FreeBSD can't boot automatically: ... > I have two pools, pool2 which is a mirrored zpool, and data being a > raid-z pool. Note how the default should be "pool2:/boot/zfsloader". How > can I fix this? The following applies to 8-STABLE from 2011-06-29. I believe -CURRENT may be identical, but don't know for certain. >From what I could tell from researching my similar problem (*), you can ignore the zpool bootfs property as well as the gpt bootme flag - they're not looked at by the boot process, at least not before the stage 3 loader. What happens is gptzfsboot simply tries to boot from the first zfs pool it finds. The only control you have is that the first drive it scans is the one it boots from. If the BIOS booted from the disk with the raid-z pool, or if there is something like a log partition for your raid-z pool before your boot pool on the disk (fixed with my patch), then gptzfsboot will try to load /boot/zfsloader from the raid-z pool, whether or not it can see enough vdevs to actually use the pool. If it can't run zfsloader it'll pointlessly try /boot/kernel/kernel from it before dumping you at the boot: prompt. That is why you see the "Default" showing as it does - it's more "Last tried" than "Default". My advice is to double-check which drive your BIOS is booting from (make sure it's one with 'pool2' on it), and if you've got a partition belonging to your 'data' pool on the disk (log, cache, etc), you could try rebuilding gptzfsboot with my patch providing you're aware that it's untested by anyone other than myself and by using it you risk causing irreparable damage to your pools. I hope not seeing as I'm running it myself, but I've had no feedback on it. (*) http://lists.freebsd.org/pipermail/freebsd-fs/2011-June/011882.html HTH, Matt. From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 14:28:49 2011 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 66142106566B for ; Mon, 11 Jul 2011 14:28:49 +0000 (UTC) (envelope-from rmh.aybabtu@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 316808FC1A for ; Mon, 11 Jul 2011 14:28:48 +0000 (UTC) Received: by iwr19 with SMTP id 19so4753274iwr.13 for ; Mon, 11 Jul 2011 07:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=zyWiItSWHyQqiqkc3krb1piCxyjj1CunHPrLMr3q2yU=; b=kWFqLq6lfvdXcJ7jvbuSUuQ4Ce9EmEvPMDsPGNz7MWXaOTmDGsSxCczs9Y89Xd3xzB OVfQOT7jcTEmqFbphukr2EOQo/6MGnEHViebWehrSh5/hYqczmf592RAQIz9u3WZ0GSv wPvbGNttYH6furwjIuRtfIxcPLwK6qrCP7o5g= MIME-Version: 1.0 Received: by 10.42.1.74 with SMTP id 10mr5310100icf.86.1310392946011; Mon, 11 Jul 2011 07:02:26 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.229.3 with HTTP; Mon, 11 Jul 2011 07:02:25 -0700 (PDT) In-Reply-To: <20110711133342.GT43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> Date: Mon, 11 Jul 2011 16:02:25 +0200 X-Google-Sender-Auth: 9M5zRDd6S4ZT7R0oKuN8Xzcpyf8 Message-ID: From: Robert Millan To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Mon, 11 Jul 2011 15:25:55 +0000 Cc: freebsd-hackers@freebsd.org, current@freebsd.org, Petr Salinger Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 14:28:49 -0000 2011/7/11 Kostik Belousov : > I shall state that the sig == SIGCHLD case is ugly. Having the separate > flag "do not send signal to the parent" would be much less clumsy. > What are the requirements for the ABI stability for Debian/kFreeBSD ? > Can this be fixed now, or is it too late ? Perhaps we could make a smooth transition by implementing both methods on our kernel, then update glibc to use the new one, and only remove the deprecated method in our kernel after a full release cycle. Petr, do you think this could fly? We'd be breaking backward compatibility in userland, but if I understand correctly we do this already and our only supported upgrade path is "first upgrade kernel, then userland" anyway. -- Robert Millan From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 14:42:01 2011 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 D5D421065670; Mon, 11 Jul 2011 14:42:01 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id 556128FC1B; Mon, 11 Jul 2011 14:42:00 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6BEfkVT075273; Mon, 11 Jul 2011 16:41:46 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Mon, 11 Jul 2011 16:50:44 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711142232.GU43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-FELK-MailScanner-Information: X-MailScanner-ID: p6BEfkVT075273 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311000109.70713@DRdNcjyQcQ4+cR/VzNgwIA X-Spam-Status: No X-Mailman-Approved-At: Mon, 11 Jul 2011 15:32:42 +0000 Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 14:42:01 -0000 > RFLINUXPTH was used by the linuxthreads port, that was popular in the > time of FreeBSD 4.x and may be 5.x to run mysql. I will object against > this breakage. Do I understand correctly that API/ABI backward compatibility with previous FreeBSD releases w.r.t RFLINUXPTH is needed ? The 1st patch satisfies this. I agree that SIGCHLD part is not easily readable. Petr From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 14:45:46 2011 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 1EA5310656AC for ; Mon, 11 Jul 2011 14:45:46 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id 9A51A8FC16 for ; Mon, 11 Jul 2011 14:45:45 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6BEEc9F073451; Mon, 11 Jul 2011 16:14:38 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Mon, 11 Jul 2011 16:23:36 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711133342.GT43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-FELK-MailScanner-Information: X-MailScanner-ID: p6BEEc9F073451 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1310998479.6933@rQF0UD8XI1GYzmeowRQmjg X-Spam-Status: No X-Mailman-Approved-At: Mon, 11 Jul 2011 15:32:53 +0000 Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 14:45:46 -0000 >>> Can you, please, describe the reasoning behind the >>>> + if (sig == SIGCHLD) sig = 0; >>> line ? >> >> The main reason is backward compatibility. >> The original FreeBSD code allows only to select between >> SIGUSR1 or SIGCHLD signals. >> >> The our extension changes meaning of RFLINUXTHPN to select signal based on >> bits 24-30 of passed flags instead of using SIGUSR1 every time. >> >> When the passed "signal" number is zero, it should behave identically >> on plain FreeBSD and in our environment, therefore SIGUSR1 is selected. >> The assumption is (have been) that (yet) undefined bits are zero. >> That way we are backward compatible with original FreeBSD. >> >> We still need an alternative way to select "none signal is sent" >> after child exit (under linux #0 is used). >> >> The SIGCHLD can be "selected" (also on original FreeBSD) by not specifying >> RFLINUXTHPN, therefore combination of RFLINUXTHPN and passed "signal" >> number SIGCHLD is (have been) used for "none signal". >> >> BTW, the opposite side is in >> >> http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/kfreebsd/clone.c?view=markup > > I shall state that the sig == SIGCHLD case is ugly. Having the separate > flag "do not send signal to the parent" would be much less clumsy. > What are the requirements for the ABI stability for Debian/kFreeBSD ? > Can this be fixed now, or is it too late ? It should be backward compatible with one previous version. What about in long term this: RFLINUXTHPN bit will be renamed and will have meaning "select signal based on bits 24-30 of passed flags" - zero would mean "no signal" - SIGCHLD would mean undefined - SIGUSR1 would mean SIGUSR1 It is ABI/API breakage under original FreeBSD. The question is how frequently RFLINUXTHPN is used under native FreeBSD and its port collection. And under "Debian GNU/kFreeBSD COMPAT" or 8-COMPAT - SIGCHLD would mean "no signal" We do not use SIGUSR1 currently, the eglibc side can detect whether it runs under new-enough kernel and decide whether use 0 or SIGCHLD for "no signal". The kernel side would be something like: if (flags & RFLINUXTHPN) { p2->p_sigparent = RFTHPNSIGNUM(flags); #if COMPAT8 if (p2->p_sigparent == SIGCHLD) p2->p_sigparent = 0; #endif } Petr From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:34:40 2011 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 A7D6E106573C; Mon, 11 Jul 2011 15:34:40 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id 21D5C8FC1F; Mon, 11 Jul 2011 15:34:39 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6BFYPnO085033; Mon, 11 Jul 2011 17:34:25 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Mon, 11 Jul 2011 17:43:23 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711150614.GV43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-FELK-MailScanner-Information: X-MailScanner-ID: p6BFYPnO085033 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311003268.14331@EbEHICip5uMYeksDqjPmBQ X-Spam-Status: No X-Mailman-Approved-At: Mon, 11 Jul 2011 15:39:31 +0000 Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 15:34:40 -0000 >> The 1st patch satisfies this. I agree that SIGCHLD part >> is not easily readable. > The SIGCHLD part is ugly. This is why I am asking about possible ways > to overcome this. We need a way to specify "no signal". It can be "new flag" or "ugly SIGCHLD". new flag: pros: cleaner design cons: one bit of flags eaten cons: GNU/kFreeBSD have to detect at runtime which "no signal" have to use cons: GNU/kFreeBSD have to add "ugly SIGCHLD" for some time (up-to and including next Debian release) anyway ugly SIGCHLD: pros: immediate GNU/kFreeBSD compatibility cons: ugly design But definitely, it would be much, much better to have "new flag" compared to diverge indefinitely ;-) What should be name of the "new flag" ? #define RFTHPNONE (1<<19) /* do not send exit notification signal to the parent */ Petr From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:41:10 2011 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 8E4021065689; Mon, 11 Jul 2011 15:41:10 +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 2D5268FC16; Mon, 11 Jul 2011 15:41:09 +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 p6BFf2DZ097906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 18:41:02 +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 p6BFf2e2051132; Mon, 11 Jul 2011 18:41:02 +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 p6BFf2ED051131; Mon, 11 Jul 2011 18:41:02 +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, 11 Jul 2011 18:41:02 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711154102.GW43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Z0wTxTCd2IDq3u/i" 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 15:41:10 -0000 --Z0wTxTCd2IDq3u/i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 05:43:23PM +0200, Petr Salinger wrote: > >>The 1st patch satisfies this. I agree that SIGCHLD part > >>is not easily readable. > >The SIGCHLD part is ugly. This is why I am asking about possible ways > >to overcome this. >=20 > We need a way to specify "no signal". > It can be "new flag" or "ugly SIGCHLD". >=20 > new flag: > pros: cleaner design > cons: one bit of flags eaten > cons: GNU/kFreeBSD have to detect at runtime which "no signal" have to = use > cons: GNU/kFreeBSD have to add "ugly SIGCHLD" for some time > (up-to and including next Debian release) anyway >=20 > ugly SIGCHLD: > pros: immediate GNU/kFreeBSD compatibility > cons: ugly design >=20 > But definitely, it would be much, much better to have "new flag" compared= =20 > to diverge indefinitely ;-) >=20 > What should be name of the "new flag" ? >=20 > #define RFTHPNONE (1<<19) /* do not send exit notification signal to the= =20 > parent */ >=20 I would instead use a new flag to specify a signal sent on the child death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is set, the bit slice is used as signal number, 0 means do not send any signal. Please note that the signal should be checked for validity, it must be <=3D _SIG_MAXSIG). --Z0wTxTCd2IDq3u/i Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4bGY0ACgkQC3+MBN1Mb4iB3ACg7W4IXzVsMQdGWspxVlmx2A7i icYAnjOSgI2LR2L42ailheOMQ4OdmDOF =ARQi -----END PGP SIGNATURE----- --Z0wTxTCd2IDq3u/i-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 15:42:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 978AA1065677 for ; Mon, 11 Jul 2011 15:42:04 +0000 (UTC) (envelope-from adrian.chadd@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 2C7B88FC27 for ; Mon, 11 Jul 2011 15:42:03 +0000 (UTC) Received: by ywf7 with SMTP id 7so1919381ywf.13 for ; Mon, 11 Jul 2011 08:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=ZRn5s2GVvg73HRg8hRCzEqHzqc9rf/79WNWUyDr+l/U=; b=Vf3We3WAK12DP9vKnujXtunvuzbmr4nACGKo+4UIcv0/MiiR7AI69ZK4LrSQzeSRgk yZ4ZgnKnKjdlCD/VV5x0AGwv60H9FQDfL9tF/43AeUZMbLyA9etATkWJRphCQbc+N9I5 vYIcw8lqBRjoYSjKXz5CJHHINhqbJ91xV6HXQ= MIME-Version: 1.0 Received: by 10.151.29.7 with SMTP id g7mr1614782ybj.410.1310398923357; Mon, 11 Jul 2011 08:42:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Mon, 11 Jul 2011 08:42:02 -0700 (PDT) In-Reply-To: <4E1B1198.6090308@FreeBSD.org> References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> <20110707151440.GA75537@troutmask.apl.washington.edu> <4E160C2F.8020001@FreeBSD.org> <20110707200845.GA77049@troutmask.apl.washington.edu> <4E1B1198.6090308@FreeBSD.org> Date: Mon, 11 Jul 2011 23:42:02 +0800 X-Google-Sender-Auth: ebFW2sfV-Yt9h0q8uk5o1_pqYKA Message-ID: From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Ivan Voras , Steve Kargl Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 15:42:04 -0000 That top output is averaged and slow to adjust. Using "top" as an indication as to what's really going on is likely not a good idea. 2c, Adrian From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 16:03:29 2011 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 6ABA2106566B; Mon, 11 Jul 2011 16:03:29 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id DB52B8FC29; Mon, 11 Jul 2011 16:03:28 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6BG3How086824; Mon, 11 Jul 2011 18:03:17 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Mon, 11 Jul 2011 18:12:15 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711154102.GW43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-FELK-MailScanner-Information: X-MailScanner-ID: p6BG3How086824 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311004997.74881@3PVEEZ+jUrOzDdbDuZJulA X-Spam-Status: No X-Mailman-Approved-At: Mon, 11 Jul 2011 16:08:12 +0000 Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 16:03:29 -0000 > I would instead use a new flag to specify a signal sent on the child > death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is > set, the bit slice is used as signal number, 0 means do not send any > signal. > > Please note that the signal should be checked for validity, it must be > <= _SIG_MAXSIG). We used this: #define RFTHPNSHIFT 24 /* reserve bits 24-30 */ #define RFTHPNMASK 0x7F /* for compatibility with linuxthreads/clone() */ /* allow to specify "clone exit parent notification" signal */ #define RFTHPNSIGNUM(flags) (((flags) >> RFTHPNSHIFT) & RFTHPNMASK) Therefore signal #128 (_SIG_MAXSIG) cannot be selected. Should the bit slice be 7 or 8 bits ? Petr From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 16:16:54 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9D28106566C; Mon, 11 Jul 2011 16:16:54 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 96F108FC0A; Mon, 11 Jul 2011 16:16:54 +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 p6BGGsku097587; Mon, 11 Jul 2011 09:16:54 -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 p6BGGsxW097586; Mon, 11 Jul 2011 09:16:54 -0700 (PDT) (envelope-from sgk) Date: Mon, 11 Jul 2011 09:16:54 -0700 From: Steve Kargl To: Andriy Gapon Message-ID: <20110711161654.GA97361@troutmask.apl.washington.edu> References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> <20110707151440.GA75537@troutmask.apl.washington.edu> <4E160C2F.8020001@FreeBSD.org> <20110707200845.GA77049@troutmask.apl.washington.edu> <4E1B1198.6090308@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E1B1198.6090308@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, Ivan Voras Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 16:16:54 -0000 On Mon, Jul 11, 2011 at 06:07:04PM +0300, Andriy Gapon wrote: > on 11/07/2011 17:41 Ivan Voras said the following: > > On 07/07/2011 22:08, Steve Kargl wrote: > > > >> 4BSD kernel gives for N = Ncpu + 1. > >> > >> 34 processes: 6 running, 28 sleeping > >> > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND > >> 1417 kargl 1 71 0 370M 294M RUN 0 1:30 79.39% sasmp > >> 1416 kargl 1 71 0 370M 294M RUN 0 1:30 79.20% sasmp > >> 1418 kargl 1 71 0 370M 294M CPU2 0 1:29 78.81% sasmp > >> 1420 kargl 1 71 0 370M 294M CPU1 2 1:30 78.27% sasmp > >> 1419 kargl 1 70 0 370M 294M CPU3 0 1:30 77.59% sasmp > > > >> ULE kernel gives for N = Ncpu + 1. > >> > >> 34 processes: 6 running, 28 sleeping > >> > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND > >> 1318 kargl 1 103 0 370M 294M CPU0 0 1:31 100.00% sasmp > >> 1319 kargl 1 103 0 370M 294M RUN 1 1:29 100.00% sasmp > >> 1322 kargl 1 99 0 370M 294M CPU2 2 1:03 87.26% sasmp > >> 1320 kargl 1 91 0 370M 294M RUN 3 1:07 60.79% sasmp > >> 1321 kargl 1 89 0 370M 294M CPU3 3 1:06 55.18% sasmp > > > > I can confirm this. Look at the priorities column for the two cases. For some > > reason (CPU affinity?) the loads get asymmetrical on ULE. > > Yeah, but what problem is demonstrated here? That ULE cannot balance numerically intensive work, leading to poor performance. > Are we confident that non-even workload is inherently bad? > E.g.: > 79.39 + .. + 77.59 < 5 * 80 = 400 > 100.00 + ... + 55.18 ~~ 402 which is more than theoretically possible :-) > So it would _appear_ that with ULE we get more work out of available CPUs. > > But it's not clear which of the processes are slaves and which is master. > It's also not clear why the master takes so much CPU (on par with the > slaves) - > from my reading of its description (by Steve) it should be doing only light > periodic work. These are all slave processes. The master process was on a different node in the cluster. Each process is doing the exact same computation with only a small change in a coordinate from (x,y,z) to (x,y+n*dy,z) with n = 1, 2, 3, 4. The small change does not causes a different code path, so all should complete in nearly identical times. > If it does have to do CPU-heavy work, then I'd imagine that it should > spawn only Ncpus - 1 slaves. And if you have M users on the system? Also note, you can get the exact same loading problem by launching Ncpu+1 completely independent cpu-bound processes. Ncpu-1 processes will be bound to specific cpus and 2 processes will ping-pong on one cpu. This ping-ponging will simply kill performance. > Also, if with ULE we get less jumping around between CPUs than with > 4BSD, that would mean less cache misses and more useful work done. Well, yes, less cache misses for the pinned processes; and, no, for more useful work done. > Still not convinced that there is a problem with ULE here. It's ULE. See the last 3 years of my posts on the topic. > I'd start with the app. I'd switch to 4BSD ;-). -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 16:25:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42F9C106564A; Mon, 11 Jul 2011 16:25:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 1F05D8FC08; Mon, 11 Jul 2011 16:25:57 +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 p6BGPuVu097631; Mon, 11 Jul 2011 09:25:56 -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 p6BGPuNR097630; Mon, 11 Jul 2011 09:25:56 -0700 (PDT) (envelope-from sgk) Date: Mon, 11 Jul 2011 09:25:56 -0700 From: Steve Kargl To: Adrian Chadd Message-ID: <20110711162556.GB97361@troutmask.apl.washington.edu> References: <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> <20110707151440.GA75537@troutmask.apl.washington.edu> <4E160C2F.8020001@FreeBSD.org> <20110707200845.GA77049@troutmask.apl.washington.edu> <4E1B1198.6090308@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: freebsd-current@freebsd.org, Ivan Voras , Andriy Gapon Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 16:25:57 -0000 On Mon, Jul 11, 2011 at 11:42:02PM +0800, Adrian Chadd wrote: > That top output is averaged and slow to adjust. > Using "top" as an indication as to what's really going on is likely > not a good idea. > Restoring top output here: > PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND > 1318 kargl 1 103 0 370M 294M CPU0 0 1:31 100.00% sasmp > 1319 kargl 1 103 0 370M 294M RUN 1 1:29 100.00% sasmp > 1322 kargl 1 99 0 370M 294M CPU2 2 1:03 87.26% sasmp > 1320 kargl 1 91 0 370M 294M RUN 3 1:07 60.79% sasmp > 1321 kargl 1 89 0 370M 294M CPU3 3 1:06 55.18% sasmp That TIME column is a very good indication of problem. I can assure you that wall-clock time for the application under ULE is far longer than under 4BSD. IIRC (because its been awhile since I looked at problem), guess what happens when pid 1318 or 1319 finishes? Did you guess that pid 1320 and 1321 are still stuck on the same cpu? -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 16:41:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0A50106566C; Mon, 11 Jul 2011 16:41:53 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78FDD8FC0C; Mon, 11 Jul 2011 16:41:53 +0000 (UTC) Received: by yxl31 with SMTP id 31so438081yxl.13 for ; Mon, 11 Jul 2011 09:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=872VSh5mEbtlGnJwpV2XYju6aNwmDVR/TEI+hs2UfFM=; b=GnrKtlDUyXCzn+H5eMqOIwAYe8PfQshe5lLVdt7kjvFFqGUJoN/LmBv1Kv4a7459H7 hgx/KbT/47AA6zJJXIKUjT7WVoYCP9UicsTdxSbee8DLXFhh/J3EuwNLCFzlsPynYB8e fayYjMkEPl1sjV/l/SlWjmQHgob7Hu+CkbXu8= Received: by 10.101.108.3 with SMTP id k3mr1151098anm.129.1310400892089; Mon, 11 Jul 2011 09:14:52 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.252.8 with HTTP; Mon, 11 Jul 2011 09:14:12 -0700 (PDT) In-Reply-To: <4E1B1198.6090308@FreeBSD.org> References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> <20110707151440.GA75537@troutmask.apl.washington.edu> <4E160C2F.8020001@FreeBSD.org> <20110707200845.GA77049@troutmask.apl.washington.edu> <4E1B1198.6090308@FreeBSD.org> From: Ivan Voras Date: Mon, 11 Jul 2011 18:14:12 +0200 X-Google-Sender-Auth: S9C1lVRwPNEnk-aT5SQl9nnMWGU Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 16:41:53 -0000 On 11 July 2011 17:07, Andriy Gapon wrote: > Yeah, but what problem is demonstrated here? > Are we confident that non-even workload is inherently bad? > E.g.: > 79.39 + .. + 77.59 < 5 * 80 =3D 400 > 100.00 + ... + 55.18 ~~ 402 which is more than theoretically possible :-) > So it would _appear_ that with ULE we get more work out of available CPUs= . It depends... I am not really concerned about the percentages; for many things, including "green computing" and TurboBoost it is beneficial to have one loaded CPU core and the rest of them idling (so they can be slowed down, or the loaded ones "boosted" - if we even support this). >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMM= AND >> 1318 kargl 1 103 0 370M 294M CPU0 0 1:31 100.00% sas= mp >> 1319 kargl 1 103 0 370M 294M RUN 1 1:29 100.00% sas= mp >> 1322 kargl 1 99 0 370M 294M CPU2 2 1:03 87.26% sasm= p >> 1320 kargl 1 91 0 370M 294M RUN 3 1:07 60.79% sasm= p >> 1321 kargl 1 89 0 370M 294M CPU3 3 1:06 55.18% sasm= p What I'd like to know is how do the priority calculations come into this - as the OP's problem sort of reminds of livelocking. > P.S. Not saying that this is the case here, but I've seen the following s= cenario > in real life. =C2=A0People add only nominal support for some platform in = their software > - when they don't know how to properly implement some feature, they just = drop that > feature or implement it very suboptimally. =C2=A0Then other people use ba= d performance > of that software on that platform as indication that there is something w= rong with > the platform, not the software. Yes but as a minority platform, it eventually becomes "our" problem... From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 16:53:02 2011 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 C045F106566B; Mon, 11 Jul 2011 16:53:02 +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 988908FC15; Mon, 11 Jul 2011 16:53:02 +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 4EF5046B24; Mon, 11 Jul 2011 12:53:02 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E07DB8A02E; Mon, 11 Jul 2011 12:53:01 -0400 (EDT) From: John Baldwin To: Alexander Best Date: Mon, 11 Jul 2011 12:05:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201107081511.43417.jhb@freebsd.org> <20110709083047.GA86927@freebsd.org> <20110709094416.GA95093@freebsd.org> In-Reply-To: <20110709094416.GA95093@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107111205.13178.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 11 Jul 2011 12:53:02 -0400 (EDT) Cc: current@freebsd.org, edwin@freebsd.org Subject: Re: [PATCH] Make top -P an interactive toggle X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 16:53:02 -0000 On Saturday, July 09, 2011 5:44:16 am Alexander Best wrote: > On Sat Jul 9 11, Alexander Best wrote: > > On Fri Jul 8 11, Alexander Best wrote: > > > On Fri Jul 8 11, John Baldwin wrote: > > > > This patch lets you use 'P' while top is running to toggle between per-CPU and > > > > global CPU stats. > > > > > > very cool. i always thought that being able to interactivly enable/disable > > > per-cpu stats in top would be a useful feature. great to see this being > > > implemented. > > > > oh...and of course i tested your patch. ;) works great without any issues. > > would it be possible to display a note when using 'P'? E.g. when pressing 'z' > top informs the user with one of these messages: > > "Displaying system idle process." > > or > > "Not displaying system idle process." > > would be nice to have something similar when pressing the 'P' key. Maybe: > > "Display per-cpu CPU usage statistics." > > and > > "Not display per-cpu CPU usage statistics." Ok, I went with "Displaying per-CPU statistics" and "Displaying global CPU statistics". -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 17:24:18 2011 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 167C61065670; Mon, 11 Jul 2011 17:24:18 +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 0DA7A8FC0C; Mon, 11 Jul 2011 17:24:16 +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 p6BHO8Mr006955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 20:24:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p6BHO8pA054637; Mon, 11 Jul 2011 20:24:08 +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 p6BHO8wJ054636; Mon, 11 Jul 2011 20:24:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Jul 2011 20:24:08 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711172408.GX43872@deviant.kiev.zoral.com.ua> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TOkWJigZa0YodlBE" 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 17:24:18 -0000 --TOkWJigZa0YodlBE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 06:12:15PM +0200, Petr Salinger wrote: > >I would instead use a new flag to specify a signal sent on the child > >death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is > >set, the bit slice is used as signal number, 0 means do not send any > >signal. > > > >Please note that the signal should be checked for validity, it must be > ><=3D _SIG_MAXSIG). >=20 > We used this: >=20 > #define RFTHPNSHIFT 24 /* reserve bits 24-30 */ > #define RFTHPNMASK 0x7F /* for compatibility with=20 > linuxthreads/clone() */ > /* allow to specify "clone exit parent=20 > notification" signal */ > #define RFTHPNSIGNUM(flags) (((flags) >> RFTHPNSHIFT) & RFTHPNMASK) >=20 > Therefore signal #128 (_SIG_MAXSIG) cannot be selected. >=20 > Should the bit slice be 7 or 8 bits ? I propose to go 8 bits, and add the check to be future-proof. It seems that we already parse GNU/kFreeBSD brandnote. I think this could be used to distinguish between old behaviour, that is currently used by your libc, and proposed new interface, if __FreeBSD_version is bumped and honored by glibc. You might need to store the brandinfo somewhere in struct proc or use the separate struct sysentvec. --TOkWJigZa0YodlBE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4bMbgACgkQC3+MBN1Mb4gEcACfdj7xc3GIUFHXKmc7JIeohaMR zcMAn2rCwH7+ioEK42bpY+4iDFftWu2j =bNtr -----END PGP SIGNATURE----- --TOkWJigZa0YodlBE-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 17:57:12 2011 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 2F3F61065673; Mon, 11 Jul 2011 17:57:12 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id A61F58FC1F; Mon, 11 Jul 2011 17:57:10 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6BHuwJS091697; Mon, 11 Jul 2011 19:56:58 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Mon, 11 Jul 2011 20:05:56 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711172408.GX43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-FELK-MailScanner-Information: X-MailScanner-ID: p6BHuwJS091697 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311011819.22339@gHoEZ/dW6hA7X9y9f898Vw X-Spam-Status: No X-Mailman-Approved-At: Mon, 11 Jul 2011 18:01:32 +0000 Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 17:57:12 -0000 >> Should the bit slice be 7 or 8 bits ? > I propose to go 8 bits, and add the check to be future-proof. > It seems that we already parse GNU/kFreeBSD brandnote. I think this > could be used to distinguish between old behaviour, that is currently > used by your libc, and proposed new interface, if __FreeBSD_version > is bumped and honored by glibc. You might need to store the brandinfo > somewhere in struct proc or use the separate struct sysentvec. No, the version in brandnote is compile-time minimal supported version, we will detect at runtime (by "sysctl kern.osreldate") which interface we should use. So far defined rfork() options: /* * XXX currently, some operations without RFPROC set are not supported. */ #define RFNAMEG (1<<0) /* UNIMPL new plan9 `name space' */ #define RFENVG (1<<1) /* UNIMPL copy plan9 `env space' */ #define RFFDG (1<<2) /* copy fd table */ #define RFNOTEG (1<<3) /* UNIMPL create new plan9 `note group' */ #define RFPROC (1<<4) /* change child (else changes curproc) */ #define RFMEM (1<<5) /* share `address space' */ #define RFNOWAIT (1<<6) /* give child to init */ #define RFCNAMEG (1<<10) /* UNIMPL zero plan9 `name space' */ #define RFCENVG (1<<11) /* UNIMPL zero plan9 `env space' */ #define RFCFDG (1<<12) /* close all fds, zero fd table */ #define RFTHREAD (1<<13) /* enable kernel thread support */ #define RFSIGSHARE (1<<14) /* share signal handlers */ #define RFLINUXTHPN (1<<16) /* do linux clone exit parent notification */ #define RFSTOPPED (1<<17) /* leave child in a stopped state */ #define RFHIGHPID (1<<18) /* use a pid higher than 10 (idleproc) */ #define RFPPWAIT (1<<31) /* parent sleeps until child exits (vfork) */ #define RFKERNELONLY (RFSTOPPED | RFHIGHPID | RFPPWAIT) The new interface will add: #define RFTSIGZMB (1<<19) #define RFTSIGSHIFT 20 /* reserve bits 20-27 */ #define RFTSIGMASK 0xFF #define RFTSIGNUM(flags) (((flags) >> RFTSIGSHIFT) & RFTSIGMASK) #define RFTSIGFLAGS(signum) ((signum) << RFTSIGSHIFT) Seems this interface be acceptable ? Petr From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 18:03:10 2011 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 B4674106564A; Mon, 11 Jul 2011 18:03:10 +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 C60D38FC08; Mon, 11 Jul 2011 18:03:09 +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 p6BI2kVl009618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 21:02:47 +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 p6BI2kOd056069; Mon, 11 Jul 2011 21:02:46 +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 p6BI2kP8056068; Mon, 11 Jul 2011 21:02:46 +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, 11 Jul 2011 21:02:46 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110711180246.GA43872@deviant.kiev.zoral.com.ua> References: <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ib0MfiC6BuP+wsSj" 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 18:03:10 -0000 --ib0MfiC6BuP+wsSj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 08:05:56PM +0200, Petr Salinger wrote: > >>Should the bit slice be 7 or 8 bits ? >=20 > >I propose to go 8 bits, and add the check to be future-proof. >=20 > >It seems that we already parse GNU/kFreeBSD brandnote. I think this > >could be used to distinguish between old behaviour, that is currently > >used by your libc, and proposed new interface, if __FreeBSD_version > >is bumped and honored by glibc. You might need to store the brandinfo > >somewhere in struct proc or use the separate struct sysentvec. >=20 > No, the version in brandnote is compile-time minimal supported version, > we will detect at runtime (by "sysctl kern.osreldate") which interface we= =20 > should use. >=20 >=20 > So far defined rfork() options: >=20 > /* > * XXX currently, some operations without RFPROC set are not supported. > */ >=20 > #define RFNAMEG (1<<0) /* UNIMPL new plan9 `name space' */ > #define RFENVG (1<<1) /* UNIMPL copy plan9 `env space' */ > #define RFFDG (1<<2) /* copy fd table */ > #define RFNOTEG (1<<3) /* UNIMPL create new plan9 `note=20 > group' */ > #define RFPROC (1<<4) /* change child (else changes=20 > curproc) */ > #define RFMEM (1<<5) /* share `address space' */ > #define RFNOWAIT (1<<6) /* give child to init */ > #define RFCNAMEG (1<<10) /* UNIMPL zero plan9 `name space' */ > #define RFCENVG (1<<11) /* UNIMPL zero plan9 `env space' */ > #define RFCFDG (1<<12) /* close all fds, zero fd table */ > #define RFTHREAD (1<<13) /* enable kernel thread support */ > #define RFSIGSHARE (1<<14) /* share signal handlers */ > #define RFLINUXTHPN (1<<16) /* do linux clone exit parent=20 > notification */ > #define RFSTOPPED (1<<17) /* leave child in a stopped state */ > #define RFHIGHPID (1<<18) /* use a pid higher than 10=20 > (idleproc) */ > #define RFPPWAIT (1<<31) /* parent sleeps until child exits=20 > (vfork) */ > #define RFKERNELONLY (RFSTOPPED | RFHIGHPID | RFPPWAIT) >=20 >=20 > The new interface will add: >=20 > #define RFTSIGZMB (1<<19) > #define RFTSIGSHIFT 20 /* reserve bits 20-27 */=20 > #define RFTSIGMASK 0xFF=20 > #define RFTSIGNUM(flags) (((flags) >> RFTSIGSHIFT) & RFTSIGMASK) > #define RFTSIGFLAGS(signum) ((signum) << RFTSIGSHIFT) >=20 > Seems this interface be acceptable ? Looks good to me. --ib0MfiC6BuP+wsSj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4bOsYACgkQC3+MBN1Mb4j6hgCfYSWLtnCtQ8i0t+q5ONU2S4iZ Xu4AoOqUDzohAK7PbnZBEzYQkGHcHpx+ =LIfS -----END PGP SIGNATURE----- --ib0MfiC6BuP+wsSj-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 18:42:42 2011 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 20F631065674; Mon, 11 Jul 2011 18:42:42 +0000 (UTC) Date: Mon, 11 Jul 2011 18:42:42 +0000 From: Alexander Best To: John Baldwin Message-ID: <20110711184242.GA87523@freebsd.org> References: <201107081511.43417.jhb@freebsd.org> <20110709083047.GA86927@freebsd.org> <20110709094416.GA95093@freebsd.org> <201107111205.13178.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107111205.13178.jhb@freebsd.org> Cc: current@freebsd.org, edwin@freebsd.org Subject: Re: [PATCH] Make top -P an interactive toggle X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 18:42:42 -0000 On Mon Jul 11 11, John Baldwin wrote: > On Saturday, July 09, 2011 5:44:16 am Alexander Best wrote: > > On Sat Jul 9 11, Alexander Best wrote: > > > On Fri Jul 8 11, Alexander Best wrote: > > > > On Fri Jul 8 11, John Baldwin wrote: > > > > > This patch lets you use 'P' while top is running to toggle between per-CPU and > > > > > global CPU stats. > > > > > > > > very cool. i always thought that being able to interactivly enable/disable > > > > per-cpu stats in top would be a useful feature. great to see this being > > > > implemented. > > > > > > oh...and of course i tested your patch. ;) works great without any issues. > > > > would it be possible to display a note when using 'P'? E.g. when pressing 'z' > > top informs the user with one of these messages: > > > > "Displaying system idle process." > > > > or > > > > "Not displaying system idle process." > > > > would be nice to have something similar when pressing the 'P' key. Maybe: > > > > "Display per-cpu CPU usage statistics." > > > > and > > > > "Not display per-cpu CPU usage statistics." > > Ok, I went with "Displaying per-CPU statistics" and > "Displaying global CPU statistics". cool! thanks. :) i've discovered a few other top-related issues and will be posting problem reports and patches throughout the next week. i also got a mail by bruce evans describing some more issues. since some of them are pretty techie, i might not be able to provide patches for each one of them, however i'll try to document them all. cheers. alex > > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 20:33:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11C251065673; Mon, 11 Jul 2011 20:33:45 +0000 (UTC) (envelope-from lacombar@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 C7BF18FC08; Mon, 11 Jul 2011 20:33:44 +0000 (UTC) Received: by mail-pv0-f182.google.com with SMTP id 11so4131929pvg.13 for ; Mon, 11 Jul 2011 13:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mq7Mrsqv9qxK21E7XSuDNvD3yGUqI9tFAUpyr4uVwaM=; b=tlhim085MzZk+lROy+yRx5jfIwY3SGsCOVX1o6lf9pOfA9LJYloQPw4PkcBtbA5m1Q JsQtTeJt5r+WOsGjfsr+ADYAl/dIWyMGk4RPxQ/8MtBohm2HR9vBcQ2Q0ym66V0MXH34 PIp9WtHJvCa/fgP0OfxhYO4M27UHd9o+9bk4I= MIME-Version: 1.0 Received: by 10.68.48.68 with SMTP id j4mr7029305pbn.407.1310416424624; Mon, 11 Jul 2011 13:33:44 -0700 (PDT) Received: by 10.68.49.42 with HTTP; Mon, 11 Jul 2011 13:33:44 -0700 (PDT) In-Reply-To: References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> Date: Mon, 11 Jul 2011 16:33:44 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, Steve Kargl , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 20:33:45 -0000 Hi, On Thu, Jul 7, 2011 at 7:45 PM, Adrian Chadd wrote: > (OT, yes, but I'd like to take a stab at explaining "why" these things > fall to the wayside..) > > On 7 July 2011 12:08, Arnaud Lacombe wrote: > >> What would be the point to even start looking at an issue? You guys >> (by "you", I mean "official" committers on public list) don't care > > When someone who has an active interest takes ownership of the problem. > >> about people providing patches, might it be for trivial, obvious, >> fixes. I'm not even talking about complex patches ... When you >> eventually ends up providing a patch, you ends up being slammed a door >> at by maintainers asserting their code is perfect, until logic and >> user complaints prove them wrong. >> >> That said, this comment is off-topic, but I will certainly re-state >> this next month when I'll be ping'ing trivial patches. > > The problem is that someone doesn't own the problem. > > If I commit someone's fix to the tree without really understanding > what's going on, I take ownership of that change and any > issues/breakages/changes that it creates. > > The people responsible for these areas are likely very busy with other > things. It's not that they don't want to help! It's much more likely > that they don't have the time. > > Trivial patches aren't always so trivial. You can change the behaviour > of something subtle which works great for you and not for others. This > is very likely what's going on with IO/CPU scheduling. It's a tricky > area. A simple fix isn't always as simple. > > So if there's a diagnosed problem, with reproducable test cases and > some patches which fix it, I suggest doing something like the > following: > > * create a webpage, even if it's a wiki somewhere (even > wiki.freebsd.org if you ask someone nicely) > * dump all the information you can in there. Having stuff in emails is > great - but it's only really helpful for tracking the 'flow' of a > discussion. Having a summarised analysis of all of that on a webpage > is much more helpful. > * Add the patches there. > * Encourage people who aren't in your immediate community to try them > too - to try and find if your changes mess up other configurations > somehow. > * Be persistent trying to get your changes in. If you've done the > background research, done some wide-spread testing and show you've not > caused any obvious regressions, you're much more likely to get your > changes in. > For the record, I would like to see enforced public review for _every_ patch *before* it is checked in, as a strong rule. gcc system is particularly interesting. But it is not likely to happen in FreeBSD where FreeBSD committers are clearly more free than other at checking-in un-publicly-reviewed stuff (especially _bad_ stuff). This would of course apply even to long-time committers, no matter how it hurt their ego (which I definitively do not care about). - Arnaud > With all of that done, you can likely find a committer who will help > you get your fixes into the tree. > > Please just try not to interpret a lack of response as a lack of > interest. There's only so much time in the day and committers tend to > be a busy bunch, with day jobs that may in no way reflect their > FreeBSD interests. > > Finally, if people do enough of the above and begin to take ownership > of parts of the tree, you'll find someone will likely sponsor you for > a commit bit. > > HTH, > > > Adrian > From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 20:40:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8F021065672; Mon, 11 Jul 2011 20:40:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8BC8FC12; Mon, 11 Jul 2011 20:40:49 +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 p6BKenYF099021; Mon, 11 Jul 2011 13:40:49 -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 p6BKenuY099020; Mon, 11 Jul 2011 13:40:49 -0700 (PDT) (envelope-from sgk) Date: Mon, 11 Jul 2011 13:40:49 -0700 From: Steve Kargl To: Arnaud Lacombe Message-ID: <20110711204049.GA98996@troutmask.apl.washington.edu> References: <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> 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: Adrian Chadd , FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 20:40:49 -0000 On Mon, Jul 11, 2011 at 04:33:44PM -0400, Arnaud Lacombe wrote: > > For the record, I would like to see enforced public review for _every_ > patch *before* it is checked in, as a strong rule. gcc system is > particularly interesting. But it is not likely to happen in FreeBSD > where FreeBSD committers are clearly more free than other at > checking-in un-publicly-reviewed stuff (especially _bad_ stuff). > > This would of course apply even to long-time committers, no matter how > it hurt their ego (which I definitively do not care about). > As a long time GCC committer, I think that you have grossly over-simplified the GCC review process and how a submitted patch is approved for committing. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 21:14:53 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CD69106564A for ; Mon, 11 Jul 2011 21:14:53 +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 87B788FC1C for ; Mon, 11 Jul 2011 21:14:52 +0000 (UTC) Received: from porto.starpoint.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 AAA28847; Tue, 12 Jul 2011 00:14:49 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QgNoX-000N34-AR; Tue, 12 Jul 2011 00:14:49 +0300 Message-ID: <4E1B67C7.8040402@FreeBSD.org> Date: Tue, 12 Jul 2011 00:14:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Arnaud Lacombe References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 21:14:53 -0000 on 11/07/2011 23:33 Arnaud Lacombe said the following: > For the record, I would like to see enforced public review for _every_ > patch *before* it is checked in, as a strong rule. gcc system is > particularly interesting. But it is not likely to happen in FreeBSD > where FreeBSD committers are clearly more free than other at > checking-in un-publicly-reviewed stuff (especially _bad_ stuff). > > This would of course apply even to long-time committers, no matter how > it hurt their ego (which I definitively do not care about). Have you just volunteered to review all of the patches that I would like to commit? And are you prepared to take responsibility for quality of your reviews? I am sure that other developers will gladly accept your offer too. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 21:38:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DC3A1065672; Mon, 11 Jul 2011 21:38:22 +0000 (UTC) (envelope-from lacombar@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 01A568FC0C; Mon, 11 Jul 2011 21:38:21 +0000 (UTC) Received: by pvg11 with SMTP id 11so4204249pvg.13 for ; Mon, 11 Jul 2011 14:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6RcsUVCy9rUjpK8kfpOXi6pH8A4mZF85yKApD3bR6l4=; b=eTi2eXGWAAVpS6h60SO1VgCHXdGN2eJ309w+UZbbCghpULn6heWZBkkwkkA7G+pXjZ h9DMXTTjGvJqrBbbs/cFI2B2UVUT7vx8APRkNwmsfurUAfSLGrNCoXfboP1XkKpEh3Hp U4iAVlMCWYBoLXuhJHf0MQjlVzFzSuAmxk27Y= MIME-Version: 1.0 Received: by 10.68.32.165 with SMTP id k5mr7923900pbi.273.1310420301441; Mon, 11 Jul 2011 14:38:21 -0700 (PDT) Received: by 10.68.49.42 with HTTP; Mon, 11 Jul 2011 14:38:21 -0700 (PDT) In-Reply-To: <20110711204049.GA98996@troutmask.apl.washington.edu> References: <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <20110711204049.GA98996@troutmask.apl.washington.edu> Date: Mon, 11 Jul 2011 17:38:21 -0400 Message-ID: From: Arnaud Lacombe To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Cc: Adrian Chadd , FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 21:38:22 -0000 Hi, On Mon, Jul 11, 2011 at 4:40 PM, Steve Kargl wrote: > On Mon, Jul 11, 2011 at 04:33:44PM -0400, Arnaud Lacombe wrote: >> >> For the record, I would like to see enforced public review for _every_ >> patch *before* it is checked in, as a strong rule. gcc system is >> particularly interesting. But it is not likely to happen in FreeBSD >> where FreeBSD committers are clearly more free than other at >> checking-in un-publicly-reviewed stuff (especially _bad_ stuff). >> >> This would of course apply even to long-time committers, no matter how >> it hurt their ego (which I definitively do not care about). >> > > As a long time GCC committer, I think that you have grossly > over-simplified the GCC review process and how a submitted > patch is approved for committing. > Yes. - Arnaud From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 21:48:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D90261065672 for ; Mon, 11 Jul 2011 21:48:06 +0000 (UTC) (envelope-from lacombar@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 A2D028FC1B for ; Mon, 11 Jul 2011 21:48:06 +0000 (UTC) Received: by pvg11 with SMTP id 11so4214617pvg.13 for ; Mon, 11 Jul 2011 14:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/qfTeVfYRhf2ROQpIXJvTlIo6OxQQijjlXZ89Pot8rw=; b=YIYa6Kw2yre7b3kP+UAPgeO2MCEtrlgUfPUbCKuCjfoo0aTPzBPaJqj46xxowi59PL FG30nXa16FzKJl6hlWxgMOIJ1YkyWSBRvjizvM2GEURgiocT05Nu51cnfjfHGPHhffav AyvZUdKsY99QZ4dECs6Zm/DPsPl6DRzIltqrw= MIME-Version: 1.0 Received: by 10.68.41.34 with SMTP id c2mr7922727pbl.340.1310420886153; Mon, 11 Jul 2011 14:48:06 -0700 (PDT) Received: by 10.68.49.42 with HTTP; Mon, 11 Jul 2011 14:48:06 -0700 (PDT) In-Reply-To: <4E1B67C7.8040402@FreeBSD.org> References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <4E1B67C7.8040402@FreeBSD.org> Date: Mon, 11 Jul 2011 17:48:06 -0400 Message-ID: From: Arnaud Lacombe To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 21:48:06 -0000 Hi, On Mon, Jul 11, 2011 at 5:14 PM, Andriy Gapon wrote: > on 11/07/2011 23:33 Arnaud Lacombe said the following: >> For the record, I would like to see enforced public review for _every_ >> patch *before* it is checked in, as a strong rule. gcc system is >> particularly interesting. But it is not likely to happen in FreeBSD >> where FreeBSD committers are clearly more free than other at >> checking-in un-publicly-reviewed stuff (especially _bad_ stuff). >> >> This would of course apply even to long-time committers, no matter how >> it hurt their ego (which I definitively do not care about). > > Have you just volunteered to review all of the patches that I would like = to > commit? =A0And are you prepared to take responsibility for quality of you= r reviews? > I am sure that other developers will gladly accept your offer too. > _No-one_ can do all the reviews, especially not me (on a purely technical level). ACK must come from subsystem maintainers. Having public review would allow the community review, which is now just not possible today. As about patches from the maintainer, they might be committed without his approval, but still sent for review. If a maintainer goes outside his area, he has to get approval from the other subsystem maintainer. - Arnaud From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 21:50:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9231D10656AB; Mon, 11 Jul 2011 21:50:45 +0000 (UTC) (envelope-from lacombar@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 548168FC20; Mon, 11 Jul 2011 21:50:45 +0000 (UTC) Received: by pvg11 with SMTP id 11so4217296pvg.13 for ; Mon, 11 Jul 2011 14:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TQqBeUi00VHs2aMCPDIIX8zLNzLfkeWV9eN0NUilYXQ=; b=i1PG40KAReIuo3kU9vGDD+w0vKtJRydK++25JCqk9ryRm4JM4mnYr1svmw2RZvt64z a/BN+9idMdeVD0/iIdZdZeMGWxB9C0o7VsZddboyysKE5e1iOPyloJfuJPM5VRrenJlH uWAPS3gF6jq1dhlvnaoTOioeEyx6xlOZJSV4E= MIME-Version: 1.0 Received: by 10.68.41.34 with SMTP id c2mr7924714pbl.340.1310421044611; Mon, 11 Jul 2011 14:50:44 -0700 (PDT) Received: by 10.68.49.42 with HTTP; Mon, 11 Jul 2011 14:50:44 -0700 (PDT) In-Reply-To: References: <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <20110711204049.GA98996@troutmask.apl.washington.edu> Date: Mon, 11 Jul 2011 17:50:44 -0400 Message-ID: From: Arnaud Lacombe To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Cc: Adrian Chadd , FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 21:50:45 -0000 Hi, [re-sent publicly, I did not "Replied-to-all":)] On Mon, Jul 11, 2011 at 5:38 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Jul 11, 2011 at 4:40 PM, Steve Kargl > wrote: >> On Mon, Jul 11, 2011 at 04:33:44PM -0400, Arnaud Lacombe wrote: >>> >>> For the record, I would like to see enforced public review for _every_ >>> patch *before* it is checked in, as a strong rule. gcc system is >>> particularly interesting. But it is not likely to happen in FreeBSD >>> where FreeBSD committers are clearly more free than other at >>> checking-in un-publicly-reviewed stuff (especially _bad_ stuff). >>> >>> This would of course apply even to long-time committers, no matter how >>> it hurt their ego (which I definitively do not care about). >>> >> >> As a long time GCC committer, I think that you have grossly >> over-simplified the GCC review process and how a submitted >> patch is approved for committing. >> > Yes. > Just to provide information more information than these sterile mails, here is the gcc contribution guidelines: http://gcc.gnu.org/contribute.html - Arnaud From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 22:13:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25C9B106566B; Mon, 11 Jul 2011 22:13:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id EAE148FC16; Mon, 11 Jul 2011 22:13:22 +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 p6BMDMJP099468; Mon, 11 Jul 2011 15:13:22 -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 p6BMDMXJ099467; Mon, 11 Jul 2011 15:13:22 -0700 (PDT) (envelope-from sgk) Date: Mon, 11 Jul 2011 15:13:22 -0700 From: Steve Kargl To: Arnaud Lacombe Message-ID: <20110711221322.GA99440@troutmask.apl.washington.edu> References: <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <20110711204049.GA98996@troutmask.apl.washington.edu> 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: Adrian Chadd , FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 22:13:23 -0000 On Mon, Jul 11, 2011 at 05:50:44PM -0400, Arnaud Lacombe wrote: > > On Mon, Jul 11, 2011 at 5:38 PM, Arnaud Lacombe wrote: > > Hi, > > > > On Mon, Jul 11, 2011 at 4:40 PM, Steve Kargl > > wrote: > >> On Mon, Jul 11, 2011 at 04:33:44PM -0400, Arnaud Lacombe wrote: > >>> > >>> For the record, I would like to see enforced public review for _every_ > >>> patch *before* it is checked in, as a strong rule. gcc system is > >>> particularly interesting. But it is not likely to happen in FreeBSD > >>> where FreeBSD committers are clearly more free than other at > >>> checking-in un-publicly-reviewed stuff (especially _bad_ stuff). > >>> > >>> This would of course apply even to long-time committers, no matter how > >>> it hurt their ego (which I definitively do not care about). > >>> > >> > >> As a long time GCC committer, I think that you have grossly > >> over-simplified the GCC review process and how a submitted > >> patch is approved for committing. > >> > > Yes. > > > Just to provide information more information than these sterile mails, > here is the gcc contribution guidelines: > > http://gcc.gnu.org/contribute.html > Which if one reads, one finds http://gcc.gnu.org/svnwrite.html#policies Localized write permission. This is for people who have primary responsibility for ports, front ends, or other specific aspects of the compiler. These folks are allowed to make changes to areas they maintain and related documentation, web pages, and test cases without approval from anyone else, and approve other people's changes in those areas. They must get approval for changes elsewhere in the compiler. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 23:23:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12824106566C; Mon, 11 Jul 2011 23:23:11 +0000 (UTC) (envelope-from mashtizadeh@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 A41188FC13; Mon, 11 Jul 2011 23:23:10 +0000 (UTC) Received: by qwc9 with SMTP id 9so2824477qwc.13 for ; Mon, 11 Jul 2011 16:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eQFgrA3s07/VmwNk6Q0mEgcmlmz5x+HI0zRSnzYUM00=; b=F9PAjYh2sfdWhDS8BW3nGBzXai+IGlaLVvf7cJfs1AXE4NC6LuX8i3L5pv+d3HhwMj mj70RiFBnh6/RKyZKux+C/n1Uh0gVoF1vEna2EM9QbtC/BNpvq33cq3su92xXpdDRvEN 2P8CY51Ss2vRdJLVjOg4cDU2Lg4sY/lgmXt3o= MIME-Version: 1.0 Received: by 10.229.1.67 with SMTP id 3mr4110907qce.150.1310425216521; Mon, 11 Jul 2011 16:00:16 -0700 (PDT) Received: by 10.229.37.12 with HTTP; Mon, 11 Jul 2011 16:00:15 -0700 (PDT) In-Reply-To: References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <4E1B67C7.8040402@FreeBSD.org> Date: Mon, 11 Jul 2011 16:00:15 -0700 Message-ID: From: Ali Mashtizadeh To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Andriy Gapon Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 23:23:11 -0000 Maybe someone can setup something like reviewboard [1] for developers to use. This may also help folks who want to keep abreast of the current work in a particular subsystem or get involved into the development process more. At my company we use reviews and it seems to help the catch some bugs and help new engineers ramp up faster. [1] http://www.reviewboard.org/ ~ Ali On Mon, Jul 11, 2011 at 2:48 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Jul 11, 2011 at 5:14 PM, Andriy Gapon wrote: >> on 11/07/2011 23:33 Arnaud Lacombe said the following: >>> For the record, I would like to see enforced public review for _every_ >>> patch *before* it is checked in, as a strong rule. gcc system is >>> particularly interesting. But it is not likely to happen in FreeBSD >>> where FreeBSD committers are clearly more free than other at >>> checking-in un-publicly-reviewed stuff (especially _bad_ stuff). >>> >>> This would of course apply even to long-time committers, no matter how >>> it hurt their ego (which I definitively do not care about). >> >> Have you just volunteered to review all of the patches that I would like= to >> commit? =C2=A0And are you prepared to take responsibility for quality of= your reviews? >> I am sure that other developers will gladly accept your offer too. >> > _No-one_ can do all the reviews, especially not me (on a purely > technical level). ACK must come from subsystem maintainers. Having > public review would allow the community review, which is now just not > possible today. As about patches from the maintainer, they might be > committed without his approval, but still sent for review. If a > maintainer goes outside his area, he has to get approval from the > other subsystem maintainer. > > =C2=A0- Arnaud > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 23:36:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D70E7106564A for ; Mon, 11 Jul 2011 23:36:20 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 868478FC0C for ; Mon, 11 Jul 2011 23:36:20 +0000 (UTC) Received: by qyk38 with SMTP id 38so2872167qyk.13 for ; Mon, 11 Jul 2011 16:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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 :content-transfer-encoding; bh=9X5O1Hegjju9ODiVyxszEGUWk5/qjg0lESDJwNMvva8=; b=bSC2qzvMIKcOu5sMkiNWMYIpt4xapytHSTodTJCqElC7F4OqR1hsqRYLpBvryNQkeS Dbv/6WmxpxYlWPei1Dm7UKtsHfgx9ZO840mAMUtk+hrKmglw0zSg9FI8MVidZL5c9lV5 s/FMukZGWF0HtHf6Zz0EopRlc8mRPAW/C2QQk= MIME-Version: 1.0 Received: by 10.229.7.137 with SMTP id d9mr4008738qcd.251.1310427379045; Mon, 11 Jul 2011 16:36:19 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.11.40 with HTTP; Mon, 11 Jul 2011 16:36:18 -0700 (PDT) In-Reply-To: References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <4E1B67C7.8040402@FreeBSD.org> Date: Mon, 11 Jul 2011 16:36:18 -0700 X-Google-Sender-Auth: WmDBoLs3p2k6wVW_t9_6IymblhA Message-ID: From: mdf@FreeBSD.org To: Ali Mashtizadeh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Arnaud Lacombe Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 23:36:20 -0000 On Mon, Jul 11, 2011 at 4:00 PM, Ali Mashtizadeh wr= ote: > Maybe someone can setup something like reviewboard [1] for developers > to use. This may also help folks who want to keep abreast of the > current work in a particular subsystem or get involved into the > development process more. At my company we use reviews and it seems to > help the catch some bugs and help new engineers ramp up faster. > > [1] http://www.reviewboard.org/ FreeBSD development is completely open; anyone can sign up for the svn-src-* mailing list they are interested in, including svn-src-head@. Code reviews are plenty as well; just check the list archives for discussion of bugs, poor design choices and unintended effects. But most reviews are silent and after-the-fact by looking at the list mail. It's a system that seems to be working just fine for the FreeBSD project so far. This isn't a job for most anyone; it's a volunteer project and so anything that raises the barrier to getting work done for the project should be looked at with skepticism. Is there a specific deficit that you want to address? Thanks, matthew > On Mon, Jul 11, 2011 at 2:48 PM, Arnaud Lacombe wrot= e: >> Hi, >> >> On Mon, Jul 11, 2011 at 5:14 PM, Andriy Gapon wrote: >>> on 11/07/2011 23:33 Arnaud Lacombe said the following: >>>> For the record, I would like to see enforced public review for _every_ >>>> patch *before* it is checked in, as a strong rule. gcc system is >>>> particularly interesting. But it is not likely to happen in FreeBSD >>>> where FreeBSD committers are clearly more free than other at >>>> checking-in un-publicly-reviewed stuff (especially _bad_ stuff). >>>> >>>> This would of course apply even to long-time committers, no matter how >>>> it hurt their ego (which I definitively do not care about). >>> >>> Have you just volunteered to review all of the patches that I would lik= e to >>> commit? =A0And are you prepared to take responsibility for quality of y= our reviews? >>> I am sure that other developers will gladly accept your offer too. >>> >> _No-one_ can do all the reviews, especially not me (on a purely >> technical level). ACK must come from subsystem maintainers. Having >> public review would allow the community review, which is now just not >> possible today. As about patches from the maintainer, they might be >> committed without his approval, but still sent for review. If a >> maintainer goes outside his area, he has to get approval from the >> other subsystem maintainer. >> >> =A0- Arnaud >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 23:57:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A32E1065672; Mon, 11 Jul 2011 23:57:32 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD4E8FC13; Mon, 11 Jul 2011 23:57:31 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAP+MG06DaFvO/2dsb2JhbABThESjWbk0kHuBK4QAgQ8EkEuCC4lWhw0 X-IronPort-AV: E=Sophos;i="4.65,517,1304308800"; d="scan'208";a="126887714" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 11 Jul 2011 19:57:31 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 42465B3F5A; Mon, 11 Jul 2011 19:57:31 -0400 (EDT) Date: Mon, 11 Jul 2011 19:57:31 -0400 (EDT) From: Rick Macklem To: mdf@FreeBSD.org Message-ID: <1441865969.450238.1310428651218.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Ali Mashtizadeh , FreeBSD Current , Arnaud Lacombe Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2011 23:57:33 -0000 mdf@FreeBSD.org wrote: > On Mon, Jul 11, 2011 at 4:00 PM, Ali Mashtizadeh > wrote: > > Maybe someone can setup something like reviewboard [1] for > > developers > > to use. This may also help folks who want to keep abreast of the > > current work in a particular subsystem or get involved into the > > development process more. At my company we use reviews and it seems > > to > > help the catch some bugs and help new engineers ramp up faster. > > > > [1] http://www.reviewboard.org/ >=20 > FreeBSD development is completely open; anyone can sign up for the > svn-src-* mailing list they are interested in, including > svn-src-head@. Code reviews are plenty as well; just check the list > archives for discussion of bugs, poor design choices and unintended > effects. But most reviews are silent and after-the-fact by looking at > the list mail. It's a system that seems to be working just fine for > the FreeBSD project so far. This isn't a job for most anyone; it's a > volunteer project and so anything that raises the barrier to getting > work done for the project should be looked at with skepticism. >=20 Yes, and if you see a problem with any commit to head (svn-src-head@), you can post to the list about this. Commits to head do not get MFC'd to stable/N until a minimum of 3 days (and usually a couple of weeks), specifically so that anyone can comment on it. If there are serious problems with the commit to head, it can be reverted or fixed via additional commits before it goes into stable/N. rick > Is there a specific deficit that you want to address? >=20 > Thanks, > matthew >=20 > > On Mon, Jul 11, 2011 at 2:48 PM, Arnaud Lacombe > > wrote: > >> Hi, > >> > >> On Mon, Jul 11, 2011 at 5:14 PM, Andriy Gapon > >> wrote: > >>> on 11/07/2011 23:33 Arnaud Lacombe said the following: > >>>> For the record, I would like to see enforced public review for > >>>> _every_ > >>>> patch *before* it is checked in, as a strong rule. gcc system is > >>>> particularly interesting. But it is not likely to happen in > >>>> FreeBSD > >>>> where FreeBSD committers are clearly more free than other at > >>>> checking-in un-publicly-reviewed stuff (especially _bad_ stuff). > >>>> > >>>> This would of course apply even to long-time committers, no > >>>> matter how > >>>> it hurt their ego (which I definitively do not care about). > >>> > >>> Have you just volunteered to review all of the patches that I > >>> would like to > >>> commit? And are you prepared to take responsibility for quality of > >>> your reviews? > >>> I am sure that other developers will gladly accept your offer too. > >>> > >> _No-one_ can do all the reviews, especially not me (on a purely > >> technical level). ACK must come from subsystem maintainers. Having > >> public review would allow the community review, which is now just > >> not > >> possible today. As about patches from the maintainer, they might be > >> committed without his approval, but still sent for review. If a > >> maintainer goes outside his area, he has to get approval from the > >> other subsystem maintainer. > >> > >> =C2=A0- Arnaud > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > >> > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 01:29:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 7E6D5106566B; Tue, 12 Jul 2011 01:29:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 006BC14FA0F; Tue, 12 Jul 2011 01:29:19 +0000 (UTC) Message-ID: <4E1BA36F.5060504@FreeBSD.org> Date: Mon, 11 Jul 2011 18:29:19 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin References: <4E100086.7080105@FreeBSD.org> <201107071720.50203.jhb@freebsd.org> <4E16C463.9020604@FreeBSD.org> <201107080919.58210.jhb@freebsd.org> In-Reply-To: <201107080919.58210.jhb@freebsd.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------070402020403010903060407" Cc: freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 01:29:20 -0000 This is a multi-part message in MIME format. --------------070402020403010903060407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/08/2011 06:19, John Baldwin wrote: > Hmm, well that's odd. It didn't grow it enough it seems. > >>> Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert >>> the card and record the messages in dmesg when it does? (You can likely get >>> those out of kgdb.) I tried your patch, and got some odd results. The good news is, no crash. However it did not actually enable the cards, with or without if_ath being loaded before inserting them. Here is the dmesg output with debug.bootverbose=1. This is with inserting and removing first one card, then the other. pcib5: attempting to grow memory window for (0x88000000-0xffffffff,0x10000) back candidate range: 0x88000000-0x8800ffff pcib5: grew memory window to 0x80000000-0x880fffff pcib5: allocated memory range (0x88000000-0x8800ffff) for rid 10 of pci0:4:0:0 found-> vendor=0x168c, dev=0x0023, revid=0x01 domain=0, bus=4, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 cardbus0: at device 0.0 (no driver attached) map[10]: type Memory, range 32, base 0, size 16, memory disabled pcib5: allocated memory range (0x88000000-0x8800ffff) for rid 10 of pci0:4:0:0 found-> vendor=0x168c, dev=0x0023, revid=0x01 domain=0, bus=4, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 cardbus0: at device 0.0 (no driver attached) pcib5: allocated memory range (0x88000000-0x8800ffff) for rid 10 of pci0:4:0:0 unknown: Lazy allocation of 0x10000 bytes rid 0x10 type 3 at 0x88000000 cbb0: Opening memory: cbb0: Normal: 0x88000000-0x8800ffff cbb0: Opening memory: cbb0: Opening memory: cbb0: Normal: 0x88000000-0x8800ffff cbb0: Opening memory: found-> vendor=0x168c, dev=0x0013, revid=0x01 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=18 powerspec 2 supports D0 D3 current D0 cardbus0: at device 0.0 (no driver attached) pci0:4:0:0: Transition from D0 to D3 > The real messages I will want to see are in the dmesg. Also, getting the > output of 'devinfo -r' before you insert the card would also be helpful so > I can see what it is growing from. Attached. Thanks for looking into this, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------070402020403010903060407 Content-Type: text/plain; name="devinfo" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="devinfo" nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x100000-0x7fe813ff acpi0 Interrupt request lines: 9 I/O ports: 0x20-0x21 0x2e-0x2f 0x4e-0x4f 0x86 0x92 0xa0-0xa1 0xb2 0xb3 0x4d0-0x4d1 0x809 0x910-0x91f 0x920-0x92f 0x930-0x97f 0xc80-0xcaf 0xcbc-0xcbf 0xcc0-0xcff 0x1000-0x1005 0x1006-0x1007 0x1008-0x1059 0x1060-0x107f 0x1080-0x10bf 0x10c0-0x10df 0xf400-0xf4fe I/O memory addresses: 0x9fc00-0x9ffff 0xc0000-0xcffff 0xe0000-0xfffff 0x7fe81400-0x7fefffff 0x7ff00000-0x7fffffff 0xf0000000-0xf3ffffff 0xf4000000-0xf4003fff 0xf4004000-0xf4004fff 0xf4005000-0xf4005fff 0xf4006000-0xf4006fff 0xf4008000-0xf400bfff 0xfec00000-0xfec0ffff 0xfed20000-0xfed3ffff 0xfed45000-0xfed9ffff 0xfee00000-0xfee0ffff 0xffa80000-0xffa83fff 0xffb00000-0xffffffff cpu0 ACPI I/O ports: 0x1014 0x1016 est0 acpi_perf0 cpufreq0 coretemp0 cpu1 ACPI I/O ports: 0x1014 0x1016 est1 acpi_perf1 cpufreq1 coretemp1 acpi_acad0 battery0 battery1 acpi_lid0 acpi_button0 acpi_button1 acpi_sysresource0 pcib0 pci0 hostb0 pcib1 I/O memory addresses: 0xd0000000-0xdfffffff 0xed000000-0xefefffff pci1 vgapci0 Interrupt request lines: 16 pcib1 memory window: 0xed000000-0xedffffff 0xee000000-0xeeffffff pcib1 prefetch window: 0xd0000000-0xdfffffff vgapm0 nvidia0 hdac0 Interrupt request lines: 256 I/O memory addresses: 0xefffc000-0xefffffff pcm0 pcib2 pci11 pcib3 I/O memory addresses: 0xecf00000-0xecffffff pci12 wpi0 Interrupt request lines: 17 pcib3 memory window: 0xecfff000-0xecffffff pcib4 I/O memory addresses: 0xece00000-0xecefffff pci9 uhci0 Interrupt request lines: 20 I/O ports: 0xbf80-0xbf9f usbus0 uhub0 uhci1 Interrupt request lines: 21 I/O ports: 0xbf60-0xbf7f usbus1 uhub1 uhci2 Interrupt request lines: 22 I/O ports: 0xbf40-0xbf5f usbus2 uhub2 ums0 uhci3 Interrupt request lines: 23 I/O ports: 0xbf20-0xbf3f usbus3 uhub3 ehci0 Interrupt request lines: 20 ACPI I/O memory addresses: 0xffa80000-0xffa803ff usbus4 uhub4 uhub5 uhub6 pcib5 I/O memory addresses: 0x80000000-0x800fffff pci3 cbb0 Interrupt request lines: 18 pcib5 memory window: 0x80000000-0x80000fff cardbus0 pccard0 isab0 isa0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 ACPI I/O memory addresses: 0xc0000-0xcffff atapci0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xbfa0-0xbfaf ata0 Interrupt request lines: 14 ad0 atapicam0 ata1 Interrupt request lines: 15 acd0 atapicam1 acpi_sysresource1 acpi_sysresource2 psmcpnp0 atkbdc0 Interrupt request lines: 1 I/O ports: 0x60 0x62 0x64 0x66 atkbd0 psm0 Interrupt request lines: 12 atrtc0 Interrupt request lines: 8 I/O ports: 0x70-0x71 0x72-0x77 attimer0 Interrupt request lines: 0 I/O ports: 0x40-0x43 0x50-0x53 acpi_sysresource3 atdma0 DMA request lines: 4 I/O ports: 0x0-0xf 0x10-0x1f 0x80-0x85 0x87-0x8f 0x90-0x91 0x93-0x9f 0xc0-0xdf fpupnp0 I/O ports: 0xf0-0xff hpet0 Interrupt request lines: 20 I/O memory addresses: 0xfed00000-0xfed003ff uart0 Interrupt request lines: 4 I/O ports: 0x3f8-0x3ff pci_link0 pci_link1 pci_link2 pci_link3 pci_link4 pci_link5 pci_link6 pci_link7 acpi_tz0 acpi_timer0 ACPI I/O ports: 0x1008-0x100b --------------070402020403010903060407-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 07:49:16 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AD5C1065670 for ; Tue, 12 Jul 2011 07:49:16 +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 BC0188FC0C for ; Tue, 12 Jul 2011 07:49:15 +0000 (UTC) Received: from porto.starpoint.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 KAA06358; Tue, 12 Jul 2011 10:49:12 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QgXiS-000Pja-Fr; Tue, 12 Jul 2011 10:49:12 +0300 Message-ID: <4E1BFC77.6080203@FreeBSD.org> Date: Tue, 12 Jul 2011 10:49:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Arnaud Lacombe References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <4E1B67C7.8040402@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 07:49:16 -0000 on 12/07/2011 00:48 Arnaud Lacombe said the following: > Hi, > > On Mon, Jul 11, 2011 at 5:14 PM, Andriy Gapon wrote: >> on 11/07/2011 23:33 Arnaud Lacombe said the following: >>> For the record, I would like to see enforced public review for _every_ >>> patch *before* it is checked in, as a strong rule. gcc system is >>> particularly interesting. But it is not likely to happen in FreeBSD >>> where FreeBSD committers are clearly more free than other at >>> checking-in un-publicly-reviewed stuff (especially _bad_ stuff). >>> >>> This would of course apply even to long-time committers, no matter how >>> it hurt their ego (which I definitively do not care about). >> >> Have you just volunteered to review all of the patches that I would like to >> commit? And are you prepared to take responsibility for quality of your reviews? >> I am sure that other developers will gladly accept your offer too. >> > _No-one_ can do all the reviews, especially not me (on a purely > technical level). OK, I see, so your plan heavily depends on other people doing something (actually, a lot) according to your ideals. I see how realistic this suggestion is. This is a volunteer project. So, people who want to get something done usually start with themselves, not with telling other people what they should do. > ACK must come from subsystem maintainers. Having > public review would allow the community review, which is now just not > possible today. So far I see that a number of requests for review posted to public mailing lists is greater than a number of actual reviews done. Also, notifications of all changes to the src tree are posted to public mailing lists, so post-commit reviews can also be easily performed. Not seeing too many of those, though. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 08:05:21 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5781106564A for ; Tue, 12 Jul 2011 08:05:21 +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 056888FC14 for ; Tue, 12 Jul 2011 08:05:20 +0000 (UTC) Received: from porto.starpoint.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 LAA07126; Tue, 12 Jul 2011 11:05:16 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QgXy0-000PkH-0Y; Tue, 12 Jul 2011 11:05:16 +0300 Message-ID: <4E1C003B.4090604@FreeBSD.org> Date: Tue, 12 Jul 2011 11:05:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Steve Kargl References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> <20110707151440.GA75537@troutmask.apl.washington.edu> <4E160C2F.8020001@FreeBSD.org> <20110707200845.GA77049@troutmask.apl.washington.edu> <4E1B1198.6090308@FreeBSD.org> <20110711161654.GA97361@troutmask.apl.washington.edu> In-Reply-To: <20110711161654.GA97361@troutmask.apl.washington.edu> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 08:05:21 -0000 on 11/07/2011 19:16 Steve Kargl said the following: > On Mon, Jul 11, 2011 at 06:07:04PM +0300, Andriy Gapon wrote: >> But it's not clear which of the processes are slaves and which is master. >> It's also not clear why the master takes so much CPU (on par with the >> slaves) - >> from my reading of its description (by Steve) it should be doing only light >> periodic work. > > These are all slave processes. The master process was on a different > node in the cluster. Each process is doing the exact same computation > with only a small change in a coordinate from (x,y,z) to (x,y+n*dy,z) > with n = 1, 2, 3, 4. The small change does not causes a different > code path, so all should complete in nearly identical times. OK, the situation is much clearer (to me) now. >> If it does have to do CPU-heavy work, then I'd imagine that it should >> spawn only Ncpus - 1 slaves. > > And if you have M users on the system? Also note, you can get the > exact same loading problem by launching Ncpu+1 completely independent > cpu-bound processes. Ncpu-1 processes will be bound to specific cpus > and 2 processes will ping-pong on one cpu. This ping-ponging will > simply kill performance. I'd still argue that if someone cares about doing some calculations as fast as possible then he shouldn't have more than Ncpu CPU-bound processes. How to achieve that is a technical/administrative issue. But nevertheless I now see what the problem is. I think that the best thing you can further provide (as objective evidence for the problem at hand) is ktr(4) traces for at least KTR_SCHED mask. Perhaps you even already have them from your previous sessions with Jeff. P.S. This is not a promise to actually debug this issue based on the traces :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 10:31:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8448C1065679 for ; Tue, 12 Jul 2011 10:31:26 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 136938FC16 for ; Tue, 12 Jul 2011 10:31:25 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id p6CAATWl009467 for ; Tue, 12 Jul 2011 19:10:29 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili17) with ESMTP id p6CAATf10855 for ; Tue, 12 Jul 2011 19:10:29 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi12) id p6CAAT1G022397 for freebsd-current@freebsd.org; Tue, 12 Jul 2011 19:10:29 +0900 Received: from localhost by lomi12.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id p6CAATFk022370 for ; Tue, 12 Jul 2011 19:10:29 +0900 Date: Tue, 12 Jul 2011 19:10:28 +0900 (JST) Message-Id: <20110712.191028.650619413057975749.okuno.kohji@jp.panasonic.com> To: freebsd-current@freebsd.org From: Kohji Okuno Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Bug about devfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 10:31:26 -0000 Hello, I think that devfs has a problem. I encountered the problem that open("/dev/AAA") returned ENOENT. Of course, /dev/AAA exists. ENOENT was created by the point(***) in devfs_allocv(). I think that the race condition had occurred between process A and vnlru kernel thread. Please check the following. If vnlru set VI_DOOMED to vp->v_iflag but vnlru didn't still execute VOP_RECLAIM(), process A cat get valid vp from de->de_vnode. But, vget() will return ENOENT, because vp->v_iflag has VI_DOOMED. When I set the break point to (***), I checked that de->de_vnode and vp->v_data were NULL. process A: vnlru: devfs_allocv() { vgonel(vp) { ... ... vp->v_iflag |= VI_DOOMED; mtx_lock(&devfs_de_interlock); ... vp = de->de_vnode; if (vp != NULL) { VI_UNLOCK(vp); _____________/ ... VI_LOCK(vp); ____________/ if (VOP_RECLAIM(vp, td)) mtx_unlock(&devfs_de_interlock); ... ... \ devfs_reclaim(ap) { error = vget(vp,...); \ ... \______ mtx_lock(&devfs_de_interlock); if (devfs_allocv_drop_refs(...)) { de = vp->v_data; ... if (de != NULL) { } de->de_vnode = NULL; else if (error) { vp->v_data = NULL; ... } rturn (error); (***) mtx_unlock(&devfs_de_interlock); } ... } I think that devfs_allocv() should be fixed as below. How do you think? devfs_allocv(struct devfs_dirent *de, struct mount *mp, struct vnode **vpp) { int error; struct vnode *vp; struct cdev *dev; struct devfs_mount *dmp; dmp = VFSTODEVFS(mp); +#if 1 + retry: +#endif if (de->de_flags & DE_DOOMED) { ... mtx_lock(&devfs_de_interlock); vp = de->de_vnode; if (vp != NULL) { VI_LOCK(vp); mtx_unlock(&devfs_de_interlock); sx_xunlock(&dmp->dm_lock); error = vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, curthread); sx_xlock(&dmp->dm_lock); if (devfs_allocv_drop_refs(0, dmp, de)) { if (error == 0) vput(vp); return (ENOENT); } else if (error) { +#if 1 + if (error == ENOENT) + goto retry; +#endif sx_xunlock(&dmp->dm_lock); return (error); } Thanks, Kohji Okuno. From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 10:35:35 2011 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 8717F106566B; Tue, 12 Jul 2011 10:35:35 +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 1E3BF8FC13; Tue, 12 Jul 2011 10:35:34 +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 p6CAZRBD080097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2011 13:35:27 +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 p6CAZQrK092183; Tue, 12 Jul 2011 13:35:26 +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 p6CAZQfM092182; Tue, 12 Jul 2011 13:35:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Jul 2011 13:35:26 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110712103526.GF43872@deviant.kiev.zoral.com.ua> References: <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qJM7dOmrnYWq+SaN" 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 10:35:35 -0000 --qJM7dOmrnYWq+SaN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2011 at 11:16:28AM +0200, Petr Salinger wrote: > >>Seems this interface be acceptable ? > > > >Looks good to me. >=20 > The proposed code changes are in the attached patch. >=20 > Proposed wording of addition into RFORK(2): Below is the patch I intend to commit after you retest it. I added the checks for validity of the flags, and some rewording to the manual page. diff --git a/lib/libc/sys/rfork.2 b/lib/libc/sys/rfork.2 index f1ae14b..993fd1b 100644 --- a/lib/libc/sys/rfork.2 +++ b/lib/libc/sys/rfork.2 @@ -5,7 +5,7 @@ .\" .\" $FreeBSD$ .\" -.Dd March 15, 2011 +.Dd July 12, 2011 .Dt RFORK 2 .Os .Sh NAME @@ -84,6 +84,16 @@ Note that a lot of code will not run correctly in such a= n environment. .It Dv RFSIGSHARE If set, the kernel will force sharing the sigacts structure between the child and the parent. +.It Dv RFTSIGZMB +If set, the kernel will deliver a specified signal to the parent +upon the child exit, instead of default SIGCHILD. +The signal number +.Dv signum +is specified by oring the +.Dv RFTSIGFLAGS(signum) +expression into +.Fa flags . +Specifying signal number 0 disables signal delivery upon the child exit. .It Dv RFLINUXTHPN If set, the kernel will return SIGUSR1 instead of SIGCHILD upon thread exit for the child. @@ -164,6 +174,8 @@ would be exceeded (see Both the RFFDG and the RFCFDG flags were specified. .It Bq Er EINVAL Any flags not listed above were specified. +.It Bq Er EINVAL +An invalid signal number was specified. .It Bq Er ENOMEM There is insufficient swap space for the new process. .El diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index a8abd8e..9d3e22d 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -476,7 +476,10 @@ do_fork(struct thread *td, int flags, struct proc *p2,= struct thread *td2, sigacts_copy(newsigacts, p1->p_sigacts); p2->p_sigacts =3D newsigacts; } - if (flags & RFLINUXTHPN)=20 + + if (flags & RFTSIGZMB) + p2->p_sigparent =3D RFTSIGNUM(flags); + else if (flags & RFLINUXTHPN) p2->p_sigparent =3D SIGUSR1; else p2->p_sigparent =3D SIGCHLD; @@ -719,10 +722,22 @@ fork1(struct thread *td, int flags, int pages, struct= proc **procp) static int curfail; static struct timeval lastfail; =20 + /* Check for the undefined or unimplemented flags. */ + if ((flags & ~(RFFLAGS | RFTSIGFLAGS(RFTSIGMASK))) !=3D 0) + return (EINVAL); + + /* Signal value requires RFTSIGZMB. */ + if ((flags & RFTSIGFLAGS(RFTSIGMASK)) !=3D 0 && (flags & RFTSIGZMB) =3D= =3D 0) + return (EINVAL); + /* Can't copy and clear. */ if ((flags & (RFFDG|RFCFDG)) =3D=3D (RFFDG|RFCFDG)) return (EINVAL); =20 + /* Check the validity of the signal number. */ + if ((flags & RFTSIGZMB) !=3D 0 && (u_int)RFTSIGNUM(flags) > _SIG_MAXSIG) + return (EINVAL); + p1 =3D td->td_proc; =20 /* diff --git a/sys/sys/unistd.h b/sys/sys/unistd.h index 378308d..9d56a3a 100644 --- a/sys/sys/unistd.h +++ b/sys/sys/unistd.h @@ -180,8 +180,16 @@ #define RFLINUXTHPN (1<<16) /* do linux clone exit parent notification */ #define RFSTOPPED (1<<17) /* leave child in a stopped state */ #define RFHIGHPID (1<<18) /* use a pid higher than 10 (idleproc) */ +#define RFTSIGZMB (1<<19) /* select signal for exit parent notification */ +#define RFTSIGSHIFT 20 /* selected signal number is in bits 20-27 */ +#define RFTSIGMASK 0xFF +#define RFTSIGNUM(flags) (((flags) >> RFTSIGSHIFT) & RFTSIGMASK) +#define RFTSIGFLAGS(signum) ((signum) << RFTSIGSHIFT) #define RFPPWAIT (1<<31) /* parent sleeps until child exits (vfork) */ #define RFKERNELONLY (RFSTOPPED | RFHIGHPID | RFPPWAIT) +#define RFFLAGS (RFFDG | RFPROC | RFMEM | RFNOWAIT | RFCFDG | \ + RFTHREAD | RFSIGSHARE | RFLINUXTHPN | RFSTOPPED | RFHIGHPID | RFTSIGZM= B | \ + RFPPWAIT) =20 #endif /* __BSD_VISIBLE */ =20 --qJM7dOmrnYWq+SaN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4cI20ACgkQC3+MBN1Mb4hM7gCeIk2P6FoqM7j24okpKp/hpnj8 ryEAoM3cL/0UcCUBjoes4UUS/nU5P8ZC =nlxa -----END PGP SIGNATURE----- --qJM7dOmrnYWq+SaN-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 09:07:45 2011 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 2B527106564A; Tue, 12 Jul 2011 09:07:45 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id BC5308FC13; Tue, 12 Jul 2011 09:07:44 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6C97T8F039166; Tue, 12 Jul 2011 11:07:29 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Tue, 12 Jul 2011 11:16:28 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110711180246.GA43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="546530387-125356705-1310462188=:10573" X-FELK-MailScanner-Information: X-MailScanner-ID: p6C97T8F039166 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311066452.38149@HEepPH6xI6E9buxH/JsZtQ X-Spam-Status: No X-Mailman-Approved-At: Tue, 12 Jul 2011 11:09:50 +0000 Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 09:07:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --546530387-125356705-1310462188=:10573 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> Seems this interface be acceptable ? > > Looks good to me. The proposed code changes are in the attached patch. Proposed wording of addition into RFORK(2): DESCRIPTION: RFTSIGZMB If set, the kernel will return selected signal number instead of SIGCHILD upon thread exit for the child. The selected signal number have to be encoded into flags by ORing RFTSIGFLAGS(signum). ERRORS: EINVAL An invalid signal was specified. Petr --546530387-125356705-1310462188=:10573 Content-Type: TEXT/x-diff; name=006_lt-rf.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=006_lt-rf.diff LS0tIGEvc3lzL2tlcm4va2Vybl9mb3JrLmMNCisrKyBiL3N5cy9rZXJuL2tl cm5fZm9yay5jDQpAQCAtNDc2LDcgKzQ3NiwxMCBAQA0KIAkJc2lnYWN0c19j b3B5KG5ld3NpZ2FjdHMsIHAxLT5wX3NpZ2FjdHMpOw0KIAkJcDItPnBfc2ln YWN0cyA9IG5ld3NpZ2FjdHM7DQogCX0NCi0JaWYgKGZsYWdzICYgUkZMSU5V WFRIUE4pIA0KKw0KKwlpZiAoZmxhZ3MgJiBSRlRTSUdaTUIpDQorCSAgICAg ICAgcDItPnBfc2lncGFyZW50ID0gUkZUU0lHTlVNKGZsYWdzKTsNCisJZWxz ZSBpZiAoZmxhZ3MgJiBSRkxJTlVYVEhQTikNCiAJICAgICAgICBwMi0+cF9z aWdwYXJlbnQgPSBTSUdVU1IxOw0KIAllbHNlDQogCSAgICAgICAgcDItPnBf c2lncGFyZW50ID0gU0lHQ0hMRDsNCkBAIC03MjMsNiArNzI2LDkgQEANCiAJ aWYgKChmbGFncyAmIChSRkZER3xSRkNGREcpKSA9PSAoUkZGREd8UkZDRkRH KSkNCiAJCXJldHVybiAoRUlOVkFMKTsNCiANCisJaWYgKChmbGFncyAmIFJG VFNJR1pNQikgJiYgKFJGVFNJR05VTShmbGFncykgPiBfU0lHX01BWFNJRykp DQorCQlyZXR1cm4gKEVJTlZBTCk7DQorDQogCXAxID0gdGQtPnRkX3Byb2M7 DQogDQogCS8qDQotLS0gYS9zeXMvc3lzL3VuaXN0ZC5oDQorKysgYi9zeXMv c3lzL3VuaXN0ZC5oDQpAQCAtMTgwLDYgKzE4MCwxMSBAQA0KICNkZWZpbmUJ UkZMSU5VWFRIUE4JKDE8PDE2KQkvKiBkbyBsaW51eCBjbG9uZSBleGl0IHBh cmVudCBub3RpZmljYXRpb24gKi8NCiAjZGVmaW5lCVJGU1RPUFBFRAkoMTw8 MTcpCS8qIGxlYXZlIGNoaWxkIGluIGEgc3RvcHBlZCBzdGF0ZSAqLw0KICNk ZWZpbmUJUkZISUdIUElECSgxPDwxOCkJLyogdXNlIGEgcGlkIGhpZ2hlciB0 aGFuIDEwIChpZGxlcHJvYykgKi8NCisjZGVmaW5lCVJGVFNJR1pNQgkoMTw8 MTkpCS8qIHNlbGVjdCBzaWduYWwgZm9yIGV4aXQgcGFyZW50IG5vdGlmaWNh dGlvbiAqLw0KKyNkZWZpbmUJUkZUU0lHU0hJRlQJMjAJLyogc2VsZWN0ZWQg c2lnbmFsIG51bWJlciBpcyBpbiBiaXRzIDIwLTI3ICAqLw0KKyNkZWZpbmUJ UkZUU0lHTUFTSwkweEZGDQorI2RlZmluZQlSRlRTSUdOVU0oZmxhZ3MpCSgo KGZsYWdzKSA+PiBSRlRTSUdTSElGVCkgJiBSRlRTSUdNQVNLKQ0KKyNkZWZp bmUJUkZUU0lHRkxBR1Moc2lnbnVtKQkoKHNpZ251bSkgPDwgUkZUU0lHU0hJ RlQpDQogI2RlZmluZQlSRlBQV0FJVAkoMTw8MzEpCS8qIHBhcmVudCBzbGVl cHMgdW50aWwgY2hpbGQgZXhpdHMgKHZmb3JrKSAqLw0KICNkZWZpbmUJUkZL RVJORUxPTkxZCShSRlNUT1BQRUQgfCBSRkhJR0hQSUQgfCBSRlBQV0FJVCkN CiANCg== --546530387-125356705-1310462188=:10573-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 11:19:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C6681065672 for ; Tue, 12 Jul 2011 11:19:30 +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 9DAD88FC1A for ; Tue, 12 Jul 2011 11:19:29 +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 p6CBJPis083834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2011 14:19:25 +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 p6CBJPLo093761; Tue, 12 Jul 2011 14:19:25 +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 p6CBJPjT093760; Tue, 12 Jul 2011 14:19:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Jul 2011 14:19:25 +0300 From: Kostik Belousov To: Kohji Okuno Message-ID: <20110712111925.GH43872@deviant.kiev.zoral.com.ua> References: <20110712.191028.650619413057975749.okuno.kohji@jp.panasonic.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TMJUm4hsTn/F+xXF" Content-Disposition: inline In-Reply-To: <20110712.191028.650619413057975749.okuno.kohji@jp.panasonic.com> 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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 Subject: Re: Bug about devfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 11:19:30 -0000 --TMJUm4hsTn/F+xXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote: > Hello, >=20 > I think that devfs has a problem. > I encountered the problem that open("/dev/AAA") returned ENOENT. > Of course, /dev/AAA exists. >=20 > ENOENT was created by the point(***) in devfs_allocv(). > I think that the race condition had occurred between process A and > vnlru kernel thread. >=20 > Please check the following. >=20 > If vnlru set VI_DOOMED to vp->v_iflag but vnlru didn't still execute > VOP_RECLAIM(), process A cat get valid vp from de->de_vnode. > But, vget() will return ENOENT, because vp->v_iflag has VI_DOOMED. >=20 > When I set the break point to (***), I checked that de->de_vnode and > vp->v_data were NULL. >=20 >=20 > process A: vnlru: >=20 > devfs_allocv() { > vgonel(vp) { > ... ... > vp->v_iflag |=3D VI_DOOMED; > mtx_lock(&devfs_de_interlock); ... > vp =3D de->de_vnode; =20 > if (vp !=3D NULL) { VI_UNLOCK(vp); > _____________/ ... > VI_LOCK(vp); ____________/ if (VOP_RECLAIM(vp, td)) > mtx_unlock(&devfs_de_interlock); ... > ... \ devfs_reclaim(ap) { > error =3D vget(vp,...); \ =20 > ... \______ mtx_lock(&devfs_de_interlock);=20 > if (devfs_allocv_drop_refs(...)) { de =3D vp->v_data; > ... if (de !=3D NULL) { > } de->de_vnode =3D NULL; =20 > else if (error) { vp->v_data =3D NULL; > ... } > rturn (error); (***) mtx_unlock(&devfs_de_interlock); > } ... > } >=20 >=20 >=20 > I think that devfs_allocv() should be fixed as below. > How do you think? >=20 > devfs_allocv(struct devfs_dirent *de, struct mount *mp, struct vnode **vp= p) > { > int error; > struct vnode *vp; > struct cdev *dev; > struct devfs_mount *dmp; > =20 > dmp =3D VFSTODEVFS(mp); > +#if 1 > + retry: > +#endif > if (de->de_flags & DE_DOOMED) { >=20 > ... >=20 > mtx_lock(&devfs_de_interlock); > vp =3D de->de_vnode; > if (vp !=3D NULL) { > VI_LOCK(vp); > mtx_unlock(&devfs_de_interlock); > sx_xunlock(&dmp->dm_lock); > error =3D vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, curthread= ); > sx_xlock(&dmp->dm_lock); > if (devfs_allocv_drop_refs(0, dmp, de)) { > if (error =3D=3D 0) > vput(vp); > return (ENOENT); > } > else if (error) { > +#if 1 > + if (error =3D=3D ENOENT) > + goto retry; > +#endif > sx_xunlock(&dmp->dm_lock); > return (error); > } >=20 Thank you for the report. The proposed change would revert r179247, which also caused some issues. Are you able to reproduce the problem ? Could you try the following patch ? I cannot reproduce your situation, so the patch is untested by me. diff --git a/sys/fs/devfs/devfs_vnops.c b/sys/fs/devfs/devfs_vnops.c index bf6dab8..bbbfff4 100644 --- a/sys/fs/devfs/devfs_vnops.c +++ b/sys/fs/devfs/devfs_vnops.c @@ -397,6 +397,7 @@ devfs_allocv(struct devfs_dirent *de, struct mount *mp,= int lockmode, sx_xunlock(&dmp->dm_lock); return (ENOENT); } +loop: DEVFS_DE_HOLD(de); DEVFS_DMP_HOLD(dmp); mtx_lock(&devfs_de_interlock); @@ -412,7 +413,16 @@ devfs_allocv(struct devfs_dirent *de, struct mount *mp= , int lockmode, vput(vp); return (ENOENT); } - else if (error) { + else if (error !=3D 0) { + if (error =3D=3D ENOENT) { + mtx_lock(&devfs_de_interlock); + while (de->de_vnode !=3D NULL) { + msleep(&de->de_vnode, + &devfs_de_interlock, 0, "dvall", 0); + } + mtx_unlock(&devfs_de_interlock); + goto loop; + } sx_xunlock(&dmp->dm_lock); return (error); } @@ -1259,6 +1269,7 @@ devfs_reclaim(struct vop_reclaim_args *ap) if (de !=3D NULL) { de->de_vnode =3D NULL; vp->v_data =3D NULL; + wakeup(&de->de_vnode); } mtx_unlock(&devfs_de_interlock); =20 --TMJUm4hsTn/F+xXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4cLb0ACgkQC3+MBN1Mb4h/mACeKHM9d6XArwTUhxSrFv8cK0tG lIAAnRXA7KmckLgCMGE8XG5jpQqwJHnM =X++1 -----END PGP SIGNATURE----- --TMJUm4hsTn/F+xXF-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 11:34:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFAA9106566C for ; Tue, 12 Jul 2011 11:34:27 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 6635F8FC08 for ; Tue, 12 Jul 2011 11:34:27 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id p6CBYPVI014498; Tue, 12 Jul 2011 20:34:25 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili16) with ESMTP id p6CBYQ330492; Tue, 12 Jul 2011 20:34:26 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi11) id p6CBYQBY019571; Tue, 12 Jul 2011 20:34:26 +0900 Received: from localhost by lomi11.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id p6CBYPXu019551; Tue, 12 Jul 2011 20:34:25 +0900 Date: Tue, 12 Jul 2011 20:34:25 +0900 (JST) Message-Id: <20110712.203425.702773873874569878.okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com From: Kohji Okuno In-Reply-To: <20110712111925.GH43872@deviant.kiev.zoral.com.ua> References: <20110712.191028.650619413057975749.okuno.kohji@jp.panasonic.com> <20110712111925.GH43872@deviant.kiev.zoral.com.ua> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com Subject: Re: Bug about devfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 11:34:27 -0000 Hello, From: Kostik Belousov Subject: Re: Bug about devfs? Date: Tue, 12 Jul 2011 14:19:25 +0300 Message-ID: <20110712111925.GH43872@deviant.kiev.zoral.com.ua> > Thank you for the report. > > The proposed change would revert r179247, which also caused some issues. > Are you able to reproduce the problem ? > > Could you try the following patch ? I cannot reproduce your situation, > so the patch is untested by me. Thank you for quick your comment. I think that your change is beter than mine. I will test it, and I will report the result. > On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote: >> Hello, >> >> I think that devfs has a problem. >> I encountered the problem that open("/dev/AAA") returned ENOENT. >> Of course, /dev/AAA exists. >> >> ENOENT was created by the point(***) in devfs_allocv(). >> I think that the race condition had occurred between process A and >> vnlru kernel thread. >> >> Please check the following. >> >> If vnlru set VI_DOOMED to vp->v_iflag but vnlru didn't still execute >> VOP_RECLAIM(), process A cat get valid vp from de->de_vnode. >> But, vget() will return ENOENT, because vp->v_iflag has VI_DOOMED. >> >> When I set the break point to (***), I checked that de->de_vnode and >> vp->v_data were NULL. >> >> >> process A: vnlru: >> >> devfs_allocv() { >> vgonel(vp) { >> ... ... >> vp->v_iflag |= VI_DOOMED; >> mtx_lock(&devfs_de_interlock); ... >> vp = de->de_vnode; >> if (vp != NULL) { VI_UNLOCK(vp); >> _____________/ ... >> VI_LOCK(vp); ____________/ if (VOP_RECLAIM(vp, td)) >> mtx_unlock(&devfs_de_interlock); ... >> ... \ devfs_reclaim(ap) { >> error = vget(vp,...); \ >> ... \______ mtx_lock(&devfs_de_interlock); >> if (devfs_allocv_drop_refs(...)) { de = vp->v_data; >> ... if (de != NULL) { >> } de->de_vnode = NULL; >> else if (error) { vp->v_data = NULL; >> ... } >> rturn (error); (***) mtx_unlock(&devfs_de_interlock); >> } ... >> } >> >> >> >> I think that devfs_allocv() should be fixed as below. >> How do you think? >> >> devfs_allocv(struct devfs_dirent *de, struct mount *mp, struct vnode **vpp) >> { >> int error; >> struct vnode *vp; >> struct cdev *dev; >> struct devfs_mount *dmp; >> >> dmp = VFSTODEVFS(mp); >> +#if 1 >> + retry: >> +#endif >> if (de->de_flags & DE_DOOMED) { >> >> ... >> >> mtx_lock(&devfs_de_interlock); >> vp = de->de_vnode; >> if (vp != NULL) { >> VI_LOCK(vp); >> mtx_unlock(&devfs_de_interlock); >> sx_xunlock(&dmp->dm_lock); >> error = vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, curthread); >> sx_xlock(&dmp->dm_lock); >> if (devfs_allocv_drop_refs(0, dmp, de)) { >> if (error == 0) >> vput(vp); >> return (ENOENT); >> } >> else if (error) { >> +#if 1 >> + if (error == ENOENT) >> + goto retry; >> +#endif >> sx_xunlock(&dmp->dm_lock); >> return (error); >> } >> > Thank you for the report. > > The proposed change would revert r179247, which also caused some issues. > Are you able to reproduce the problem ? > > Could you try the following patch ? I cannot reproduce your situation, > so the patch is untested by me. > > diff --git a/sys/fs/devfs/devfs_vnops.c b/sys/fs/devfs/devfs_vnops.c > index bf6dab8..bbbfff4 100644 > --- a/sys/fs/devfs/devfs_vnops.c > +++ b/sys/fs/devfs/devfs_vnops.c > @@ -397,6 +397,7 @@ devfs_allocv(struct devfs_dirent *de, struct mount *mp, int lockmode, > sx_xunlock(&dmp->dm_lock); > return (ENOENT); > } > +loop: > DEVFS_DE_HOLD(de); > DEVFS_DMP_HOLD(dmp); > mtx_lock(&devfs_de_interlock); > @@ -412,7 +413,16 @@ devfs_allocv(struct devfs_dirent *de, struct mount *mp, int lockmode, > vput(vp); > return (ENOENT); > } > - else if (error) { > + else if (error != 0) { > + if (error == ENOENT) { > + mtx_lock(&devfs_de_interlock); > + while (de->de_vnode != NULL) { > + msleep(&de->de_vnode, > + &devfs_de_interlock, 0, "dvall", 0); > + } > + mtx_unlock(&devfs_de_interlock); > + goto loop; > + } > sx_xunlock(&dmp->dm_lock); > return (error); > } > @@ -1259,6 +1269,7 @@ devfs_reclaim(struct vop_reclaim_args *ap) > if (de != NULL) { > de->de_vnode = NULL; > vp->v_data = NULL; > + wakeup(&de->de_vnode); > } > mtx_unlock(&devfs_de_interlock); > > > From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 13:02:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BCE9106564A for ; Tue, 12 Jul 2011 13:02:45 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CF0298FC19 for ; Tue, 12 Jul 2011 13:02:44 +0000 (UTC) Received: by gwb15 with SMTP id 15so2385748gwb.13 for ; Tue, 12 Jul 2011 06:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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 :content-transfer-encoding; bh=E6F/gwcl1AiX9FyQLNs3lbQC4kJyjtuSd0kPI/s9/Qc=; b=VAA2RK9yjilc69XIRFYPKjvby4+dQ9PiXU9Kamfj8ZAdAQD374zdFVHYhBIOWJpaRO 7aupisrXnUSt0BN6bamHkUefqU9ejGKlFnUL9pRD0YjnTimft+KhPFyZqSEi/YuVdJQL J8rTssJOfr/GLYfBp7taXr0bcNxfvCdPaIeI0= MIME-Version: 1.0 Received: by 10.236.180.38 with SMTP id i26mr7440099yhm.205.1310475764132; Tue, 12 Jul 2011 06:02:44 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.31.4 with HTTP; Tue, 12 Jul 2011 06:02:44 -0700 (PDT) In-Reply-To: <20110712111925.GH43872@deviant.kiev.zoral.com.ua> References: <20110712.191028.650619413057975749.okuno.kohji@jp.panasonic.com> <20110712111925.GH43872@deviant.kiev.zoral.com.ua> Date: Tue, 12 Jul 2011 15:02:44 +0200 X-Google-Sender-Auth: p2vOg4GYyocNYh8z7EJneKIEd84 Message-ID: From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Cc: freebsd-current@freebsd.org, Kohji Okuno , Ed Maste Subject: Re: Bug about devfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 13:02:45 -0000 MjAxMS83LzEyIEtvc3RpayBCZWxvdXNvdiA8a29zdGlrYmVsQGdtYWlsLmNvbT46Cj4gT24gVHVl LCBKdWwgMTIsIDIwMTEgYXQgMDc6MTA6MjhQTSArMDkwMCwgS29oamkgT2t1bm8gd3JvdGU6Cj4+ IEhlbGxvLAo+Pgo+PiBJIHRoaW5rIHRoYXQgZGV2ZnMgaGFzIGEgcHJvYmxlbS4KPj4gSSBlbmNv dW50ZXJlZCB0aGUgcHJvYmxlbSB0aGF0IG9wZW4oIi9kZXYvQUFBIikgcmV0dXJuZWQgRU5PRU5U Lgo+PiBPZiBjb3Vyc2UsIC9kZXYvQUFBIGV4aXN0cy4KPj4KPj4gRU5PRU5UIHdhcyBjcmVhdGVk IGJ5IHRoZSBwb2ludCgqKiopIGluIGRldmZzX2FsbG9jdigpLgo+PiBJIHRoaW5rIHRoYXQgdGhl IHJhY2UgY29uZGl0aW9uIGhhZCBvY2N1cnJlZCBiZXR3ZWVuIHByb2Nlc3MgQSBhbmQKPj4gdm5s cnUga2VybmVsIHRocmVhZC4KPj4KPj4gUGxlYXNlIGNoZWNrIHRoZSBmb2xsb3dpbmcuCj4+Cj4+ IElmIHZubHJ1IHNldCBWSV9ET09NRUQgdG8gdnAtPnZfaWZsYWcgYnV0IHZubHJ1IGRpZG4ndCBz dGlsbCBleGVjdXRlCj4+IFZPUF9SRUNMQUlNKCksIHByb2Nlc3MgQSBjYXQgZ2V0IHZhbGlkIHZw IGZyb20gZGUtPmRlX3Zub2RlLgo+PiBCdXQsIHZnZXQoKSB3aWxsIHJldHVybiBFTk9FTlQsIGJl Y2F1c2UgdnAtPnZfaWZsYWcgaGFzIFZJX0RPT01FRC4KPj4KPj4gV2hlbiBJIHNldCB0aGUgYnJl YWsgcG9pbnQgdG8gKCoqKiksIEkgY2hlY2tlZCB0aGF0IGRlLT5kZV92bm9kZSBhbmQKPj4gdnAt PnZfZGF0YSB3ZXJlIE5VTEwuCj4+Cj4+Cj4+IHByb2Nlc3MgQTogwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB2bmxydToKPj4KPj4gZGV2ZnNfYWxsb2N2KCkgewo+PiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB2 Z29uZWwodnApIHsKPj4gwqAgwqAuLi4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLi4uCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHZwLT52X2lmbGFnIHw9IFZJ X0RPT01FRDsKPj4gwqAgbXR4X2xvY2soJmRldmZzX2RlX2ludGVybG9jayk7IMKgIMKgIMKgIMKg IC4uLgo+PiDCoCB2cCA9IGRlLT5kZV92bm9kZTsKPj4gwqAgaWYgKHZwICE9IE5VTEwpIHsgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVklfVU5MT0NLKHZwKTsKPj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgX19fX19fX19fX19fXy8gLi4uCj4+IMKgIFZJX0xP Q0sodnApOyBfX19fX19fX19fX18vIMKgIMKgIMKgIMKgIMKgIMKgIMKgaWYgKFZPUF9SRUNMQUlN KHZwLCB0ZCkpCj4+IMKgIG10eF91bmxvY2soJmRldmZzX2RlX2ludGVybG9jayk7IMKgIMKgIMKg IC4uLgo+PiDCoCDCoC4uLiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoFwgwqAgwqAgwqAgwqAgZGV2ZnNfcmVjbGFpbShhcCkgewo+PiDCoCBlcnJvciA9IHZn ZXQodnAsLi4uKTsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBcCj4+IMKgIMKgLi4uIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgXF9fX19fXyDCoCBtdHhf bG9jaygmZGV2ZnNfZGVfaW50ZXJsb2NrKTsKPj4gwqAgaWYgKGRldmZzX2FsbG9jdl9kcm9wX3Jl ZnMoLi4uKSkgeyDCoCDCoCDCoCDCoGRlID0gdnAtPnZfZGF0YTsKPj4gwqAgwqAgLi4uIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGlmIChkZSAhPSBOVUxMKSB7Cj4+IMKgIH0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGUtPmRlX3Zub2RlID0gTlVMTDsKPj4gwqAg ZWxzZSBpZiAoZXJyb3IpIHsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdnAt PnZfZGF0YSA9IE5VTEw7Cj4+IMKgIMKgIC4uLiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB9Cj4+IMKgIMKgIHJ0dXJuIChlcnJv cik7ICgqKiopIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbXR4X3VubG9jaygmZGV2ZnNfZGVf aW50ZXJsb2NrKTsKPj4gwqAgfSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAuLi4KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfQo+Pgo+Pgo+Pgo+PiBJIHRoaW5rIHRo YXQgZGV2ZnNfYWxsb2N2KCkgc2hvdWxkIGJlIGZpeGVkIGFzIGJlbG93Lgo+PiBIb3cgZG8geW91 IHRoaW5rPwo+Pgo+PiBkZXZmc19hbGxvY3Yoc3RydWN0IGRldmZzX2RpcmVudCAqZGUsIHN0cnVj dCBtb3VudCAqbXAsIHN0cnVjdCB2bm9kZSAqKnZwcCkKPj4gewo+PiDCoCDCoCDCoCDCoCBpbnQg ZXJyb3I7Cj4+IMKgIMKgIMKgIHN0cnVjdCB2bm9kZSAqdnA7Cj4+IMKgIMKgIMKgIHN0cnVjdCBj ZGV2ICpkZXY7Cj4+IMKgIMKgIMKgIHN0cnVjdCBkZXZmc19tb3VudCAqZG1wOwo+Pgo+PiDCoCDC oCDCoCBkbXAgPSBWRlNUT0RFVkZTKG1wKTsKPj4gKyNpZiAxCj4+ICsgcmV0cnk6Cj4+ICsjZW5k aWYKPj4gwqAgwqAgwqAgwqAgaWYgKGRlLT5kZV9mbGFncyAmIERFX0RPT01FRCkgewo+Pgo+PiDC oCDCoCDCoCDCoCDCoCDCoC4uLgo+Pgo+PiDCoCDCoCDCoCDCoCBtdHhfbG9jaygmZGV2ZnNfZGVf aW50ZXJsb2NrKTsKPj4gwqAgwqAgwqAgwqAgdnAgPSBkZS0+ZGVfdm5vZGU7Cj4+IMKgIMKgIMKg IMKgIGlmICh2cCAhPSBOVUxMKSB7Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFZJX0xPQ0so dnApOwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtdHhfdW5sb2NrKCZkZXZmc19kZV9pbnRl cmxvY2spOwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzeF94dW5sb2NrKCZkbXAtPmRtX2xv Y2spOwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlcnJvciA9IHZnZXQodnAsIExLX0VYQ0xV U0lWRSB8IExLX0lOVEVSTE9DSywgY3VydGhyZWFkKTsKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgc3hfeGxvY2soJmRtcC0+ZG1fbG9jayk7Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlm IChkZXZmc19hbGxvY3ZfZHJvcF9yZWZzKDAsIGRtcCwgZGUpKSB7Cj4+IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChlcnJvciA9PSAwKQo+PiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB2cHV0KHZwKTsKPj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmV0dXJuIChFTk9FTlQpOwo+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB9Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGVsc2UgaWYgKGVycm9yKSB7 Cj4+ICsjaWYgMQo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChlcnJvciA9 PSBFTk9FTlQpCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Z290byByZXRyeTsKPj4gKyNlbmRpZgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBzeF94dW5sb2NrKCZkbXAtPmRtX2xvY2spOwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCByZXR1cm4gKGVycm9yKTsKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgfQo+Pgo+IFRo YW5rIHlvdSBmb3IgdGhlIHJlcG9ydC4KPgo+IFRoZSBwcm9wb3NlZCBjaGFuZ2Ugd291bGQgcmV2 ZXJ0IHIxNzkyNDcsIHdoaWNoIGFsc28gY2F1c2VkIHNvbWUgaXNzdWVzLgo+IEFyZSB5b3UgYWJs ZSB0byByZXByb2R1Y2UgdGhlIHByb2JsZW0gPwo+Cj4gQ291bGQgeW91IHRyeSB0aGUgZm9sbG93 aW5nIHBhdGNoID8gSSBjYW5ub3QgcmVwcm9kdWNlIHlvdXIgc2l0dWF0aW9uLAo+IHNvIHRoZSBw YXRjaCBpcyB1bnRlc3RlZCBieSBtZS4KPgo+IGRpZmYgLS1naXQgYS9zeXMvZnMvZGV2ZnMvZGV2 ZnNfdm5vcHMuYyBiL3N5cy9mcy9kZXZmcy9kZXZmc192bm9wcy5jCj4gaW5kZXggYmY2ZGFiOC4u YmJiZmZmNCAxMDA2NDQKPiAtLS0gYS9zeXMvZnMvZGV2ZnMvZGV2ZnNfdm5vcHMuYwo+ICsrKyBi L3N5cy9mcy9kZXZmcy9kZXZmc192bm9wcy5jCj4gQEAgLTM5Nyw2ICszOTcsNyBAQCBkZXZmc19h bGxvY3Yoc3RydWN0IGRldmZzX2RpcmVudCAqZGUsIHN0cnVjdCBtb3VudCAqbXAsIGludCBsb2Nr bW9kZSwKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHN4X3h1bmxvY2soJmRtcC0+ZG1fbG9jayk7 Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZXR1cm4gKEVOT0VOVCk7Cj4gwqAgwqAgwqAgwqB9 Cj4gK2xvb3A6Cj4gwqAgwqAgwqAgwqBERVZGU19ERV9IT0xEKGRlKTsKPiDCoCDCoCDCoCDCoERF VkZTX0RNUF9IT0xEKGRtcCk7Cj4gwqAgwqAgwqAgwqBtdHhfbG9jaygmZGV2ZnNfZGVfaW50ZXJs b2NrKTsKPiBAQCAtNDEyLDcgKzQxMywxNiBAQCBkZXZmc19hbGxvY3Yoc3RydWN0IGRldmZzX2Rp cmVudCAqZGUsIHN0cnVjdCBtb3VudCAqbXAsIGludCBsb2NrbW9kZSwKPiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHZwdXQodnApOwo+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmV0dXJuIChFTk9FTlQpOwo+IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgfQo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgZWxzZSBpZiAoZXJyb3IpIHsKPiAr IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGVsc2UgaWYgKGVycm9yICE9IDApIHsKPiArIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChlcnJvciA9PSBFTk9FTlQpIHsKPiArIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG10eF9sb2NrKCZkZXZmc19k ZV9pbnRlcmxvY2spOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgd2hpbGUgKGRlLT5kZV92bm9kZSAhPSBOVUxMKSB7Cj4gKyDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtc2xlZXAoJmRlLT5kZV92 bm9kZSwKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgICZkZXZmc19kZV9pbnRlcmxvY2ssIDAsICJkdmFsbCIsIDApOwo+ICsg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfQo+ICsgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbXR4X3VubG9jaygmZGV2ZnNf ZGVfaW50ZXJsb2NrKTsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGdvdG8gbG9vcDsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIH0K PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHN4X3h1bmxvY2soJmRtcC0+ZG1f bG9jayk7Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZXR1cm4gKGVycm9y KTsKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoH0KPiBAQCAtMTI1OSw2ICsxMjY5LDcgQEAgZGV2 ZnNfcmVjbGFpbShzdHJ1Y3Qgdm9wX3JlY2xhaW1fYXJncyAqYXApCj4gwqAgwqAgwqAgwqBpZiAo ZGUgIT0gTlVMTCkgewo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGUtPmRlX3Zub2RlID0gTlVM TDsKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHZwLT52X2RhdGEgPSBOVUxMOwo+ICsgwqAgwqAg wqAgwqAgwqAgwqAgwqAgd2FrZXVwKCZkZS0+ZGVfdm5vZGUpOwo+IMKgIMKgIMKgIMKgfQo+IMKg IMKgIMKgIMKgbXR4X3VubG9jaygmZGV2ZnNfZGVfaW50ZXJsb2NrKTsKCkkgdGhpbmsgdGhhdCB0 aGlzIGFwcHJvYWNoIG1heSBzdGFydmUgdGhlIHRocmVhZCBmb3IgYSB3aGlsZS4KQXMgSSB0b2xk IHlvdSBwcml2YXRlbHkgSSB3YXMgYWJsZSB0byBzZWUgb24gZmllbGQgYSBsaXZlbG9jayBiZWNh dXNlCm9mIHRoaXMgY2hlY2suIEluIG15IGNhc2UsIGl0IHdhcyBhIHRocmVhZCBydW5uaW5nIGZv ciA2M3NlY29uZHMgKGF0CmxlYXN0LCBhdCB0aGF0IHBvaW50IHRoZSB3YXRjaGRvZyB3YXMgdHJp cHBpbmcgb3ZlcikuCgpBdHRpbGlvCgoKLS0gClBlYWNlIGNhbiBvbmx5IGJlIGFjaGlldmVkIGJ5 IHVuZGVyc3RhbmRpbmcgLSBBLiBFaW5zdGVpbgo= From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 14:58:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EDDC1065672; Tue, 12 Jul 2011 14:58:02 +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 E19FB8FC08; Tue, 12 Jul 2011 14:58:01 +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 p6CEvsSE002328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2011 17:57:54 +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 p6CEvsJM001491; Tue, 12 Jul 2011 17:57:54 +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 p6CEvrDT001490; Tue, 12 Jul 2011 17:57:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Jul 2011 17:57:53 +0300 From: Kostik Belousov To: Attilio Rao Message-ID: <20110712145753.GI43872@deviant.kiev.zoral.com.ua> References: <20110712.191028.650619413057975749.okuno.kohji@jp.panasonic.com> <20110712111925.GH43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jAJnlX6Iz2QeVWJH" 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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, Kohji Okuno , Ed Maste Subject: Re: Bug about devfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 14:58:02 -0000 --jAJnlX6Iz2QeVWJH Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2011 at 03:02:44PM +0200, Attilio Rao wrote: > 2011/7/12 Kostik Belousov : > > On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote: > >> Hello, > >> > >> I think that devfs has a problem. > >> I encountered the problem that open("/dev/AAA") returned ENOENT. > >> Of course, /dev/AAA exists. > >> > >> ENOENT was created by the point(***) in devfs_allocv(). > >> I think that the race condition had occurred between process A and > >> vnlru kernel thread. > >> > >> Please check the following. > >> > >> If vnlru set VI_DOOMED to vp->v_iflag but vnlru didn't still execute > >> VOP_RECLAIM(), process A cat get valid vp from de->de_vnode. > >> But, vget() will return ENOENT, because vp->v_iflag has VI_DOOMED. > >> > >> When I set the break point to (***), I checked that de->de_vnode and > >> vp->v_data were NULL. > >> > >> > >> process A: =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Avnlr= u: > >> > >> devfs_allocv() { > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A =9A vgonel(vp) { > >> =9A =9A... =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A= =9A =9A =9A =9A =9A =9A ... > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A =9A =9A vp->v_iflag |=3D VI_DOOMED; > >> =9A mtx_lock(&devfs_de_interlock); =9A =9A =9A =9A ... > >> =9A vp =3D de->de_vnode; > >> =9A if (vp !=3D NULL) { =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A VI_UNL= OCK(vp); > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A _____________/ ... > >> =9A VI_LOCK(vp); ____________/ =9A =9A =9A =9A =9A =9A =9Aif (VOP_RECL= AIM(vp, td)) > >> =9A mtx_unlock(&devfs_de_interlock); =9A =9A =9A ... > >> =9A =9A... =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A= =9A\ =9A =9A =9A =9A devfs_reclaim(ap) { > >> =9A error =3D vget(vp,...); =9A =9A =9A =9A =9A =9A =9A =9A\ > >> =9A =9A... =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A= =9A =9A\______ =9A mtx_lock(&devfs_de_interlock); > >> =9A if (devfs_allocv_drop_refs(...)) { =9A =9A =9A =9Ade =3D vp->v_dat= a; > >> =9A =9A ... =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A =9A =9A =9A =9A =9A =9A if (de !=3D NULL) { > >> =9A } =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A =9A =9A =9A de->de_vnode =3D NULL; > >> =9A else if (error) { =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = vp->v_data =3D NULL; > >> =9A =9A ... =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A =9A =9A =9A =9A =9A =9A } > >> =9A =9A rturn (error); (***) =9A =9A =9A =9A =9A =9A =9A =9A =9Amtx_un= lock(&devfs_de_interlock); > >> =9A } =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A =9A =9A =9A ... > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A =9A =9A } > >> > >> > >> > >> I think that devfs_allocv() should be fixed as below. > >> How do you think? > >> > >> devfs_allocv(struct devfs_dirent *de, struct mount *mp, struct vnode *= *vpp) > >> { > >> =9A =9A =9A =9A int error; > >> =9A =9A =9A struct vnode *vp; > >> =9A =9A =9A struct cdev *dev; > >> =9A =9A =9A struct devfs_mount *dmp; > >> > >> =9A =9A =9A dmp =3D VFSTODEVFS(mp); > >> +#if 1 > >> + retry: > >> +#endif > >> =9A =9A =9A =9A if (de->de_flags & DE_DOOMED) { > >> > >> =9A =9A =9A =9A =9A =9A... > >> > >> =9A =9A =9A =9A mtx_lock(&devfs_de_interlock); > >> =9A =9A =9A =9A vp =3D de->de_vnode; > >> =9A =9A =9A =9A if (vp !=3D NULL) { > >> =9A =9A =9A =9A =9A =9A =9A =9A VI_LOCK(vp); > >> =9A =9A =9A =9A =9A =9A =9A =9A mtx_unlock(&devfs_de_interlock); > >> =9A =9A =9A =9A =9A =9A =9A =9A sx_xunlock(&dmp->dm_lock); > >> =9A =9A =9A =9A =9A =9A =9A =9A error =3D vget(vp, LK_EXCLUSIVE | LK_I= NTERLOCK, curthread); > >> =9A =9A =9A =9A =9A =9A =9A =9A sx_xlock(&dmp->dm_lock); > >> =9A =9A =9A =9A =9A =9A =9A =9A if (devfs_allocv_drop_refs(0, dmp, de)= ) { > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A if (error =3D=3D 0) > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A vput(v= p); > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A return (ENOENT); > >> =9A =9A =9A =9A =9A =9A =9A =9A } > >> =9A =9A =9A =9A =9A =9A =9A =9A else if (error) { > >> +#if 1 > >> + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A if (error =3D=3D ENOENT) > >> + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A goto retry; > >> +#endif > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A sx_xunlock(&dmp->dm_lock); > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A return (error); > >> =9A =9A =9A =9A =9A =9A =9A } > >> > > Thank you for the report. > > > > The proposed change would revert r179247, which also caused some issues. > > Are you able to reproduce the problem ? > > > > Could you try the following patch ? I cannot reproduce your situation, > > so the patch is untested by me. > > > > diff --git a/sys/fs/devfs/devfs_vnops.c b/sys/fs/devfs/devfs_vnops.c > > index bf6dab8..bbbfff4 100644 > > --- a/sys/fs/devfs/devfs_vnops.c > > +++ b/sys/fs/devfs/devfs_vnops.c > > @@ -397,6 +397,7 @@ devfs_allocv(struct devfs_dirent *de, struct mount = *mp, int lockmode, > > =9A =9A =9A =9A =9A =9A =9A =9Asx_xunlock(&dmp->dm_lock); > > =9A =9A =9A =9A =9A =9A =9A =9Areturn (ENOENT); > > =9A =9A =9A =9A} > > +loop: > > =9A =9A =9A =9ADEVFS_DE_HOLD(de); > > =9A =9A =9A =9ADEVFS_DMP_HOLD(dmp); > > =9A =9A =9A =9Amtx_lock(&devfs_de_interlock); > > @@ -412,7 +413,16 @@ devfs_allocv(struct devfs_dirent *de, struct mount= *mp, int lockmode, > > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Avput(vp); > > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Areturn (ENOENT); > > =9A =9A =9A =9A =9A =9A =9A =9A} > > - =9A =9A =9A =9A =9A =9A =9A else if (error) { > > + =9A =9A =9A =9A =9A =9A =9A else if (error !=3D 0) { > > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A if (error =3D=3D ENOENT) { > > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A mtx_lock(= &devfs_de_interlock); > > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A while (de= ->de_vnode !=3D NULL) { > > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A =9A msleep(&de->de_vnode, > > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A =9A =9A =9A &devfs_de_interlock, 0, "dvall", 0); > > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A } > > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A mtx_unloc= k(&devfs_de_interlock); > > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A goto loop; > > + =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A } > > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Asx_xunlock(&dmp->dm_lock= ); > > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Areturn (error); > > =9A =9A =9A =9A =9A =9A =9A =9A} > > @@ -1259,6 +1269,7 @@ devfs_reclaim(struct vop_reclaim_args *ap) > > =9A =9A =9A =9Aif (de !=3D NULL) { > > =9A =9A =9A =9A =9A =9A =9A =9Ade->de_vnode =3D NULL; > > =9A =9A =9A =9A =9A =9A =9A =9Avp->v_data =3D NULL; > > + =9A =9A =9A =9A =9A =9A =9A wakeup(&de->de_vnode); > > =9A =9A =9A =9A} > > =9A =9A =9A =9Amtx_unlock(&devfs_de_interlock); >=20 > I think that this approach may starve the thread for a while. > As I told you privately I was able to see on field a livelock because > of this check. In my case, it was a thread running for 63seconds (at > least, at that point the watchdog was tripping over). Feasible explanation was not found at the time, AFAIR. I could believe that this is possible with r179247 and driver stuck in the close cdevsw method. More risky change would be to clear de_vnode early. All devfs code shall be already safe by checking for VI_DOOMED, and if VI_DOOMED, v_data may be NULL. Again, I am unable to test. diff --git a/sys/fs/devfs/devfs_vnops.c b/sys/fs/devfs/devfs_vnops.c index bf6dab8..955bd8b 100644 --- a/sys/fs/devfs/devfs_vnops.c +++ b/sys/fs/devfs/devfs_vnops.c @@ -397,6 +397,7 @@ devfs_allocv(struct devfs_dirent *de, struct mount *mp,= int lockmode, sx_xunlock(&dmp->dm_lock); return (ENOENT); } +loop: DEVFS_DE_HOLD(de); DEVFS_DMP_HOLD(dmp); mtx_lock(&devfs_de_interlock); @@ -405,16 +406,21 @@ devfs_allocv(struct devfs_dirent *de, struct mount *m= p, int lockmode, VI_LOCK(vp); mtx_unlock(&devfs_de_interlock); sx_xunlock(&dmp->dm_lock); - error =3D vget(vp, lockmode | LK_INTERLOCK, curthread); + vget(vp, lockmode | LK_INTERLOCK | LK_RETRY, curthread); sx_xlock(&dmp->dm_lock); if (devfs_allocv_drop_refs(0, dmp, de)) { - if (error =3D=3D 0) - vput(vp); + vput(vp); return (ENOENT); } - else if (error) { - sx_xunlock(&dmp->dm_lock); - return (error); + else if ((vp->v_iflag & VI_DOOMED) !=3D 0) { + mtx_lock(&devfs_de_interlock); + if (de->de_vnode =3D=3D vp) { + de->de_vnode =3D NULL; + vp->v_data =3D NULL; + } + mtx_unlock(&devfs_de_interlock); + vput(vp); + goto loop; } sx_xunlock(&dmp->dm_lock); *vpp =3D vp; --jAJnlX6Iz2QeVWJH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4cYPEACgkQC3+MBN1Mb4iVVACgmxg/VHxHjPnHEPLFw85wHfwh DFYAoKCfJRca+DqGmkn3/kR3w9mik8Cm =7FWP -----END PGP SIGNATURE----- --jAJnlX6Iz2QeVWJH-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 14:27:38 2011 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 502881065674; Tue, 12 Jul 2011 14:27:38 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id C38008FC16; Tue, 12 Jul 2011 14:27:37 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6CERO1E066991; Tue, 12 Jul 2011 16:27:24 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Tue, 12 Jul 2011 16:36:24 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20110712103526.GF43872@deviant.kiev.zoral.com.ua> Message-ID: References: <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> <20110712103526.GF43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-FELK-MailScanner-Information: X-MailScanner-ID: p6CERO1E066991 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311085645.06565@zVRW0eVb5adjF12m3TDUow X-Spam-Status: No X-Mailman-Approved-At: Tue, 12 Jul 2011 15:30:58 +0000 Cc: freebsd-hackers@freebsd.org, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 14:27:38 -0000 > Below is the patch I intend to commit after you retest it. I applied it against our 8.2 based package, altered our "clone" to use this new interface and run eglibc testsuite. No regression. Our runtime detection of this new interface will be based on "sysctl kern.osreldate". > some rewording to the manual page. You might want to reword also RFLINUXTHPN part "kernel will return" -> "kernel will deliver" Can we expect MFC before 8.3 release ? Thanks Petr From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 17:50:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4FC9106566B; Tue, 12 Jul 2011 17:50:55 +0000 (UTC) (envelope-from lacombar@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 6D1B08FC0A; Tue, 12 Jul 2011 17:50:55 +0000 (UTC) Received: by pvg11 with SMTP id 11so5220148pvg.13 for ; Tue, 12 Jul 2011 10:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vve4wwbHkbOyYEs1PgWLWZBhSslRjnfIZyAxOWCVH2A=; b=qIT6OLixtAVB/Q2PhtGQNQ4QPUjcyiUUl8Tob+Vt3gLcgaTxZCCgNJDOLKyW8eOwwq vK6hxy4ekA5I2/Xg6GJFEjcKYzsvn/ntfB4TSuPd8svwEpO0Be0p2FPu1X3S/ZD5OtBm neKTbSJKWDw+KmH7dlrRCe2YYa0mq5Gca0jKk= MIME-Version: 1.0 Received: by 10.68.64.100 with SMTP id n4mr228244pbs.72.1310493054867; Tue, 12 Jul 2011 10:50:54 -0700 (PDT) Received: by 10.68.49.42 with HTTP; Tue, 12 Jul 2011 10:50:54 -0700 (PDT) In-Reply-To: References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <4E1B67C7.8040402@FreeBSD.org> Date: Tue, 12 Jul 2011 13:50:54 -0400 Message-ID: From: Arnaud Lacombe To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 17:50:55 -0000 Hi, On Mon, Jul 11, 2011 at 7:36 PM, wrote: > On Mon, Jul 11, 2011 at 4:00 PM, Ali Mashtizadeh wrote: >> Maybe someone can setup something like reviewboard [1] for developers >> to use. This may also help folks who want to keep abreast of the >> current work in a particular subsystem or get involved into the >> development process more. At my company we use reviews and it seems to >> help the catch some bugs and help new engineers ramp up faster. >> >> [1] http://www.reviewboard.org/ > > FreeBSD development is completely open; Sic... If you allow me the comparison, FreeBSD development is as open as are the US (and, to some extend, most western country) borders nowadays open to aliens, and believe me, this is not a compliment. - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 18:10:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 707B21065670 for ; Tue, 12 Jul 2011 18:10:35 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2BFBC8FC14 for ; Tue, 12 Jul 2011 18:10:34 +0000 (UTC) Received: by iyb11 with SMTP id 11so6285158iyb.13 for ; Tue, 12 Jul 2011 11:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=kHGRwFtbEFNWzJU/Re/4ROpzIKSZg156uBCrZhD4Pm0=; b=Zz4pramRBeWkIv5tyNg6BOl6b1qedn3RK4LuIsDsWPvteAZCMph3qEpl6cITt52S8j SbnTqgaCSDAb1nNPyyeb4/6r3NHgotiarbMWIobe1m6D+6iWhWinnivp9IrKaZsjjjnK OmSZ9rbD7KTu1CRSUwdSH+MQZSQ4+8tiwxfJA= Received: by 10.42.177.197 with SMTP id bj5mr177754icb.212.1310494234033; Tue, 12 Jul 2011 11:10:34 -0700 (PDT) Received: from sidhe.local ([75.111.38.94]) by mx.google.com with ESMTPS id a5sm1031885icb.3.2011.07.12.11.10.31 (version=SSLv3 cipher=OTHER); Tue, 12 Jul 2011 11:10:32 -0700 (PDT) Message-ID: <4E1C8E19.8010105@gmail.com> Date: Tue, 12 Jul 2011 11:10:33 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Arnaud Lacombe References: <4E1421D9.7080808@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <4E1B67C7.8040402@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mdf@freebsd.org, FreeBSD Current Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 18:10:35 -0000 > Sic... If you allow me the comparison, FreeBSD development is as open > as are the US (and, to some extend, most western country) borders > nowadays open to aliens, and believe me, this is not a compliment. > > - Arnaud > _______________________________________________ > 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" > This is getting offtopic fast. Can we just EGODWIN here? It doesn't fulfill the entire requirements, but it's getting close... Is it possible CPU is the wrong cause of the blocking? Is there perhaps memory contention between ZFS/UFS in OP's setup? Could filesystem/disk performance be the cause and not obscure technicalities of ULE scheduler? Dodgy hardware causing interrupt storms? Ethernet not in polling mode? Matt From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 18:44:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 944B0106566C for ; Tue, 12 Jul 2011 18:44:21 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 44FAA8FC18 for ; Tue, 12 Jul 2011 18:44:21 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QghwS-0007S5-2t>; Tue, 12 Jul 2011 20:44:20 +0200 Received: from e178028043.adsl.alicedsl.de ([85.178.28.43] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QghwR-0002dS-VV>; Tue, 12 Jul 2011 20:44:20 +0200 Message-ID: <4E1C9603.9070801@zedat.fu-berlin.de> Date: Tue, 12 Jul 2011 20:44:19 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110712 Thunderbird/5.0 MIME-Version: 1.0 To: Matt References: <4E1421D9.7080808@zedat.fu-berlin.de> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> <4E1B67C7.8040402@FreeBSD.org> <4E1C8E19.8010105@gmail.com> In-Reply-To: <4E1C8E19.8010105@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.28.43 Cc: mdf@freebsd.org, FreeBSD Current , Arnaud Lacombe Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 18:44:21 -0000 On 07/12/11 20:10, Matt wrote: > >> Sic... If you allow me the comparison, FreeBSD development is as open >> as are the US (and, to some extend, most western country) borders >> nowadays open to aliens, and believe me, this is not a compliment. >> >> - Arnaud >> I like the comment, although I disagree. In some cases, 'too open' is worse. Look at Linux. There are too open ditributions, and the rate of systemmalfunctions are relative high compared to *BSDs. This is my experience over the last few years, especially with RedHat ... > This is getting offtopic fast. Can we just EGODWIN here? It doesn't > fulfill the entire requirements, but it's getting close... > > Is it possible CPU is the wrong cause of the blocking? Is there > perhaps memory contention between ZFS/UFS in OP's setup? Could > filesystem/disk performance be the cause and not obscure > technicalities of ULE scheduler? Dodgy hardware causing interrupt > storms? Ethernet not in polling mode? > > Matt Doggy hardware: Dell PowerEdge 1950 with 16 GB RAM, two 4-core XEONs at 2.5 GHz, two Broadcom GBit NICs, SAS controller (mpt) and two SATA drives. Another box: Selfmade box based upon LGA775 with 8GB RAM, Realtek NIC with polling enabled (but do not know wheter it is used or not), Q6600 CPU, 5 SATA drives connected to ICH10R. Notebook: doggy hardware is Dell Latitude E6520. Another doggy hardware is our Dell Blade system with 24 GB RAM, two socket LGA1366 and two Westmere 6-core Intel XEONs (X56XXsomething). This box has as doggy hardware a SAS 2.0 controller with a 500 GB SAS 2.0 harddrive and a 2 TB SATA drive. The box is now running Linux due to the nVidia TESLA M2050 board, the doggy nVidia GPU card can not be used with the server OS FreeBSD. Especially on that machine, which runs headless, I experienced those 'locks' - when starting compiler, when running some n-body simulation code which is not parallelised, so I start an ensemble of 5 or six or 12 instances. I would like to qunatify the problems if someone would give me some advice how to measure. Within this thread I read about top isn't well designed doing that, so what is? Well, just for fun, I compiled 4BSD scheduler in the older 16-core XEON box's kernel and tried reproducing the problems. I wasn't able to do so in most cases, except when doing massively disk I/O AND network try to copy lots of data via network. It seems to bring down even a simple SSH. I'm confused ... From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 19:46:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31F46106567A; Tue, 12 Jul 2011 19:46:11 +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 070A78FC1A; Tue, 12 Jul 2011 19:46:11 +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 AAF5946B29; Tue, 12 Jul 2011 15:46:10 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 13D928A037; Tue, 12 Jul 2011 15:46:10 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Tue, 12 Jul 2011 10:22:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E100086.7080105@FreeBSD.org> <201107080919.58210.jhb@freebsd.org> <4E1BA36F.5060504@FreeBSD.org> In-Reply-To: <4E1BA36F.5060504@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107121022.16999.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 12 Jul 2011 15:46:10 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 19:46:11 -0000 On Monday, July 11, 2011 9:29:19 pm Doug Barton wrote: > On 07/08/2011 06:19, John Baldwin wrote: > > > Hmm, well that's odd. It didn't grow it enough it seems. > > > >>> Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert > >>> the card and record the messages in dmesg when it does? (You can likely get > >>> those out of kgdb.) > > I tried your patch, and got some odd results. The good news is, no > crash. However it did not actually enable the cards, with or without > if_ath being loaded before inserting them. Here is the dmesg output with > debug.bootverbose=1. This is with inserting and removing first one card, > then the other. Hmm, can you try without NEW_PCIB just as a test? (You'll need to add 'nooption NEW_PCIB' to your kernel config file.) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 20:17:01 2011 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 F21A41065670; Tue, 12 Jul 2011 20:17:01 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9C9288FC15; Tue, 12 Jul 2011 20:17:00 +0000 (UTC) Received: by yxl31 with SMTP id 31so1097992yxl.13 for ; Tue, 12 Jul 2011 13:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LU3ofp4TcZVnnCkdPk6KxuXkGTjCMcUqNOVni+L0SoQ=; b=iTDWnQplyTw05Qlp2JusmoiEEe2soGDU3gD043rXLbYFxK/JUqeq8DpC3JH4K7m/fO u8eUYRulIoLagTyuLP9v3DFm/vr7t/GeNpGggvJaOVgyQYvIaPXKWjQ+1pVERAbdtaIK IppT0s942sh4XS/KxDGsEXhPXtpkTwsaadAKA= MIME-Version: 1.0 Received: by 10.150.159.10 with SMTP id h10mr578699ybe.29.1310500235432; Tue, 12 Jul 2011 12:50:35 -0700 (PDT) Received: by 10.151.111.7 with HTTP; Tue, 12 Jul 2011 12:50:35 -0700 (PDT) Received: by 10.151.111.7 with HTTP; Tue, 12 Jul 2011 12:50:35 -0700 (PDT) In-Reply-To: References: <20110630162315.GV48734@deviant.kiev.zoral.com.ua> Date: Tue, 12 Jul 2011 12:50:35 -0700 Message-ID: From: Kevin Oberman To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: x11@freebsd.org, current@freebsd.org Subject: Re: Intel GPU kernel driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 20:17:02 -0000 On Jun 30, 2011 9:24 AM, "Kostik Belousov" wrote: > > [Please remove current@ when replying.] > > I created the first code drop for the ongoing GEM/KMS project. Please > note that this is not an end-user release, and even _not_ a call for > testing. The project is not finished yet, and I expect quite more > efforts from me even after the scheduled project end, and from ports/x11 > people, before the driver and usermode infrastructure will be ready for > the general public consumption. > > That said, the patch is only of use for you now if you want to review, > debug or otherwise help the project. The driver is known to be unstable, > some parts are missing, some (esp. VM changes) are under the discussion > and propably will be changed. > > If you have fix or useful bug analisys or suggestions for improvements, > you are welcome. I will not answer to the support requests for this > code now, please do not waste your time asking for it. > > The pointers to the patches, useful hints for debugging and bug > reporting, and some notes are at the http://wiki.freebsd.org/Intel_GPU. > I will maintain this page further. > > Current patch is ~50KLOC, it took quite an efforts to bring the code to > the state where there is something to debug. Thanks for everybody who > waited for it, and please be patient while the further work is done. One question I have is whether there is any chance of this working with a Sandy Bridge with the integrated Intel 3000 GPU? If so, it would give me incentive to move to current for the first time since 8 went stable. Sent from me cell phone while hurtling down the freeway at 80 MPH (125 KPH). Please excuse typos. And no, I'm not driving. R. Kevin Oberman, Network Engineer Retired kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 20:43:47 2011 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 59D541065672; Tue, 12 Jul 2011 20:43:47 +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 BC1AD8FC0A; Tue, 12 Jul 2011 20:43:46 +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 p6CKhb6B028884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2011 23:43:37 +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 p6CKhbAF014322; Tue, 12 Jul 2011 23:43:37 +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 p6CKhb4j014321; Tue, 12 Jul 2011 23:43:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Jul 2011 23:43:37 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110712204337.GJ43872@deviant.kiev.zoral.com.ua> References: <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> <20110712103526.GF43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZP5/UaesXwhUwRsu" 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 20:43:47 -0000 --ZP5/UaesXwhUwRsu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2011 at 04:36:24PM +0200, Petr Salinger wrote: > >Below is the patch I intend to commit after you retest it. >=20 > I applied it against our 8.2 based package, > altered our "clone" to use this new=20 > interface and run eglibc testsuite. No regression. >=20 > Our runtime detection of this new interface will be based > on "sysctl kern.osreldate". I will bump revision for stable/8 when merging, but I do not see much reason to bump on HEAD right now. >=20 >=20 > >some rewording to the manual page. >=20 > You might want to reword also RFLINUXTHPN part > "kernel will return" -> "kernel will deliver" >=20 > Can we expect MFC before 8.3 release ? I just committed this to HEAD. Will MFC in a week, unless some problems arise. --ZP5/UaesXwhUwRsu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4csfgACgkQC3+MBN1Mb4jj2wCfRxS9QKW9g+5lBx/tYqZKkXLU YJsAn0/H9x2olqhbuyRmi0Lk9sMpCmci =BLhR -----END PGP SIGNATURE----- --ZP5/UaesXwhUwRsu-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 21:21:37 2011 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 B70AC106566C; Tue, 12 Jul 2011 21:21:37 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F85E8FC17; Tue, 12 Jul 2011 21:21:37 +0000 (UTC) Received: by iyb11 with SMTP id 11so6462960iyb.13 for ; Tue, 12 Jul 2011 14:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=fdqc2hRlmcqUaXGPyjvOCvc1xbsAIMh57CEIWrUI5Ms=; b=QV5/ygVwdx37QYp6k8ONTLr8vszdZJV6pnF3qQbdFLxMblhrKGKFdq4AvYJus1lQK9 xLJYw5LSx1vs1ljE8BISJDmeD3K/amnyorUzX+ah/mYYS+rSDVmRN530zp1pXMMYdxlG B8Lz80nLKwP5Ptd9b8pCX4bY8tUMRboxG7d60= MIME-Version: 1.0 Received: by 10.42.147.65 with SMTP id m1mr360844icv.46.1310505696679; Tue, 12 Jul 2011 14:21:36 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.7 with HTTP; Tue, 12 Jul 2011 14:21:36 -0700 (PDT) In-Reply-To: <20110712204337.GJ43872@deviant.kiev.zoral.com.ua> References: <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> <20110712103526.GF43872@deviant.kiev.zoral.com.ua> <20110712204337.GJ43872@deviant.kiev.zoral.com.ua> Date: Tue, 12 Jul 2011 23:21:36 +0200 X-Google-Sender-Auth: TzrqMztSGscTL1Wu-_C6JGRnImw Message-ID: From: Robert Millan To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Tue, 12 Jul 2011 21:22:41 +0000 Cc: freebsd-hackers@freebsd.org, current@freebsd.org, Petr Salinger Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 21:21:37 -0000 2011/7/12 Kostik Belousov : > I just committed this to HEAD. Will MFC in a week, unless some problems > arise. Thanks! > I will bump revision for stable/8 when merging, but I do not see much > reason to bump on HEAD right now. Uhm I think we can survive without a bump in HEAD. For now we will need to keep our backward-compatibility patch anyway, and when the bump happens on stable/8 our sysctl comparison will identify 900039 as new ABI. Petr is that correct? -- Robert Millan From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 21:28:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 923851065670 for ; Tue, 12 Jul 2011 21:28:00 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2046F8FC12 for ; Tue, 12 Jul 2011 21:27:59 +0000 (UTC) Received: by fxe6 with SMTP id 6so4411566fxe.17 for ; Tue, 12 Jul 2011 14:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:user-agent:mime-version :content-type; bh=LgYIGfXW6+ciplWou1Qe11kVOLed6NKNm2yUPylVErA=; b=qnyfzw4Is5/viCufA6nqGL4/UySE+g0pPgwqm2TgHMnvAFeM/cKzDh00+FG0EQH7kp A5yOK4/c048Niul2WseRW5lCiEUOdMQZBrHIh3VKOpFFlzSWrlMkSKnTJVYX5qtB01oM wjqvI6F6ZWWwYmkt7izYbeA9mpWWpU5DQXD7Q= Received: by 10.223.17.68 with SMTP id r4mr534531faa.62.1310506078727; Tue, 12 Jul 2011 14:27:58 -0700 (PDT) Received: from localhost (c-66-31-196-160.hsd1.nh.comcast.net [66.31.196.160]) by mx.google.com with ESMTPS id h28sm10110632faj.29.2011.07.12.14.27.55 (version=SSLv3 cipher=OTHER); Tue, 12 Jul 2011 14:27:57 -0700 (PDT) From: Pan Tsu To: freebsd-current@freebsd.org Date: Wed, 13 Jul 2011 01:27:43 +0400 Message-ID: <8639ib1968.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Subject: pmcstat(8) and machdep.hlt_cpus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 21:28:00 -0000 pmcstat(8) stopped to work for me after largeSMP landed in r222813. At the time only pmccontrol(8) was updated. Then the next day machdep.hlt_cpus was ripped out. So, I've assumed it's going to be fixed by subsequent commits and commented out related code locally. $ qemu -smp 2 -nographic ... $ kldload hwpmc $ pmcstat -S instructions -T pmcstat: ERROR: Cannot determine which CPUs are halted: No such file or directory Exit 71 A month passed, nothing changed. Am I doing smth wrong? FWIW, smp(4) still documents machdep.hlt_cpus and machdep.hlt_logical_cpus. It should probably be updated with hint.lapic.X.disabled from UPDATING. From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 21:41:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B484F106564A; Tue, 12 Jul 2011 21:41:17 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9308FC1D; Tue, 12 Jul 2011 21:41:16 +0000 (UTC) Received: by fxe6 with SMTP id 6so4419696fxe.17 for ; Tue, 12 Jul 2011 14:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=jbJPJCnt3m6WYYSXjrun37geQaFp7EzImmLa48kbaJ0=; b=NACn/W5xFcYyia1eV/Kxcl18MHHIssdC5+XAYgAummiQZO+DlypT4Bi5M8yOs5KFjG LjGGIIa2RL+UxsZg5wXKw6iwfqgYw9T3Ah61W4plsGv/bY98Yi6qrV48TDOlk68Yhafu sEtHob1zkDZ5nCGXQGEm9wHHg4st8JqvX5WTM= Received: by 10.223.67.194 with SMTP id s2mr521369fai.124.1310506875833; Tue, 12 Jul 2011 14:41:15 -0700 (PDT) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id l9sm7006900fal.19.2011.07.12.14.41.13 (version=SSLv3 cipher=OTHER); Tue, 12 Jul 2011 14:41:14 -0700 (PDT) Date: Wed, 13 Jul 2011 00:40:49 +0300 From: Gleb Kurtsou To: mdf@FreeBSD.org Message-ID: <20110712214049.GA12290@tops> References: <20110707015151.GB71966@troutmask.apl.washington.edu> <4E1B67C7.8040402@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ali Mashtizadeh , FreeBSD Current , Arnaud Lacombe Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 21:41:17 -0000 On (11/07/2011 16:36), mdf@FreeBSD.org wrote: > On Mon, Jul 11, 2011 at 4:00 PM, Ali Mashtizadeh wrote: > > Maybe someone can setup something like reviewboard [1] for developers > > to use. This may also help folks who want to keep abreast of the > > current work in a particular subsystem or get involved into the > > development process more. At my company we use reviews and it seems to > > help the catch some bugs and help new engineers ramp up faster. > > > > [1] http://www.reviewboard.org/ > > FreeBSD development is completely open; anyone can sign up for the > svn-src-* mailing list they are interested in, including > svn-src-head@. Code reviews are plenty as well; just check the list > archives for discussion of bugs, poor design choices and unintended > effects. But most reviews are silent and after-the-fact by looking at > the list mail. It's a system that seems to be working just fine for > the FreeBSD project so far. This isn't a job for most anyone; it's a > volunteer project and so anything that raises the barrier to getting > work done for the project should be looked at with skepticism. I agree with everything said above and think that it's not reviews that's missing. By review I don't mean something like getting "ok to commit" reply from N developers before committing. svn-src@ works great for it, commits keep getting reverted :) Review is a time consuming process that also requires certain level of expertise. Volunteer project can hardly afford it. Having a project adopted way of sharing work in progress will be a step forward. Yes, I'm aware of perforce, it's to hard to use and wasn't designed to share and test ideas. I think guthub can be a very good candidate (but AFAIK it won't allow hosting of FreeBSD repo for not paid accounts). I'm not suggesting switching to git as VCS, but using github UI for communication and tracking not yet commited or work in progress changes. In ideal world developers will merge patches from each other increasing chance of a good code to survive and get commited later. Currently we have patches hosted at people.freebsd.org, as attachments on maillists and PRs -- almost all stale or outdated. Key difference of github is that original patch author will be aware of you using it, potentially updating and improving it. Others can continue supporting the patch if original author abandons it, etc. Sending patches is too complicated and counterproductive comparing to github. Thanks, Gleb. > > Is there a specific deficit that you want to address? > > Thanks, > matthew From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 21:49:17 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77A73106566C for ; Tue, 12 Jul 2011 21:49:17 +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 C7A6C8FC17 for ; Tue, 12 Jul 2011 21:49:16 +0000 (UTC) Received: from porto.starpoint.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 AAA21439; Wed, 13 Jul 2011 00:49:13 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QgkpN-0000Sx-LR; Wed, 13 Jul 2011 00:49:13 +0300 Message-ID: <4E1CC157.800@FreeBSD.org> Date: Wed, 13 Jul 2011 00:49:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Pan Tsu , freebsd-current@FreeBSD.org References: <8639ib1968.fsf@gmail.com> In-Reply-To: <8639ib1968.fsf@gmail.com> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: pmcstat(8) and machdep.hlt_cpus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 21:49:17 -0000 on 13/07/2011 00:27 Pan Tsu said the following: > pmcstat(8) stopped to work for me after largeSMP landed in r222813. > At the time only pmccontrol(8) was updated. Then the next day > machdep.hlt_cpus was ripped out. So, I've assumed it's going to > be fixed by subsequent commits and commented out related code locally. > > $ qemu -smp 2 -nographic ... > $ kldload hwpmc > $ pmcstat -S instructions -T > pmcstat: ERROR: Cannot determine which CPUs are halted: No such file or directory > Exit 71 > > A month passed, nothing changed. Am I doing smth wrong? Only one thing - waiting one month before reporting a regression... > FWIW, smp(4) still documents machdep.hlt_cpus and machdep.hlt_logical_cpus. > It should probably be updated with hint.lapic.X.disabled from UPDATING. Yes. Thank you for the reports. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 21:44:25 2011 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 9AAB61065673; Tue, 12 Jul 2011 21:44:25 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id 1850B8FC17; Tue, 12 Jul 2011 21:44:23 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.4/8.14.4) with ESMTP id p6CLi5W0093602; Tue, 12 Jul 2011 23:44:05 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Tue, 12 Jul 2011 23:53:05 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Robert Millan In-Reply-To: Message-ID: References: <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> <20110712103526.GF43872@deviant.kiev.zoral.com.ua> <20110712204337.GJ43872@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-FELK-MailScanner-Information: X-MailScanner-ID: p6CLi5W0093602 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.119, required 6, AWL 0.00, BAYES_00 -1.90, FREEMAIL_FROM 0.00, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: current@freebsd.org, freebsd-hackers@freebsd.org, kostikbel@gmail.com, rmh@debian.org X-FELK-MailScanner-Watermark: 1311111846.61093@TuNctzhbfAQ3xyu/Wv33mw X-Spam-Status: No X-Mailman-Approved-At: Tue, 12 Jul 2011 21:51:12 +0000 Cc: Kostik Belousov , freebsd-hackers@freebsd.org, current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 21:44:25 -0000 >> I will bump revision for stable/8 when merging, but I do not see much >> reason to bump on HEAD right now. Many thanks. > Uhm I think we can survive without a bump in HEAD. For now we will > need to keep our backward-compatibility patch anyway, and when the > bump happens on stable/8 our sysctl comparison will identify 900039 as > new ABI. We cannot survive without a bump in HEAD before 9.0 release, but we do not need bump immediately. So far the condition for new API will be if ( (osreldate >= 900040) || ((osreldate >= 803000) && (osreldate < 900000))) Of course, when MFC will bump revision, the 803000 constant will change (probably to 802509). Petr From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 21:57:11 2011 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 8F633106564A; Tue, 12 Jul 2011 21:57:11 +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 F264E8FC15; Tue, 12 Jul 2011 21:57:10 +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 p6CLurYX034236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jul 2011 00:56:53 +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 p6CLurmm016966; Wed, 13 Jul 2011 00:56:53 +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 p6CLurWx016965; Wed, 13 Jul 2011 00:56:53 +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: Wed, 13 Jul 2011 00:56:53 +0300 From: Kostik Belousov To: Petr Salinger Message-ID: <20110712215653.GL43872@deviant.kiev.zoral.com.ua> References: <20110711172408.GX43872@deviant.kiev.zoral.com.ua> <20110711180246.GA43872@deviant.kiev.zoral.com.ua> <20110712103526.GF43872@deviant.kiev.zoral.com.ua> <20110712204337.GJ43872@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t3wCcZxwnWQbJWrM" 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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, Robert Millan , current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2011 21:57:11 -0000 --t3wCcZxwnWQbJWrM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2011 at 11:53:05PM +0200, Petr Salinger wrote: > >>I will bump revision for stable/8 when merging, but I do not see much > >>reason to bump on HEAD right now. >=20 > Many thanks. >=20 > >Uhm I think we can survive without a bump in HEAD. For now we will > >need to keep our backward-compatibility patch anyway, and when the > >bump happens on stable/8 our sysctl comparison will identify 900039 as > >new ABI. >=20 > We cannot survive without a bump in HEAD before 9.0 release, > but we do not need bump immediately. Right, the point is that you can just say 'do not use 9.0-current earlier then r223966', and check only for >=3D 8025XX, where XX is the bump at MFC. >=20 > So far the condition for new API will be >=20 > if ( (osreldate >=3D 900040) > || ((osreldate >=3D 803000) && (osreldate < 900000))) >=20 > Of course, when MFC will bump revision, the 803000 constant > will change (probably to 802509). >=20 > Petr --t3wCcZxwnWQbJWrM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4cwyQACgkQC3+MBN1Mb4ijWwCg5tbkrkKTj6AWRwHoNUjA++Co TVoAoMEjk2Hk8pafGLB/aKKFJP6M0wM8 =bIEd -----END PGP SIGNATURE----- --t3wCcZxwnWQbJWrM-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 00:06:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B3A6106564A for ; Wed, 13 Jul 2011 00:06:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 123908FC08 for ; Wed, 13 Jul 2011 00:06:58 +0000 (UTC) Received: by iyb11 with SMTP id 11so6578201iyb.13 for ; Tue, 12 Jul 2011 17:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=/46SOcVme4/lLS5zlG8S/Sw70K5I/oxXjgI1VShA2lo=; b=SBg5NrcY7kVh9HQLFuWE3pKeB8Jme5aF2gLpBE+dd6HKh4gBnyL6/v88X5T15/P/kB 5Qzuow6xfEf3PDuc5LCkxsTIRYYnGVrtg5P0xzGTja873IpjgxpSGM5NzASfAILNmc9K XyAk2JBTo/UVnehb2qbzjurqdqKNNuHeaGTLA= Received: by 10.42.133.202 with SMTP id i10mr571431ict.110.1310515618363; Tue, 12 Jul 2011 17:06:58 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c2sm6190158ibd.5.2011.07.12.17.06.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jul 2011 17:06:57 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 12 Jul 2011 17:05:41 -0700 From: YongHyeon PYUN Date: Tue, 12 Jul 2011 17:05:41 -0700 To: Andrey Smagin Message-ID: <20110713000541.GC7564@michelle.cdnetworks.com> References: <20110630171914.GA12124@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20110630171914.GA12124@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: AX88772A AX88772B chipset differences? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@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: Wed, 13 Jul 2011 00:06:59 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jun 30, 2011 at 10:19:14AM -0700, YongHyeon PYUN wrote: > On Thu, Jun 30, 2011 at 02:44:48PM +0400, Andrey Smagin wrote: > > I have card based on AX88772B. I tried patch axe driver for vendor and device IDs. card detected, set up link, but no data received. What else need for patch in this driver ? Anybody have datasheet ? > > ASIX requires a login account to get the data sheet so it's not > publicly available to open source developers. > AFAIK the difference between AX88772A and AX88772B is IPv4/IPv6 > checksum offloading support of AX88772B. The introduction of > checksum offloading means they might have changed its RX header > format which in turn makes current RX handler to not work. The > other difference would be more advanced power saving used in > AX8877B but it wouldn't be much difference to axe(4) driver once > PHY is correctly woken in initialization phase. > Could you show me your diff and verbose boot output to know PHY > model and EEPROM data? I have a minimal patch for AX88772B. It requires more work to support TX/RX checksum offloading, flow-control and power saving but attached patch would be enough for most cases. Let me know whether it works or not. --2oS5YaxWCcQjTEyO Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="axe.88772B.diff" Index: sys/dev/usb/usbdevs =================================================================== --- sys/dev/usb/usbdevs (revision 223958) +++ sys/dev/usb/usbdevs (working copy) @@ -1045,6 +1045,7 @@ product ASIX AX88178 0x1780 AX88178 product ASIX AX88772 0x7720 AX88772 product ASIX AX88772A 0x772a AX88772A USB 2.0 10/100 Ethernet +product ASIX AX88772B 0x772b AX88772B USB 2.0 10/100 Ethernet /* ASUS products */ product ASUS2 USBN11 0x0b05 USB-N11 Index: sys/dev/usb/net/if_axereg.h =================================================================== --- sys/dev/usb/net/if_axereg.h (revision 223958) +++ sys/dev/usb/net/if_axereg.h (working copy) @@ -92,6 +92,8 @@ #define AXE_CMD_SW_PHY_STATUS 0x0021 #define AXE_CMD_SW_PHY_SELECT 0x0122 +#define AXE_772B_CMD_RXCTL_WRITE_CFG 0x012A + /* AX88772A and AX88772B only. */ #define AXE_CMD_READ_VLAN_CTRL 0x4027 #define AXE_CMD_WRITE_VLAN_CTRL 0x4028 @@ -132,12 +134,18 @@ #define AXE_178_RXCMD_KEEP_INVALID_CRC 0x0004 #define AXE_RXCMD_BROADCAST 0x0008 #define AXE_RXCMD_MULTICAST 0x0010 +#define AXE_RXCMD_ACCEPT_RUNT 0x0040 /* AX88772B */ #define AXE_RXCMD_ENABLE 0x0080 #define AXE_178_RXCMD_MFB_MASK 0x0300 #define AXE_178_RXCMD_MFB_2048 0x0000 #define AXE_178_RXCMD_MFB_4096 0x0100 #define AXE_178_RXCMD_MFB_8192 0x0200 #define AXE_178_RXCMD_MFB_16384 0x0300 +#define AXE_772B_RXCMD_HDR_TYPE_0 0x0000 +#define AXE_772B_RXCMD_HDR_TYPE_1 0x0100 +#define AXE_772B_RXCMD_IPHDR_ALIGN 0x0200 +#define AXE_772B_RXCMD_ADD_CHKSUM 0x0400 +#define AXE_RXCMD_LOOPBACK 0x1000 /* AX88772A/AX88772B */ #define AXE_PHY_SEL_PRI 1 #define AXE_PHY_SEL_SEC 0 @@ -176,7 +184,7 @@ #define AXE_PHY_MODE_REALTEK_8251CL 0x0E #define AXE_PHY_MODE_ATTANSIC 0x40 -/* AX88772A only. */ +/* AX88772A/AX88772B only. */ #define AXE_SW_PHY_SELECT_EXT 0x0000 #define AXE_SW_PHY_SELECT_EMBEDDED 0x0001 #define AXE_SW_PHY_SELECT_AUTO 0x0002 @@ -199,6 +207,24 @@ #define AXE_CONFIG_IDX 0 /* config number 1 */ #define AXE_IFACE_IDX 0 +/* EEPROM Map. */ +#define AXE_EEPROM_772B_NODE_ID 0x04 +#define AXE_EEPROM_772B_PHY_PWRCFG 0x18 + +struct ax88772b_mfb { + int byte_cnt; + int threshold; + int size; +}; +#define AX88772B_MFB_2K 0 +#define AX88772B_MFB_4K 1 +#define AX88772B_MFB_6K 2 +#define AX88772B_MFB_8K 3 +#define AX88772B_MFB_16K 4 +#define AX88772B_MFB_20K 5 +#define AX88772B_MFB_24K 6 +#define AX88772B_MFB_32K 7 + struct axe_sframe_hdr { uint16_t len; uint16_t ilen; @@ -228,6 +254,7 @@ uint8_t sc_ipgs[3]; uint8_t sc_phyaddrs[2]; + uint16_t sc_pwrcfg; int sc_tx_bufsz; }; Index: sys/dev/usb/net/if_axe.c =================================================================== --- sys/dev/usb/net/if_axe.c (revision 223958) +++ sys/dev/usb/net/if_axe.c (working copy) @@ -142,6 +142,7 @@ AXE_DEV(ASIX, AX88178, AXE_FLAG_178), AXE_DEV(ASIX, AX88772, AXE_FLAG_772), AXE_DEV(ASIX, AX88772A, AXE_FLAG_772A), + AXE_DEV(ASIX, AX88772B, AXE_FLAG_772B), AXE_DEV(ATEN, UC210T, 0), AXE_DEV(BELKIN, F5D5055, AXE_FLAG_178), AXE_DEV(BILLIONTON, USB2AR, 0), @@ -190,7 +191,9 @@ static int axe_cmd(struct axe_softc *, int, int, int, void *); static void axe_ax88178_init(struct axe_softc *); static void axe_ax88772_init(struct axe_softc *); +static void axe_ax88772_phywake(struct axe_softc *); static void axe_ax88772a_init(struct axe_softc *); +static void axe_ax88772b_init(struct axe_softc *); static int axe_get_phyno(struct axe_softc *, int); static const struct usb_config axe_config[AXE_N_TRANSFER] = { @@ -217,6 +220,17 @@ }, }; +static const struct ax88772b_mfb ax88772b_mfb_table[] = { + { 0x8000, 0x8001, 2048 }, + { 0x8100, 0x8147, 4096}, + { 0x8200, 0x81EB, 6144}, + { 0x8300, 0x83D7, 8192}, + { 0x8400, 0x851E, 16384}, + { 0x8500, 0x8666, 20480}, + { 0x8600, 0x87AE, 24576}, + { 0x8700, 0x8A3D, 32768} +}; + static device_method_t axe_methods[] = { /* Device interface */ DEVMETHOD(device_probe, axe_probe), @@ -669,16 +683,11 @@ } static void -axe_ax88772a_init(struct axe_softc *sc) +axe_ax88772_phywake(struct axe_softc *sc) { struct usb_ether *ue; - uint16_t eeprom; ue = &sc->sc_ue; - axe_cmd(sc, AXE_CMD_SROM_READ, 0, 0x0017, &eeprom); - eeprom = le16toh(eeprom); - /* Reload EEPROM. */ - AXE_GPIO_WRITE(AXE_GPIO_RELOAD_EEPROM, hz / 32); if (sc->sc_phyno == AXE_772_PHY_NO_EPHY) { /* Manually select internal(embedded) PHY - MAC mode. */ axe_cmd(sc, AXE_CMD_SW_PHY_SELECT, 0, AXE_SW_PHY_SELECT_SS_ENB | @@ -704,9 +713,58 @@ uether_pause(&sc->sc_ue, hz / 32); axe_cmd(sc, AXE_CMD_SW_RESET_REG, 0, AXE_SW_RESET_IPRL, NULL); uether_pause(&sc->sc_ue, hz / 32); +} + +static void +axe_ax88772a_init(struct axe_softc *sc) +{ + struct usb_ether *ue; + + ue = &sc->sc_ue; + /* Reload EEPROM. */ + AXE_GPIO_WRITE(AXE_GPIO_RELOAD_EEPROM, hz / 32); + axe_ax88772_phywake(sc); + /* Stop MAC. */ axe_cmd(sc, AXE_CMD_RXCTL_WRITE, 0, 0, NULL); } +static void +axe_ax88772b_init(struct axe_softc *sc) +{ + struct usb_ether *ue; + uint16_t eeprom; + uint8_t *eaddr; + int i; + + ue = &sc->sc_ue; + /* Reload EEPROM. */ + AXE_GPIO_WRITE(AXE_GPIO_RELOAD_EEPROM, hz / 32); + /* + * Save PHY power saving configuration(high byte) and + * clear EEPROM checksum value(low byte). + */ + axe_cmd(sc, AXE_CMD_SROM_READ, 0, AXE_EEPROM_772B_PHY_PWRCFG, &eeprom); + sc->sc_pwrcfg = le16toh(eeprom) & 0xFF00; + + /* + * Auto-loaded default station address from internal ROM is + * 00:00:00:00:00 such that an explicit access to EEPROM is + * required to get real station address. + */ + eaddr = ue->ue_eaddr; + for (i = 0; i < ETHER_ADDR_LEN / 2; i++) { + axe_cmd(sc, AXE_CMD_SROM_READ, 0, AXE_EEPROM_772B_NODE_ID + i, + &eeprom); + eeprom = le16toh(eeprom); + *eaddr++ = (uint8_t)(eeprom & 0xFF); + *eaddr++ = (uint8_t)((eeprom >> 8) & 0xFF); + } + /* Wakeup PHY. */ + axe_ax88772_phywake(sc); + /* Stop MAC. */ + axe_cmd(sc, AXE_CMD_RXCTL_WRITE, 0, 0, NULL); +} + #undef AXE_GPIO_WRITE static void @@ -732,6 +790,8 @@ axe_ax88772_init(sc); else if (sc->sc_flags & AXE_FLAG_772A) axe_ax88772a_init(sc); + else if (sc->sc_flags & AXE_FLAG_772B) + axe_ax88772b_init(sc); } static void @@ -755,29 +815,29 @@ sc->sc_phyno = 0; } + /* Initialize controller and get station address. */ if (sc->sc_flags & AXE_FLAG_178) { axe_ax88178_init(sc); sc->sc_tx_bufsz = 16 * 1024; + axe_cmd(sc, AXE_178_CMD_READ_NODEID, 0, 0, ue->ue_eaddr); } else if (sc->sc_flags & AXE_FLAG_772) { axe_ax88772_init(sc); sc->sc_tx_bufsz = 8 * 1024; + axe_cmd(sc, AXE_178_CMD_READ_NODEID, 0, 0, ue->ue_eaddr); } else if (sc->sc_flags & AXE_FLAG_772A) { axe_ax88772a_init(sc); sc->sc_tx_bufsz = 8 * 1024; - } - - /* - * Get station address. - */ - if (AXE_IS_178_FAMILY(sc)) axe_cmd(sc, AXE_178_CMD_READ_NODEID, 0, 0, ue->ue_eaddr); - else + } else if (sc->sc_flags & AXE_FLAG_772B) { + axe_ax88772b_init(sc); + sc->sc_tx_bufsz = 8 * 1024; + } else axe_cmd(sc, AXE_172_CMD_READ_NODEID, 0, 0, ue->ue_eaddr); /* * Fetch IPG values. */ - if (sc->sc_flags & AXE_FLAG_772A) { + if (sc->sc_flags & (AXE_FLAG_772A | AXE_FLAG_772B)) { /* Set IPG values. */ sc->sc_ipgs[0] = 0x15; sc->sc_ipgs[1] = 0x16; @@ -1104,18 +1164,30 @@ axe_cmd(sc, AXE_172_CMD_WRITE_IPG2, 0, sc->sc_ipgs[2], NULL); } - /* Enable receiver, set RX mode */ + /* AX88772B uses different maximum frame burst configuration. */ + if (sc->sc_flags & AXE_FLAG_772B) + axe_cmd(sc, AXE_772B_CMD_RXCTL_WRITE_CFG, + ax88772b_mfb_table[AX88772B_MFB_16K].threshold, + ax88772b_mfb_table[AX88772B_MFB_16K].byte_cnt, NULL); + + /* Enable receiver, set RX mode. */ rxmode = (AXE_RXCMD_MULTICAST | AXE_RXCMD_ENABLE); if (AXE_IS_178_FAMILY(sc)) { -#if 0 - rxmode |= AXE_178_RXCMD_MFB_2048; /* chip default */ -#else - /* - * Default Rx buffer size is too small to get - * maximum performance. - */ - rxmode |= AXE_178_RXCMD_MFB_16384; -#endif + if (sc->sc_flags & AXE_FLAG_772B) { + /* + * Select RX header format type 1. Aligning IP + * header on 4 byte boundary is not needed + * because we always copy the received frame in + * RX handler. + */ + rxmode |= AXE_772B_RXCMD_HDR_TYPE_1; + } else { + /* + * Default Rx buffer size is too small to get + * maximum performance. + */ + rxmode |= AXE_178_RXCMD_MFB_16384; + } } else { rxmode |= AXE_172_RXCMD_UNICAST; } --2oS5YaxWCcQjTEyO-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 00:18:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 497581065675; Wed, 13 Jul 2011 00:18:24 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A56F1161BA1; Wed, 13 Jul 2011 00:18:22 +0000 (UTC) Message-ID: <4E1CE44E.4090904@FreeBSD.org> Date: Tue, 12 Jul 2011 17:18:22 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin References: <4E100086.7080105@FreeBSD.org> <201107080919.58210.jhb@freebsd.org> <4E1BA36F.5060504@FreeBSD.org> <201107121022.16999.jhb@freebsd.org> In-Reply-To: <201107121022.16999.jhb@freebsd.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2011 00:18:24 -0000 On 07/12/2011 07:22, John Baldwin wrote: > On Monday, July 11, 2011 9:29:19 pm Doug Barton wrote: >> On 07/08/2011 06:19, John Baldwin wrote: >> >>> Hmm, well that's odd. It didn't grow it enough it seems. >>> >>>>> Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert >>>>> the card and record the messages in dmesg when it does? (You can likely get >>>>> those out of kgdb.) >> >> I tried your patch, and got some odd results. The good news is, no >> crash. However it did not actually enable the cards, with or without >> if_ath being loaded before inserting them. Here is the dmesg output with >> debug.bootverbose=1. This is with inserting and removing first one card, >> then the other. > > Hmm, can you try without NEW_PCIB just as a test? (You'll need to add > 'nooption NEW_PCIB' to your kernel config file.) Yes, but not any sooner than this evening. I see you committed the patch you sent me, so I'll update my srcs to the latest HEAD, add the option you suggested, and rebuild ASAP. Thanks again, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 04:15:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2DE4106564A for ; Wed, 13 Jul 2011 04:15:20 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 700BA8FC13 for ; Wed, 13 Jul 2011 04:15:20 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id p6D4FIQn003541; Wed, 13 Jul 2011 13:15:18 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili16) with ESMTP id p6D4FI303261; Wed, 13 Jul 2011 13:15:18 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi17) id p6D4FI64010989; Wed, 13 Jul 2011 13:15:18 +0900 Received: from localhost by lomi17.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id p6D4FIlR010975; Wed, 13 Jul 2011 13:15:18 +0900 Date: Wed, 13 Jul 2011 13:15:14 +0900 (JST) Message-Id: <20110713.131514.2295692683054433320.okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com From: Kohji Okuno In-Reply-To: <20110712145753.GI43872@deviant.kiev.zoral.com.ua> References: <20110712111925.GH43872@deviant.kiev.zoral.com.ua> <20110712145753.GI43872@deviant.kiev.zoral.com.ua> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: attilio@freebsd.org, freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com, emaste@sandvine.com Subject: Re: Bug about devfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2011 04:15:20 -0000 Hello, From: Kostik Belousov Date: Tue, 12 Jul 2011 17:57:53 +0300 > On Tue, Jul 12, 2011 at 03:02:44PM +0200, Attilio Rao wrote: >> 2011/7/12 Kostik Belousov : >> > On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote: >> >> Hello, >> >> >> >> I think that devfs has a problem. >> >> I encountered the problem that open("/dev/AAA") returned ENOENT. >> >> Of course, /dev/AAA exists. >> >> >> >> ENOENT was created by the point(***) in devfs_allocv(). >> >> I think that the race condition had occurred between process A an= d >> >> vnlru kernel thread. >> >> >> >> Please check the following. >> >> >> >> If vnlru set VI_DOOMED to vp->v_iflag but vnlru didn't still exec= ute >> >> VOP_RECLAIM(), process A cat get valid vp from de->de_vnode. >> >> But, vget() will return ENOENT, because vp->v_iflag has VI_DOOMED= .= >> >> >> >> When I set the break point to (***), I checked that de->de_vnode = and >> >> vp->v_data were NULL. >> >> >> >> >> >> process A: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= vnlru: >> >> >> >> devfs_allocv() { >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 vgonel(vp) { >> >> =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 ... >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 vp->v_iflag |=3D VI_DOOMED; >> >> =A0 mtx_lock(&devfs_de_interlock); =A0 =A0 =A0 =A0 ... >> >> =A0 vp =3D de->de_vnode; >> >> =A0 if (vp !=3D NULL) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 V= I_UNLOCK(vp); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _____________= / ... >> >> =A0 VI_LOCK(vp); ____________/ =A0 =A0 =A0 =A0 =A0 =A0 =A0if (VOP= _RECLAIM(vp, td)) >> >> =A0 mtx_unlock(&devfs_de_interlock); =A0 =A0 =A0 ... >> >> =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0\ =A0 =A0 =A0 =A0 devfs_reclaim(ap) { >> >> =A0 error =3D vget(vp,...); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ >> >> =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0\______ =A0 mtx_lock(&devfs_de_interlock); >> >> =A0 if (devfs_allocv_drop_refs(...)) { =A0 =A0 =A0 =A0de =3D vp->= v_data; >> >> =A0 =A0 ... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (de !=3D NULL) { >> >> =A0 } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 de->de_vnode =3D NULL; >> >> =A0 else if (error) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 vp->v_data =3D NULL; >> >> =A0 =A0 ... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> >> =A0 =A0 rturn (error); (***) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m= tx_unlock(&devfs_de_interlock); >> >> =A0 } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 ... >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 } >> >> >> >> >> >> >> >> I think that devfs_allocv() should be fixed as below. >> >> How do you think? >> >> >> >> devfs_allocv(struct devfs_dirent *de, struct mount *mp, struct vn= ode **vpp) >> >> { >> >> =A0 =A0 =A0 =A0 int error; >> >> =A0 =A0 =A0 struct vnode *vp; >> >> =A0 =A0 =A0 struct cdev *dev; >> >> =A0 =A0 =A0 struct devfs_mount *dmp; >> >> >> >> =A0 =A0 =A0 dmp =3D VFSTODEVFS(mp); >> >> +#if 1 >> >> + retry: >> >> +#endif >> >> =A0 =A0 =A0 =A0 if (de->de_flags & DE_DOOMED) { >> >> >> >> =A0 =A0 =A0 =A0 =A0 =A0... >> >> >> >> =A0 =A0 =A0 =A0 mtx_lock(&devfs_de_interlock); >> >> =A0 =A0 =A0 =A0 vp =3D de->de_vnode; >> >> =A0 =A0 =A0 =A0 if (vp !=3D NULL) { >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 VI_LOCK(vp); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtx_unlock(&devfs_de_interlock); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sx_xunlock(&dmp->dm_lock); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D vget(vp, LK_EXCLUSIVE |= LK_INTERLOCK, curthread); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sx_xlock(&dmp->dm_lock); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (devfs_allocv_drop_refs(0, dmp= , de)) { >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error =3D=3D = 0) >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 v= put(vp); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (ENOENT); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else if (error) { >> >> +#if 1 >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error =3D=3D ENOENT= ) >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto re= try; >> >> +#endif >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sx_xunlock(&dmp->dm_l= ock); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (error); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> >> >> > Thank you for the report. >> > >> > The proposed change would revert r179247, which also caused some i= ssues. >> > Are you able to reproduce the problem ? >> > >> > Could you try the following patch ? I cannot reproduce your situat= ion, >> > so the patch is untested by me. >> > >> > diff --git a/sys/fs/devfs/devfs_vnops.c b/sys/fs/devfs/devfs_vnops= .c >> > index bf6dab8..bbbfff4 100644 >> > --- a/sys/fs/devfs/devfs_vnops.c >> > +++ b/sys/fs/devfs/devfs_vnops.c >> > @@ -397,6 +397,7 @@ devfs_allocv(struct devfs_dirent *de, struct m= ount *mp, int lockmode, >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sx_xunlock(&dmp->dm_lock); >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (ENOENT); >> > =A0 =A0 =A0 =A0} >> > +loop: >> > =A0 =A0 =A0 =A0DEVFS_DE_HOLD(de); >> > =A0 =A0 =A0 =A0DEVFS_DMP_HOLD(dmp); >> > =A0 =A0 =A0 =A0mtx_lock(&devfs_de_interlock); >> > @@ -412,7 +413,16 @@ devfs_allocv(struct devfs_dirent *de, struct = mount *mp, int lockmode, >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vpu= t(vp); >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (ENOENT); >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 else if (error) { >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else if (error !=3D 0) { >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error =3D=3D ENO= ENT) { >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtx_= lock(&devfs_de_interlock); >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 whil= e (de->de_vnode !=3D NULL) { >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 msleep(&de->de_vnode, >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 &devfs_de_interlock, 0, "dvall", 0); >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtx_= unlock(&devfs_de_interlock); >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto= loop; >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sx_xunlock(&dmp->dm= _lock); >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (error); >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> > @@ -1259,6 +1269,7 @@ devfs_reclaim(struct vop_reclaim_args *ap) >> > =A0 =A0 =A0 =A0if (de !=3D NULL) { >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0de->de_vnode =3D NULL; >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vp->v_data =3D NULL; >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 wakeup(&de->de_vnode); >> > =A0 =A0 =A0 =A0} >> > =A0 =A0 =A0 =A0mtx_unlock(&devfs_de_interlock); >> = >> I think that this approach may starve the thread for a while. >> As I told you privately I was able to see on field a livelock becaus= e >> of this check. In my case, it was a thread running for 63seconds (at= >> least, at that point the watchdog was tripping over). > Feasible explanation was not found at the time, AFAIR. I could believ= e > that this is possible with r179247 and driver stuck in the close cdev= sw > method. > = > More risky change would be to clear de_vnode early. All devfs code sh= all > be already safe by checking for VI_DOOMED, and if VI_DOOMED, v_data m= ay > be NULL. > = > Again, I am unable to test. > = > diff --git a/sys/fs/devfs/devfs_vnops.c b/sys/fs/devfs/devfs_vnops.c > index bf6dab8..955bd8b 100644 > --- a/sys/fs/devfs/devfs_vnops.c > +++ b/sys/fs/devfs/devfs_vnops.c > @@ -397,6 +397,7 @@ devfs_allocv(struct devfs_dirent *de, struct moun= t *mp, int lockmode, > sx_xunlock(&dmp->dm_lock); > return (ENOENT); > } > +loop: > DEVFS_DE_HOLD(de); > DEVFS_DMP_HOLD(dmp); > mtx_lock(&devfs_de_interlock); > @@ -405,16 +406,21 @@ devfs_allocv(struct devfs_dirent *de, struct mo= unt *mp, int lockmode, > VI_LOCK(vp); > mtx_unlock(&devfs_de_interlock); > sx_xunlock(&dmp->dm_lock); > - error =3D vget(vp, lockmode | LK_INTERLOCK, curthread); > + vget(vp, lockmode | LK_INTERLOCK | LK_RETRY, curthread); > sx_xlock(&dmp->dm_lock); > if (devfs_allocv_drop_refs(0, dmp, de)) { > - if (error =3D=3D 0) > - vput(vp); > + vput(vp); > return (ENOENT); > } > - else if (error) { > - sx_xunlock(&dmp->dm_lock); > - return (error); > + else if ((vp->v_iflag & VI_DOOMED) !=3D 0) { > + mtx_lock(&devfs_de_interlock); > + if (de->de_vnode =3D=3D vp) { > + de->de_vnode =3D NULL; > + vp->v_data =3D NULL; > + } > + mtx_unlock(&devfs_de_interlock); > + vput(vp); > + goto loop; > } > sx_xunlock(&dmp->dm_lock); > *vpp =3D vp; I tried Kostik's last patch, and I checked that open() successed twice by retry. It is difficult for me to reproduce this situation. At least, my problem is solved by this patch. Thanks, Kohji Okuno. From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 06:32:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C258106564A for ; Wed, 13 Jul 2011 06:32:53 +0000 (UTC) (envelope-from freebsd@berczi.be) Received: from macsec.hu (cl-23.bud-01.hu.sixxs.net [IPv6:2a01:368:e000:16::2]) by mx1.freebsd.org (Postfix) with ESMTP id 001888FC12 for ; Wed, 13 Jul 2011 06:32:52 +0000 (UTC) Received: from [10.11.0.1] by macsec.hu with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1Qgt07-000C9K-92 for freebsd-current@freebsd.org; Wed, 13 Jul 2011 08:32:51 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Berczi Gabor In-Reply-To: <4E1B0C72.7030109@icritical.com> Date: Wed, 13 Jul 2011 08:32:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12DA9EAC-8677-49AD-BA6C-5A155D2A6122@berczi.be> <4E1B0C72.7030109@icritical.com> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1084) Subject: Re: ZFS boot fails with two pools X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2011 06:32:53 -0000 Thanks for the explanation! The patch didn't fix it though (as it probably only works against log = partitions). On Jul 11, 2011, at 4:45 PM, Matt Burke wrote: > On 07/06/11 16:44, Berczi Gabor wrote: >> For some reason FreeBSD can't boot automatically: > ... >> I have two pools, pool2 which is a mirrored zpool, and data being a >> raid-z pool. Note how the default should be "pool2:/boot/zfsloader". = How >> can I fix this? >=20 > The following applies to 8-STABLE from 2011-06-29. I believe -CURRENT = may > be identical, but don't know for certain. >=20 >=20 >> =46rom what I could tell from researching my similar problem (*), you = can > ignore the zpool bootfs property as well as the gpt bootme flag - = they're > not looked at by the boot process, at least not before the stage 3 = loader. >=20 > What happens is gptzfsboot simply tries to boot from the first zfs = pool it > finds. The only control you have is that the first drive it scans is = the > one it boots from. >=20 > If the BIOS booted from the disk with the raid-z pool, or if there is > something like a log partition for your raid-z pool before your boot = pool > on the disk (fixed with my patch), then gptzfsboot will try to load > /boot/zfsloader from the raid-z pool, whether or not it can see enough > vdevs to actually use the pool. If it can't run zfsloader it'll = pointlessly > try /boot/kernel/kernel from it before dumping you at the boot: = prompt. > That is why you see the "Default" showing as it does - it's more "Last > tried" than "Default". >=20 > My advice is to double-check which drive your BIOS is booting from = (make > sure it's one with 'pool2' on it), and if you've got a partition = belonging > to your 'data' pool on the disk (log, cache, etc), you could try = rebuilding > gptzfsboot with my patch providing you're aware that it's untested by > anyone other than myself and by using it you risk causing irreparable > damage to your pools. I hope not seeing as I'm running it myself, but = I've > had no feedback on it. >=20 >=20 > (*) = http://lists.freebsd.org/pipermail/freebsd-fs/2011-June/011882.html >=20 >=20 > HTH, >=20 > Matt. >=20 From owner-freebsd-current@FreeBSD.ORG Wed Jul 13 13:11:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A67941065673; Wed, 13 Jul 2011 13:11:18 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 6659D8FC17; Wed, 13 Jul 2011 13:11:18 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id p6DDBG5U019002; Wed, 13 Jul 2011 22:11:16 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili15) with ESMTP id p6DDBHA20850; Wed, 13 Jul 2011 22:11:17 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi13) id p6DDBH5B008433; Wed, 13 Jul 2011 22:11:17 +0900 Received: from localhost by lomi13.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id p6DDBGta008411; Wed, 13 Jul 2011 22:11:16 +0900 Date: Wed, 13 Jul 2011 22:11:15 +0900 (JST) Message-Id: <20110713.221115.864172011004492659.okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com From: Kohji Okuno In-Reply-To: <20110713.131514.2295692683054433320.okuno.kohji@jp.panasonic.com> References: <20110712145753.GI43872@deviant.kiev.zoral.com.ua> <20110713.131514.2295692683054433320.okuno.kohji@jp.panasonic.com> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: attilio@freebsd.org, freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com, emaste@sandvine.com Subject: Re: Bug about devfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2011 13:11:18 -0000 Hello, > From: Kostik Belousov > Date: Tue, 12 Jul 2011 17:57:53 +0300 >> On Tue, Jul 12, 2011 at 03:02:44PM +0200, Attilio Rao wrote: >>> 2011/7/12 Kostik Belousov : >>> > On Tue, Jul 12, 2011 at 07:10:28PM +0900, Kohji Okuno wrote: >>> >> Hello, >>> >> >>> >> I think that devfs has a problem. >>> >> I encountered the problem that open("/dev/AAA") returned ENOENT.= >>> >> Of course, /dev/AAA exists. >>> >> >>> >> ENOENT was created by the point(***) in devfs_allocv(). >>> >> I think that the race condition had occurred between process A a= nd >>> >> vnlru kernel thread. >>> >> >>> >> Please check the following. >>> >> >>> >> If vnlru set VI_DOOMED to vp->v_iflag but vnlru didn't still exe= cute >>> >> VOP_RECLAIM(), process A cat get valid vp from de->de_vnode. >>> >> But, vget() will return ENOENT, because vp->v_iflag has VI_DOOME= D. >>> >> >>> >> When I set the break point to (***), I checked that de->de_vnode= and >>> >> vp->v_data were NULL. >>> >> >>> >> >>> >> process A: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= vnlru: >>> >> >>> >> devfs_allocv() { >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 vgonel(vp) { >>> >> =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 ... >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 vp->v_iflag |=3D VI_DOOMED; >>> >> =A0 mtx_lock(&devfs_de_interlock); =A0 =A0 =A0 =A0 ... >>> >> =A0 vp =3D de->de_vnode; >>> >> =A0 if (vp !=3D NULL) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = VI_UNLOCK(vp); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ____________= _/ ... >>> >> =A0 VI_LOCK(vp); ____________/ =A0 =A0 =A0 =A0 =A0 =A0 =A0if (VO= P_RECLAIM(vp, td)) >>> >> =A0 mtx_unlock(&devfs_de_interlock); =A0 =A0 =A0 ... >>> >> =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0\ =A0 =A0 =A0 =A0 devfs_reclaim(ap) { >>> >> =A0 error =3D vget(vp,...); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ >>> >> =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0\______ =A0 mtx_lock(&devfs_de_interlock); >>> >> =A0 if (devfs_allocv_drop_refs(...)) { =A0 =A0 =A0 =A0de =3D vp-= >v_data; >>> >> =A0 =A0 ... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (de !=3D NULL) { >>> >> =A0 } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 de->de_vnode =3D NULL; >>> >> =A0 else if (error) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 vp->v_data =3D NULL; >>> >> =A0 =A0 ... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >>> >> =A0 =A0 rturn (error); (***) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= mtx_unlock(&devfs_de_interlock); >>> >> =A0 } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 ... >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 } >>> >> >>> >> >>> >> >>> >> I think that devfs_allocv() should be fixed as below. >>> >> How do you think? >>> >> >>> >> devfs_allocv(struct devfs_dirent *de, struct mount *mp, struct v= node **vpp) >>> >> { >>> >> =A0 =A0 =A0 =A0 int error; >>> >> =A0 =A0 =A0 struct vnode *vp; >>> >> =A0 =A0 =A0 struct cdev *dev; >>> >> =A0 =A0 =A0 struct devfs_mount *dmp; >>> >> >>> >> =A0 =A0 =A0 dmp =3D VFSTODEVFS(mp); >>> >> +#if 1 >>> >> + retry: >>> >> +#endif >>> >> =A0 =A0 =A0 =A0 if (de->de_flags & DE_DOOMED) { >>> >> >>> >> =A0 =A0 =A0 =A0 =A0 =A0... >>> >> >>> >> =A0 =A0 =A0 =A0 mtx_lock(&devfs_de_interlock); >>> >> =A0 =A0 =A0 =A0 vp =3D de->de_vnode; >>> >> =A0 =A0 =A0 =A0 if (vp !=3D NULL) { >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 VI_LOCK(vp); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtx_unlock(&devfs_de_interlock);= >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sx_xunlock(&dmp->dm_lock); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D vget(vp, LK_EXCLUSIVE = | LK_INTERLOCK, curthread); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sx_xlock(&dmp->dm_lock); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (devfs_allocv_drop_refs(0, dm= p, de)) { >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error =3D=3D= 0) >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = vput(vp); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (ENOENT);= >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else if (error) { >>> >> +#if 1 >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error =3D=3D ENOEN= T) >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto r= etry; >>> >> +#endif >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sx_xunlock(&dmp->dm_= lock); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (error); >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >>> >> >>> > Thank you for the report. >>> > >>> > The proposed change would revert r179247, which also caused some = issues. >>> > Are you able to reproduce the problem ? >>> > >>> > Could you try the following patch ? I cannot reproduce your situa= tion, >>> > so the patch is untested by me. >>> > >>> > diff --git a/sys/fs/devfs/devfs_vnops.c b/sys/fs/devfs/devfs_vnop= s.c >>> > index bf6dab8..bbbfff4 100644 >>> > --- a/sys/fs/devfs/devfs_vnops.c >>> > +++ b/sys/fs/devfs/devfs_vnops.c >>> > @@ -397,6 +397,7 @@ devfs_allocv(struct devfs_dirent *de, struct = mount *mp, int lockmode, >>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sx_xunlock(&dmp->dm_lock); >>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (ENOENT); >>> > =A0 =A0 =A0 =A0} >>> > +loop: >>> > =A0 =A0 =A0 =A0DEVFS_DE_HOLD(de); >>> > =A0 =A0 =A0 =A0DEVFS_DMP_HOLD(dmp); >>> > =A0 =A0 =A0 =A0mtx_lock(&devfs_de_interlock); >>> > @@ -412,7 +413,16 @@ devfs_allocv(struct devfs_dirent *de, struct= mount *mp, int lockmode, >>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vp= ut(vp); >>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (ENOENT); >>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >>> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 else if (error) { >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else if (error !=3D 0) { >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error =3D=3D EN= OENT) { >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtx= _lock(&devfs_de_interlock); >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 whi= le (de->de_vnode !=3D NULL) { >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 msleep(&de->de_vnode, >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 &devfs_de_interlock, 0, "dvall", 0); >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtx= _unlock(&devfs_de_interlock); >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 got= o loop; >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sx_xunlock(&dmp->d= m_lock); >>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (error); >>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >>> > @@ -1259,6 +1269,7 @@ devfs_reclaim(struct vop_reclaim_args *ap) >>> > =A0 =A0 =A0 =A0if (de !=3D NULL) { >>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0de->de_vnode =3D NULL; >>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vp->v_data =3D NULL; >>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 wakeup(&de->de_vnode); >>> > =A0 =A0 =A0 =A0} >>> > =A0 =A0 =A0 =A0mtx_unlock(&devfs_de_interlock); >>> = >>> I think that this approach may starve the thread for a while. >>> As I told you privately I was able to see on field a livelock becau= se >>> of this check. In my case, it was a thread running for 63seconds (a= t >>> least, at that point the watchdog was tripping over). >> Feasible explanation was not found at the time, AFAIR. I could belie= ve >> that this is possible with r179247 and driver stuck in the close cde= vsw >> method. >> = >> More risky change would be to clear de_vnode early. All devfs code s= hall >> be already safe by checking for VI_DOOMED, and if VI_DOOMED, v_data = may >> be NULL. >> = >> Again, I am unable to test. >> = >> diff --git a/sys/fs/devfs/devfs_vnops.c b/sys/fs/devfs/devfs_vnops.c= >> index bf6dab8..955bd8b 100644 >> --- a/sys/fs/devfs/devfs_vnops.c >> +++ b/sys/fs/devfs/devfs_vnops.c >> @@ -397,6 +397,7 @@ devfs_allocv(struct devfs_dirent *de, struct mou= nt *mp, int lockmode, >> sx_xunlock(&dmp->dm_lock); >> return (ENOENT); >> } >> +loop: >> DEVFS_DE_HOLD(de); >> DEVFS_DMP_HOLD(dmp); >> mtx_lock(&devfs_de_interlock); >> @@ -405,16 +406,21 @@ devfs_allocv(struct devfs_dirent *de, struct m= ount *mp, int lockmode, >> VI_LOCK(vp); >> mtx_unlock(&devfs_de_interlock); >> sx_xunlock(&dmp->dm_lock); >> - error =3D vget(vp, lockmode | LK_INTERLOCK, curthread); >> + vget(vp, lockmode | LK_INTERLOCK | LK_RETRY, curthread); >> sx_xlock(&dmp->dm_lock); >> if (devfs_allocv_drop_refs(0, dmp, de)) { >> - if (error =3D=3D 0) >> - vput(vp); >> + vput(vp); >> return (ENOENT); >> } >> - else if (error) { >> - sx_xunlock(&dmp->dm_lock); >> - return (error); >> + else if ((vp->v_iflag & VI_DOOMED) !=3D 0) { >> + mtx_lock(&devfs_de_interlock); >> + if (de->de_vnode =3D=3D vp) { >> + de->de_vnode =3D NULL; >> + vp->v_data =3D NULL; >> + } >> + mtx_unlock(&devfs_de_interlock); >> + vput(vp); >> + goto loop; >> } >> sx_xunlock(&dmp->dm_lock); >> *vpp =3D vp; > = > I tried Kostik's last patch, and I checked that open() successed twic= e > by retry. It is difficult for me to reproduce this situation. > = > At least, my problem is solved by this patch. I checked ten times or more. And, I didn't encounter all problems. Thanks, Kohji Okuno. From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 05:52:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 431121065672; Thu, 14 Jul 2011 05:52:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB50A8FC16; Thu, 14 Jul 2011 05:52:56 +0000 (UTC) Received: by yxl31 with SMTP id 31so1859453yxl.13 for ; Wed, 13 Jul 2011 22:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ov843xHUUyIOpLDbSCvo4aabwCUZ7eMxFEyY3a2eoRc=; b=F3kvxoFhb5SGHUt7sN3yhWmAky6AnRGwQs4QNSjkc+Fdu7Y4lhVk/Le1w1pYhKk6TM rv7oUftyY5m101ZF8L2JZD0vp/08+JmHgSZU68iTTeBbH1lDf3d/VNtRoaQcn1PEmxA0 Pnx3zu0DmtkdtCAyQNCpkZN099pgxm6cWsJmo= MIME-Version: 1.0 Received: by 10.151.134.4 with SMTP id l4mr2110375ybn.272.1310622776393; Wed, 13 Jul 2011 22:52:56 -0700 (PDT) Received: by 10.150.189.1 with HTTP; Wed, 13 Jul 2011 22:52:56 -0700 (PDT) Date: Thu, 14 Jul 2011 13:52:56 +0800 Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Subject: 802.11 regulatory update - Japan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2011 05:52:57 -0000 Hi all, I've updated the -current regulatory domain database to include some of the missing 5ghz channels that are now allowed in Japan. Please test/comment. Thanks! Adrian From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 05:53:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFA89106564A; Thu, 14 Jul 2011 05:53:42 +0000 (UTC) (envelope-from matpockuh@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 7BAE68FC1F; Thu, 14 Jul 2011 05:53:42 +0000 (UTC) Received: by pvg11 with SMTP id 11so7017134pvg.13 for ; Wed, 13 Jul 2011 22:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tHcunqki3GdTrO6hhaB+y/SuvqdtC5FYQSjppKCJ40M=; b=GgyuHKgZ3eyagI1KTE/dWuYVyZI4jhh8Ptxs1v9EWGq8kzJNidMTAFq61hz9KJ2+Iw FSdRW9RchVvk0T+k1yOxKvW5v/3ZSQUxZOw6YqnFg84d/BQ97WQGAITjp4iMXWzQeAf0 IE9mOLrHF8RWngExO3SJeORTxo1oARBv01Xr8= MIME-Version: 1.0 Received: by 10.68.49.232 with SMTP id x8mr2143215pbn.307.1310622822157; Wed, 13 Jul 2011 22:53:42 -0700 (PDT) Received: by 10.68.62.97 with HTTP; Wed, 13 Jul 2011 22:53:42 -0700 (PDT) In-Reply-To: References: <20110629134140.GF14797@alchemy.franken.de> <4E0B8F25.7090107@FreeBSD.org> <20110707100446.GJ14797@alchemy.franken.de> <20110707154958.GK14797@alchemy.franken.de> <20110708181102.GA95673@alchemy.franken.de> <20110708193236.GB95673@alchemy.franken.de> Date: Thu, 14 Jul 2011 09:53:42 +0400 Message-ID: From: KOT MATPOCKuH To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2011 05:53:42 -0000 2011/7/11 KOT MATPOCKuH : >> Oops, sorry, I forgot to revert the previous patch when test-compiling. >> Please re-fetch sparc64_isc_atomic.h.diff2 and try again. > I started named from ports (dns/bind96) at Sat Jul =A09 10:08:41 MSD, > and it worked properly till Sun Jul 10 22:25:41 MSD. > At 22:25:41 I restarted bind from base system with your > sparc64_isc_atomic.h.diff2. > From this moment till today, 15:57:05 he crashed 3 times: > Jul 10 23:19:19 sunrise kernel: pid 45352 (named), uid 53: exited on sign= al 6 > Jul 11 14:52:20 sunrise kernel: pid 52032 (named), uid 53: exited on sign= al 6 > Jul 11 15:14:15 sunrise kernel: pid 71300 (named), uid 53: exited on sign= al 6 > > To make to ensure proper operation of bind from ports, I ran it again > at 15:57:05, and, I think, we need to wait several days. And from that time till now bind from ports never died and works properly..= . --=20 MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 08:59:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id F33B2106574C; Thu, 14 Jul 2011 08:59:12 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2512514F829; Thu, 14 Jul 2011 08:59:09 +0000 (UTC) Message-ID: <4E1EAFDD.2010201@FreeBSD.org> Date: Thu, 14 Jul 2011 01:59:09 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin References: <4E100086.7080105@FreeBSD.org> <201107080919.58210.jhb@freebsd.org> <4E1BA36F.5060504@FreeBSD.org> <201107121022.16999.jhb@freebsd.org> In-Reply-To: <201107121022.16999.jhb@freebsd.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2011 08:59:13 -0000 On 07/12/2011 07:22, John Baldwin wrote: > On Monday, July 11, 2011 9:29:19 pm Doug Barton wrote: >> On 07/08/2011 06:19, John Baldwin wrote: >> >>> Hmm, well that's odd. It didn't grow it enough it seems. >>> >>>>> Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert >>>>> the card and record the messages in dmesg when it does? (You can likely get >>>>> those out of kgdb.) >> >> I tried your patch, and got some odd results. The good news is, no >> crash. However it did not actually enable the cards, with or without >> if_ath being loaded before inserting them. Here is the dmesg output with >> debug.bootverbose=1. This is with inserting and removing first one card, >> then the other. > > Hmm, can you try without NEW_PCIB just as a test? (You'll need to add > 'nooption NEW_PCIB' to your kernel config file.) No change. Still no panic, but the cards were not recognized with or without if_ath loaded in advance. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 10:27:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 221AE106566B; Thu, 14 Jul 2011 10:27:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE9D48FC17; Thu, 14 Jul 2011 10:27:22 +0000 (UTC) Received: by yic13 with SMTP id 13so50162yic.13 for ; Thu, 14 Jul 2011 03:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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 :content-transfer-encoding; bh=nte+jT5od7hY/1tORKfEqGek+Pworhj0I4itQl+r7yE=; b=WQQI/Cbd1KoPEMmd3r85SmxUiKukLoMxDfujkXkhzaZK/GGU8qIzRXb2LqVa1/8inO zheZW6w2zyzvwXftQJunnWhlA+pWVXz0PtTpfOnp7r+oYH1+tcB+VAEdDiWFt8vo29gY 9z7Y3fRe6rW1vIp2k2/nB51OYo/4YmMkxftgs= MIME-Version: 1.0 Received: by 10.151.134.4 with SMTP id l4mr2325856ybn.272.1310639240116; Thu, 14 Jul 2011 03:27:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.189.1 with HTTP; Thu, 14 Jul 2011 03:27:20 -0700 (PDT) In-Reply-To: <4E1EAFDD.2010201@FreeBSD.org> References: <4E100086.7080105@FreeBSD.org> <201107080919.58210.jhb@freebsd.org> <4E1BA36F.5060504@FreeBSD.org> <201107121022.16999.jhb@freebsd.org> <4E1EAFDD.2010201@FreeBSD.org> Date: Thu, 14 Jul 2011 18:27:20 +0800 X-Google-Sender-Auth: HcdM-XgI_mqr4ujdod1T2Cu2W2A Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2011 10:27:23 -0000 Don't forget if_ath_pci. Adrian On 14 July 2011 16:59, Doug Barton wrote: > On 07/12/2011 07:22, John Baldwin wrote: >> On Monday, July 11, 2011 9:29:19 pm Doug Barton wrote: >>> On 07/08/2011 06:19, John Baldwin wrote: >>> >>>> Hmm, well that's odd. =A0It didn't grow it enough it seems. >>>> >>>>>> Also, can you boot your machine, then do 'sysctl debug.bootverbose= =3D1', insert >>>>>> the card and record the messages in dmesg when it does? =A0(You can = likely get >>>>>> those out of kgdb.) >>> >>> I tried your patch, and got some odd results. The good news is, no >>> crash. However it did not actually enable the cards, with or without >>> if_ath being loaded before inserting them. Here is the dmesg output wit= h >>> debug.bootverbose=3D1. This is with inserting and removing first one ca= rd, >>> then the other. >> >> Hmm, can you try without NEW_PCIB just as a test? =A0(You'll need to add >> 'nooption NEW_PCIB' to your kernel config file.) > > No change. Still no panic, but the cards were not recognized with or > without if_ath loaded in advance. > > > > -- > > =A0 =A0 =A0 =A0Nothin' ever doesn't change, but nothin' changes much. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- OK Go > > =A0 =A0 =A0 =A0Breadth of IT experience, and depth of knowledge in the DN= S. > =A0 =A0 =A0 =A0Yours for the right price. =A0:) =A0http://SupersetSolutio= ns.com/ > > _______________________________________________ > 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 14 18:47:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7E001065672; Thu, 14 Jul 2011 18:47:22 +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 8CB898FC0C; Thu, 14 Jul 2011 18:47:22 +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 32FB146B0D; Thu, 14 Jul 2011 14:47:22 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A18558A02F; Thu, 14 Jul 2011 14:47:21 -0400 (EDT) From: John Baldwin To: Adrian Chadd Date: Thu, 14 Jul 2011 14:39:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E100086.7080105@FreeBSD.org> <4E1EAFDD.2010201@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107141439.27225.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 14 Jul 2011 14:47:21 -0400 (EDT) Cc: Doug Barton , freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2011 18:47:22 -0000 On Thursday, July 14, 2011 6:27:20 am Adrian Chadd wrote: > Don't forget if_ath_pci. Which I think is a bug for this very reason if it turns out to be the cause. > Adrian > > On 14 July 2011 16:59, Doug Barton wrote: > > On 07/12/2011 07:22, John Baldwin wrote: > >> On Monday, July 11, 2011 9:29:19 pm Doug Barton wrote: > >>> On 07/08/2011 06:19, John Baldwin wrote: > >>> > >>>> Hmm, well that's odd. It didn't grow it enough it seems. > >>>> > >>>>>> Also, can you boot your machine, then do 'sysctl debug.bootverbose=1', insert > >>>>>> the card and record the messages in dmesg when it does? (You can likely get > >>>>>> those out of kgdb.) > >>> > >>> I tried your patch, and got some odd results. The good news is, no > >>> crash. However it did not actually enable the cards, with or without > >>> if_ath being loaded before inserting them. Here is the dmesg output with > >>> debug.bootverbose=1. This is with inserting and removing first one card, > >>> then the other. > >> > >> Hmm, can you try without NEW_PCIB just as a test? (You'll need to add > >> 'nooption NEW_PCIB' to your kernel config file.) > > > > No change. Still no panic, but the cards were not recognized with or > > without if_ath loaded in advance. > > > > > > > > -- > > > > Nothin' ever doesn't change, but nothin' changes much. > > -- OK Go > > > > Breadth of IT experience, and depth of knowledge in the DNS. > > Yours for the right price. :) http://SupersetSolutions.com/ > > > > _______________________________________________ > > 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" > > > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 19:55:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id AD047106566C; Thu, 14 Jul 2011 19:55:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1B3F714DDD8; Thu, 14 Jul 2011 19:55:08 +0000 (UTC) Message-ID: <4E1F499C.4010804@FreeBSD.org> Date: Thu, 14 Jul 2011 12:55:08 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin References: <4E100086.7080105@FreeBSD.org> <4E1EAFDD.2010201@FreeBSD.org> <201107141439.27225.jhb@freebsd.org> In-Reply-To: <201107141439.27225.jhb@freebsd.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2011 19:55:09 -0000 On 07/14/2011 11:39, John Baldwin wrote: > On Thursday, July 14, 2011 6:27:20 am Adrian Chadd wrote: >> > Don't forget if_ath_pci. > Which I think is a bug for this very reason if it turns out to be the cause. I have MODULES_OVERRIDE=ath ... in src.conf and I have an if_ath module, but no if_ath_pci module. There is no directory in /sys/modules for either, and no Makefile in /sys/dev/ath. Looking in GENERIC it seems I'm going to need ath_hal as well? Do _pci and _hal need to be compiled into the kernel unconditionally in order to use if_ath? Or am I missing something? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 23:21:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D71D106566C; Thu, 14 Jul 2011 23:21:29 +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 79B7F8FC15; Thu, 14 Jul 2011 23:21:28 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p6ENLQcZ042056; Fri, 15 Jul 2011 01:21:27 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p6ENLQqd042055; Fri, 15 Jul 2011 01:21:26 +0200 (CEST) (envelope-from marius) Date: Fri, 15 Jul 2011 01:21:26 +0200 From: Marius Strobl To: Doug Barton Message-ID: <20110714232126.GK95673@alchemy.franken.de> References: <20110707100446.GJ14797@alchemy.franken.de> <20110707154958.GK14797@alchemy.franken.de> <20110708181102.GA95673@alchemy.franken.de> <20110708193236.GB95673@alchemy.franken.de> 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: KOT MATPOCKuH , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2011 23:21:29 -0000 On Thu, Jul 14, 2011 at 09:53:42AM +0400, KOT MATPOCKuH wrote: > 2011/7/11 KOT MATPOCKuH : > >> Oops, sorry, I forgot to revert the previous patch when test-compiling. > >> Please re-fetch sparc64_isc_atomic.h.diff2 and try again. > > I started named from ports (dns/bind96) at Sat Jul ?9 10:08:41 MSD, > > and it worked properly till Sun Jul 10 22:25:41 MSD. > > At 22:25:41 I restarted bind from base system with your > > sparc64_isc_atomic.h.diff2. > > From this moment till today, 15:57:05 he crashed 3 times: > > Jul 10 23:19:19 sunrise kernel: pid 45352 (named), uid 53: exited on signal 6 > > Jul 11 14:52:20 sunrise kernel: pid 52032 (named), uid 53: exited on signal 6 > > Jul 11 15:14:15 sunrise kernel: pid 71300 (named), uid 53: exited on signal 6 > > > > To make to ensure proper operation of bind from ports, I ran it again > > at 15:57:05, and, I think, we need to wait several days. > And from that time till now bind from ports never died and works properly... > Okay. Doug, could you please disable the use of atomic operations for sparc64 in the in-tree BIND via the following patch in order to match what the vendor source does? http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff I've no idea why they don't work properly (apart from the fact that there additionally should be memory barriers at least when used for reference counting just like the alpha version of the ISC atomic operations uses), I just can say they match what we use in the kernel without problems pretty closely and that they work as described in the respective comments when testing them stand-alone. So my best guess is that the BIND source additionaly depends on some x86-specific behavior of the atomic operations there or in general, but from a glance the source it's not obvious for me what that could be. Given that the vendor source doesn't even use atomic operations on Solaris/SPARC I suspect this is a non-trivial problem. It probably would be a good idea to also disable the use of atomic operations for arm again just like the vendor source does as they don't work there either but nobody seems to care (see PR 154306). Marius From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 23:52:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E74FD1065673; Thu, 14 Jul 2011 23:52:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4C93714DB34; Thu, 14 Jul 2011 23:52:16 +0000 (UTC) Message-ID: <4E1F812E.708@FreeBSD.org> Date: Thu, 14 Jul 2011 16:52:14 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin References: <4E100086.7080105@FreeBSD.org> <4E1EAFDD.2010201@FreeBSD.org> <201107141439.27225.jhb@freebsd.org> <4E1F499C.4010804@FreeBSD.org> In-Reply-To: <4E1F499C.4010804@FreeBSD.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org Subject: Re: cardbus panic: end address is not aligned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2011 23:52:22 -0000 On 07/14/2011 12:55, Doug Barton wrote: > On 07/14/2011 11:39, John Baldwin wrote: >> On Thursday, July 14, 2011 6:27:20 am Adrian Chadd wrote: >>>> Don't forget if_ath_pci. >> Which I think is a bug for this very reason if it turns out to be the cause. > > I have > > MODULES_OVERRIDE=ath ... > > in src.conf and I have an if_ath module, but no if_ath_pci module. There > is no directory in /sys/modules for either, and no Makefile in > /sys/dev/ath. Looking in GENERIC it seems I'm going to need ath_hal as > well? Do _pci and _hal need to be compiled into the kernel > unconditionally in order to use if_ath? Or am I missing something? Adrian set me straight on /sys/modules/ath[_pci] being the proper places to build the modules, and with if_ath_pci kldload'ed the cards are recognized. There is a minor issue with one of the cards but I have some other things to poke before I am sure it's FreeBSD at fault this time. So it's likely this issue is closed. Thanks again John and Adrian for your help. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 00:31:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 7C33C106566C for ; Fri, 15 Jul 2011 00:31:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 02809150A89; Fri, 15 Jul 2011 00:31:49 +0000 (UTC) Message-ID: <4E1F8A75.5060304@FreeBSD.org> Date: Thu, 14 Jul 2011 17:31:49 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Marius Strobl References: <20110707100446.GJ14797@alchemy.franken.de> <20110707154958.GK14797@alchemy.franken.de> <20110708181102.GA95673@alchemy.franken.de> <20110708193236.GB95673@alchemy.franken.de> <20110714232126.GK95673@alchemy.franken.de> In-Reply-To: <20110714232126.GK95673@alchemy.franken.de> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: KOT MATPOCKuH , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2011 00:31:50 -0000 On 07/14/2011 16:21, Marius Strobl wrote: > On Thu, Jul 14, 2011 at 09:53:42AM +0400, KOT MATPOCKuH wrote: >> 2011/7/11 KOT MATPOCKuH : >>>> Oops, sorry, I forgot to revert the previous patch when test-compiling. >>>> Please re-fetch sparc64_isc_atomic.h.diff2 and try again. >>> I started named from ports (dns/bind96) at Sat Jul ?9 10:08:41 MSD, >>> and it worked properly till Sun Jul 10 22:25:41 MSD. >>> At 22:25:41 I restarted bind from base system with your >>> sparc64_isc_atomic.h.diff2. >>> From this moment till today, 15:57:05 he crashed 3 times: >>> Jul 10 23:19:19 sunrise kernel: pid 45352 (named), uid 53: exited on signal 6 >>> Jul 11 14:52:20 sunrise kernel: pid 52032 (named), uid 53: exited on signal 6 >>> Jul 11 15:14:15 sunrise kernel: pid 71300 (named), uid 53: exited on signal 6 >>> >>> To make to ensure proper operation of bind from ports, I ran it again >>> at 15:57:05, and, I think, we need to wait several days. >> And from that time till now bind from ports never died and works properly... >> > > Okay. > Doug, could you please disable the use of atomic operations for sparc64 > in the in-tree BIND via the following patch in order to match what the > vendor source does? > http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff If you use the port and do 'make configure' are the values in config.h the same as the ones in your patch? If so, that's likely to be the right answer, and I'll go ahead and apply your patch. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 08:40:41 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F6191065676; Fri, 15 Jul 2011 08:40:41 +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 7C0AF8FC13; Fri, 15 Jul 2011 08:40:40 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p6F8ed2g068867; Fri, 15 Jul 2011 10:40:39 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p6F8eddK068866; Fri, 15 Jul 2011 10:40:39 +0200 (CEST) (envelope-from marius) Date: Fri, 15 Jul 2011 10:40:39 +0200 From: Marius Strobl To: Doug Barton Message-ID: <20110715084039.GL95673@alchemy.franken.de> References: <20110707154958.GK14797@alchemy.franken.de> <20110708181102.GA95673@alchemy.franken.de> <20110708193236.GB95673@alchemy.franken.de> <20110714232126.GK95673@alchemy.franken.de> <4E1F8A75.5060304@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E1F8A75.5060304@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: KOT MATPOCKuH , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2011 08:40:41 -0000 On Thu, Jul 14, 2011 at 05:31:49PM -0700, Doug Barton wrote: > On 07/14/2011 16:21, Marius Strobl wrote: > > On Thu, Jul 14, 2011 at 09:53:42AM +0400, KOT MATPOCKuH wrote: > >> 2011/7/11 KOT MATPOCKuH : > >>>> Oops, sorry, I forgot to revert the previous patch when test-compiling. > >>>> Please re-fetch sparc64_isc_atomic.h.diff2 and try again. > >>> I started named from ports (dns/bind96) at Sat Jul ?9 10:08:41 MSD, > >>> and it worked properly till Sun Jul 10 22:25:41 MSD. > >>> At 22:25:41 I restarted bind from base system with your > >>> sparc64_isc_atomic.h.diff2. > >>> From this moment till today, 15:57:05 he crashed 3 times: > >>> Jul 10 23:19:19 sunrise kernel: pid 45352 (named), uid 53: exited on signal 6 > >>> Jul 11 14:52:20 sunrise kernel: pid 52032 (named), uid 53: exited on signal 6 > >>> Jul 11 15:14:15 sunrise kernel: pid 71300 (named), uid 53: exited on signal 6 > >>> > >>> To make to ensure proper operation of bind from ports, I ran it again > >>> at 15:57:05, and, I think, we need to wait several days. > >> And from that time till now bind from ports never died and works properly... > >> > > > > Okay. > > Doug, could you please disable the use of atomic operations for sparc64 > > in the in-tree BIND via the following patch in order to match what the > > vendor source does? > > http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff > > If you use the port and do 'make configure' are the values in config.h > the same as the ones in your patch? If so, that's likely to be the > right answer, and I'll go ahead and apply your patch. > The generated config.h and platform.h for sparc64 are these: http://people.freebsd.org/~marius/bind96_config.h http://people.freebsd.org/~marius/bind96_platform.h Marius From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 15:03:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5E7A106566B for ; Fri, 15 Jul 2011 15:03:56 +0000 (UTC) (envelope-from rmh.aybabtu@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 9DABF8FC18 for ; Fri, 15 Jul 2011 15:03:56 +0000 (UTC) Received: by iwr19 with SMTP id 19so1517367iwr.13 for ; Fri, 15 Jul 2011 08:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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 :content-transfer-encoding; bh=oe4vI+aQ6ZTRhu4R8wnK2Wul5blazZmt+h37ORuSixc=; b=jnxkpvvqOzEDsnx0Jh0ZMqo9z7h2c4HqHjeyQ4BAOsuv7ZhuRR68JKYZMMNUYXdl+1 4oeite7D514n5VYBwLnLwIGuyPI/uRC8uwjisQOkzzs4J8wjP0xpdhZ6M6658IyEDTtN 1e8JVhJwcsJoRqe2saFIqTw+lLCMzQbc7VdnU= MIME-Version: 1.0 Received: by 10.42.204.3 with SMTP id fk3mr4031379icb.515.1310742236130; Fri, 15 Jul 2011 08:03:56 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.224.70 with HTTP; Fri, 15 Jul 2011 08:03:56 -0700 (PDT) In-Reply-To: <3FC50F07-2C7B-4DD4-A75C-49001CFEF85D@bsdimp.com> References: <201106242342.47194.hselasky@c2i.net> <201106251907.02052.hselasky@c2i.net> <201106260738.21847.hselasky@c2i.net> <3FC50F07-2C7B-4DD4-A75C-49001CFEF85D@bsdimp.com> Date: Fri, 15 Jul 2011 17:03:56 +0200 X-Google-Sender-Auth: dXg2yH3X9JDlEtLM93Rp0a6RrIM Message-ID: From: Robert Millan To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 15 Jul 2011 15:19:56 +0000 Cc: Jeremy Messenger , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:03:56 -0000 2011/6/26 Warner Losh : > I like the idea of having a standardized table. =C2=A0I've done this with= PC Card and it really works well. =C2=A0It isn't the design pattern that a= ll drivers use, and it may be hard to get everyone lined up on this. =C2=A0= I tried PCI back after I did PC Card and met resistance. =C2=A0Most of the = resistance was from people that are no longer active in the project, so I t= hink that we could do this today. =C2=A0 I suspect that some of the vendor = drivers today might stand in the way of having PCI be completely uniform. > > The big advantage of USB is that it is uniform now. =C2=A0PCI isn't. =C2= =A0It would take a lot of work to make it uniform. If only some PCI drivers can be made uniform, why not provide devd autoload support only to those drivers whose maintainers choose to make them uniform? This would give those opposing uniformity a compelling reason to change their view, without forcing them into it. --=20 Robert Millan From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 15:49:25 2011 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 01A61106566B; Fri, 15 Jul 2011 15:49:25 +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 ACA088FC08; Fri, 15 Jul 2011 15:49:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6FFnNFK075721; Fri, 15 Jul 2011 11:49:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6FFnNhW075677; Fri, 15 Jul 2011 15:49:23 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 15 Jul 2011 15:49:23 GMT Message-Id: <201107151549.p6FFnNhW075677@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 ia64/ia64 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, 15 Jul 2011 15:49:25 -0000 TB --- 2011-07-15 14:29:56 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-15 14:29:56 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-07-15 14:29:56 - cleaning the object tree TB --- 2011-07-15 14:30:18 - cvsupping the source tree TB --- 2011-07-15 14:30:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-07-15 14:30:30 - building world TB --- 2011-07-15 14:30:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-15 14:30:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-15 14:30:30 - TARGET=ia64 TB --- 2011-07-15 14:30:30 - TARGET_ARCH=ia64 TB --- 2011-07-15 14:30:30 - TZ=UTC TB --- 2011-07-15 14:30:30 - __MAKE_CONF=/dev/null TB --- 2011-07-15 14:30:30 - cd /src TB --- 2011-07-15 14:30:30 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 15 14:30:31 UTC 2011 >>> 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 [...] cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/asltransform.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/asltree.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslutils.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/asluuid.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslwalks.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/dtcompile.c mv -f dtparserparse.h dtparser.y.h mv: rename dtparserparse.h to dtparser.y.h: No such file or directory *** Error code 1 Stop in /src/usr.sbin/acpi/iasl. *** Error code 1 Stop in /src/usr.sbin/acpi. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-15 15:49:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-15 15:49:23 - ERROR: failed to build world TB --- 2011-07-15 15:49:23 - 3742.35 user 737.04 system 4766.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 16:24:47 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFBD71065675 for ; Fri, 15 Jul 2011 16:24:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 779348FC0A for ; Fri, 15 Jul 2011 16:24:47 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p6FGKMZB030394 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 15 Jul 2011 10:20:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 15 Jul 2011 10:20:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201106242342.47194.hselasky@c2i.net> <201106251907.02052.hselasky@c2i.net> <201106260738.21847.hselasky@c2i.net> <3FC50F07-2C7B-4DD4-A75C-49001CFEF85D@bsdimp.com> To: Robert Millan X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Fri, 15 Jul 2011 10:20:24 -0600 (MDT) Cc: Jeremy Messenger , freebsd-current@FreeBSD.org, Hans Petter Selasky Subject: Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 16:24:47 -0000 On Jul 15, 2011, at 9:03 AM, Robert Millan wrote: > 2011/6/26 Warner Losh : >> I like the idea of having a standardized table. I've done this with = PC Card and it really works well. It isn't the design pattern that all = drivers use, and it may be hard to get everyone lined up on this. I = tried PCI back after I did PC Card and met resistance. Most of the = resistance was from people that are no longer active in the project, so = I think that we could do this today. I suspect that some of the vendor = drivers today might stand in the way of having PCI be completely = uniform. >>=20 >> The big advantage of USB is that it is uniform now. PCI isn't. It = would take a lot of work to make it uniform. >=20 > If only some PCI drivers can be made uniform, why not provide devd > autoload support only to those drivers whose maintainers choose to > make them uniform? This would give those opposing uniformity a > compelling reason to change their view, without forcing them into it. Sure. The problem is that I don't want it to be another hack like the = current USB which is specific to PCI. Warner From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 17:43:41 2011 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 C6BCC106564A for ; Fri, 15 Jul 2011 17:43:41 +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 859268FC1A for ; Fri, 15 Jul 2011 17:43:41 +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 08F2846B0A for ; Fri, 15 Jul 2011 13:43:41 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9C1B78A02C for ; Fri, 15 Jul 2011 13:43:40 -0400 (EDT) From: John Baldwin To: current@freebsd.org Date: Fri, 15 Jul 2011 13:43:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201107151343.40065.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 15 Jul 2011 13:43:40 -0400 (EDT) Cc: Subject: [PATCH] Export per-thread resource usage via sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Jul 2011 17:43:41 -0000 This change exports each individual thread's resource usage via sysctl when individual threads are requested via KERN_PROC_INC_THREAD. This generally works correctly with 'top -m io' after the previous change to revert top(1) back to using KERN_PROC_PROC when threads are not enabled. There is one issue in that top doesn't necessarily DTRT when disabling/enabling threads via 'H' at runtime while in io mode. I may do some further work to clean that up. However, for just top run it will now show per-thread stats instead of duplicating the per-process stats for each thread. It also fixes a bug in that the code in calcru() to try to account for the current thread's runtime wasn't correctly accounting charging that time to the current thread. Index: sys/kern/kern_proc.c =================================================================== --- sys/kern/kern_proc.c (revision 224058) +++ sys/kern/kern_proc.c (working copy) @@ -848,6 +848,8 @@ kp->ki_tdaddr = td; PROC_LOCK_ASSERT(p, MA_OWNED); + if (preferthread) + PROC_SLOCK(p); thread_lock(td); if (td->td_wmesg != NULL) strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki_wmesg)); @@ -899,6 +901,7 @@ kp->ki_pri.pri_user = td->td_user_pri; if (preferthread) { + rufetchtd(td, &kp->ki_rusage); kp->ki_runtime = cputick2usec(td->td_rux.rux_runtime); kp->ki_pctcpu = sched_pctcpu(td); kp->ki_estcpu = td->td_estcpu; @@ -911,6 +914,8 @@ kp->ki_siglist = td->td_siglist; kp->ki_sigmask = td->td_sigmask; thread_unlock(td); + if (preferthread) + PROC_SUNLOCK(p); } /* Index: sys/kern/kern_resource.c =================================================================== --- sys/kern/kern_resource.c (revision 224058) +++ sys/kern/kern_resource.c (working copy) @@ -813,7 +813,7 @@ calcru(struct proc *p, struct timeval *up, struct timeval *sp) { struct thread *td; - uint64_t u; + uint64_t runtime, u; PROC_LOCK_ASSERT(p, MA_OWNED); PROC_SLOCK_ASSERT(p, MA_OWNED); @@ -826,7 +826,9 @@ td = curthread; if (td->td_proc == p) { u = cpu_ticks(); - p->p_rux.rux_runtime += u - PCPU_GET(switchtime); + runtime = u - PCPU_GET(switchtime); + td->td_runtime += runtime; + td->td_incruntime += runtime; PCPU_SET(switchtime, u); } /* Make sure the per-thread stats are current. */ @@ -838,6 +840,34 @@ calcru1(p, &p->p_rux, up, sp); } +/* Collect resource usage for a single thread. */ +void +rufetchtd(struct thread *td, struct rusage *ru) +{ + struct proc *p; + uint64_t runtime, u; + + p = td->td_proc; + PROC_SLOCK_ASSERT(p, MA_OWNED); + THREAD_LOCK_ASSERT(td, MA_OWNED); + /* + * If we are getting stats for the current thread, then add in the + * stats that this thread has accumulated in its current time slice. + * We reset the thread and CPU state as if we had performed a context + * switch right here. + */ + if (td == curthread) { + u = cpu_ticks(); + runtime = u - PCPU_GET(switchtime); + td->td_runtime += runtime; + td->td_incruntime += runtime; + PCPU_SET(switchtime, u); + } + ruxagg(p, td); + *ru = td->td_ru; + calcru1(p, &td->td_rux, &ru->ru_utime, &ru->ru_stime); +} + static void calcru1(struct proc *p, struct rusage_ext *ruxp, struct timeval *up, struct timeval *sp) @@ -955,12 +985,10 @@ case RUSAGE_THREAD: PROC_SLOCK(p); - ruxagg(p, td); - PROC_SUNLOCK(p); thread_lock(td); - *rup = td->td_ru; - calcru1(p, &td->td_rux, &rup->ru_utime, &rup->ru_stime); + rufetchtd(td, rup); thread_unlock(td); + PROC_SUNLOCK(p); break; default: Index: sys/sys/resourcevar.h =================================================================== --- sys/sys/resourcevar.h (revision 224058) +++ sys/sys/resourcevar.h (working copy) @@ -136,6 +136,7 @@ void rufetch(struct proc *p, struct rusage *ru); void rufetchcalc(struct proc *p, struct rusage *ru, struct timeval *up, struct timeval *sp); +void rufetchtd(struct thread *td, struct rusage *ru); void ruxagg(struct proc *p, struct thread *td); int suswintr(void *base, int word); struct uidinfo -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 02:23:24 2011 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 33AA91065672; Sat, 16 Jul 2011 02:23:24 +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 E89358FC08; Sat, 16 Jul 2011 02:23:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6G2NNGA086967; Fri, 15 Jul 2011 22:23:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6G2NMZ1086946; Sat, 16 Jul 2011 02:23:22 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Jul 2011 02:23:22 GMT Message-Id: <201107160223.p6G2NMZ1086946@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 i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 02:23:24 -0000 TB --- 2011-07-16 00:10:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-16 00:10:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-07-16 00:10:01 - cleaning the object tree TB --- 2011-07-16 00:10:37 - cvsupping the source tree TB --- 2011-07-16 00:10:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-07-16 00:11:00 - building world TB --- 2011-07-16 00:11:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 00:11:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 00:11:00 - TARGET=pc98 TB --- 2011-07-16 00:11:00 - TARGET_ARCH=i386 TB --- 2011-07-16 00:11:00 - TZ=UTC TB --- 2011-07-16 00:11:00 - __MAKE_CONF=/dev/null TB --- 2011-07-16 00:11:00 - cd /src TB --- 2011-07-16 00:11:00 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 16 00:11:00 UTC 2011 >>> 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 Sat Jul 16 02:07:59 UTC 2011 TB --- 2011-07-16 02:07:59 - generating LINT kernel config TB --- 2011-07-16 02:07:59 - cd /src/sys/pc98/conf TB --- 2011-07-16 02:07:59 - /usr/bin/make -B LINT TB --- 2011-07-16 02:08:00 - building LINT kernel TB --- 2011-07-16 02:08:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 02:08:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 02:08:00 - TARGET=pc98 TB --- 2011-07-16 02:08:00 - TARGET_ARCH=i386 TB --- 2011-07-16 02:08:00 - TZ=UTC TB --- 2011-07-16 02:08:00 - __MAKE_CONF=/dev/null TB --- 2011-07-16 02:08:00 - cd /src TB --- 2011-07-16 02:08:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 16 02:08:00 UTC 2011 >>> 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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/busdma_machdep.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/dump_machdep.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/io_apic.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/local_apic.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/mca.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/mptable.c cc1: warnings being treated as errors /src/sys/x86/x86/mptable.c:446: warning: 'mptable_walk_extended_table' defined but not used *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-16 02:23:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-16 02:23:22 - ERROR: failed to build lint kernel TB --- 2011-07-16 02:23:22 - 6292.23 user 1182.91 system 8001.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 03:12:09 2011 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 4CAE8106564A for ; Sat, 16 Jul 2011 03:12:09 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id F3F078FC08 for ; Sat, 16 Jul 2011 03:12:08 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.4/8.14.4) with ESMTP id p6G2hgfp066756; Fri, 15 Jul 2011 21:43:42 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4E20FADE.6060103@missouri.edu> Date: Fri, 15 Jul 2011 21:43:42 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: bug-followup@freebsd.org, freebsd@sopwith.solgatos.com, current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(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: Sat, 16 Jul 2011 03:12:09 -0000 I was looking through the source code of pkg_add. Personally I don't see how the "-P" or "-p" option could be made to work with pkg_add. Many of the installation commands involve scripts which have ${PREFIX} hard coded into them. ${PREFIX} is often hard coded when trhe package is created by the port. In my opinion, the options "-p" and "-P" should be removed from pkg_add. Either that, or provide the port a way to access "@cwd" in any scripts it installs. But this would require a major overhaul of the whole ports system, and probably much of the software it installs as well. Am I missing something? Stephen From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 03:16:34 2011 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 799041065670; Sat, 16 Jul 2011 03:16:34 +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 3246C8FC08; Sat, 16 Jul 2011 03:16:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6G3GXdJ097705; Fri, 15 Jul 2011 23:16:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6G3GXnw097628; Sat, 16 Jul 2011 03:16:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Jul 2011 03:16:33 GMT Message-Id: <201107160316.p6G3GXnw097628@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 i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 03:16:34 -0000 TB --- 2011-07-16 00:10:01 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-16 00:10:01 - starting HEAD tinderbox run for i386/i386 TB --- 2011-07-16 00:10:01 - cleaning the object tree TB --- 2011-07-16 00:10:46 - cvsupping the source tree TB --- 2011-07-16 00:10:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-07-16 00:11:00 - building world TB --- 2011-07-16 00:11:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 00:11:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 00:11:00 - TARGET=i386 TB --- 2011-07-16 00:11:00 - TARGET_ARCH=i386 TB --- 2011-07-16 00:11:00 - TZ=UTC TB --- 2011-07-16 00:11:00 - __MAKE_CONF=/dev/null TB --- 2011-07-16 00:11:00 - cd /src TB --- 2011-07-16 00:11:00 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 16 00:11:00 UTC 2011 >>> 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 Sat Jul 16 02:08:10 UTC 2011 TB --- 2011-07-16 02:08:10 - generating LINT kernel config TB --- 2011-07-16 02:08:10 - cd /src/sys/i386/conf TB --- 2011-07-16 02:08:10 - /usr/bin/make -B LINT TB --- 2011-07-16 02:08:10 - building LINT kernel TB --- 2011-07-16 02:08:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 02:08:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 02:08:10 - TARGET=i386 TB --- 2011-07-16 02:08:10 - TARGET_ARCH=i386 TB --- 2011-07-16 02:08:10 - TZ=UTC TB --- 2011-07-16 02:08:10 - __MAKE_CONF=/dev/null TB --- 2011-07-16 02:08:10 - cd /src TB --- 2011-07-16 02:08:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 16 02:08:11 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jul 16 02:38:28 UTC 2011 TB --- 2011-07-16 02:38:28 - cd /src/sys/i386/conf TB --- 2011-07-16 02:38:28 - /usr/sbin/config -m GENERIC TB --- 2011-07-16 02:38:28 - building GENERIC kernel TB --- 2011-07-16 02:38:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 02:38:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 02:38:28 - TARGET=i386 TB --- 2011-07-16 02:38:28 - TARGET_ARCH=i386 TB --- 2011-07-16 02:38:28 - TZ=UTC TB --- 2011-07-16 02:38:28 - __MAKE_CONF=/dev/null TB --- 2011-07-16 02:38:28 - cd /src TB --- 2011-07-16 02:38:28 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Jul 16 02:38:29 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Jul 16 03:02:05 UTC 2011 TB --- 2011-07-16 03:02:05 - cd /src/sys/i386/conf TB --- 2011-07-16 03:02:05 - /usr/sbin/config -m PAE TB --- 2011-07-16 03:02:05 - building PAE kernel TB --- 2011-07-16 03:02:05 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 03:02:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 03:02:05 - TARGET=i386 TB --- 2011-07-16 03:02:05 - TARGET_ARCH=i386 TB --- 2011-07-16 03:02:05 - TZ=UTC TB --- 2011-07-16 03:02:05 - __MAKE_CONF=/dev/null TB --- 2011-07-16 03:02:05 - cd /src TB --- 2011-07-16 03:02:05 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Jul 16 03:02:05 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sat Jul 16 03:08:15 UTC 2011 TB --- 2011-07-16 03:08:16 - cd /src/sys/i386/conf TB --- 2011-07-16 03:08:16 - /usr/sbin/config -m XBOX TB --- 2011-07-16 03:08:16 - building XBOX kernel TB --- 2011-07-16 03:08:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 03:08:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 03:08:16 - TARGET=i386 TB --- 2011-07-16 03:08:16 - TARGET_ARCH=i386 TB --- 2011-07-16 03:08:16 - TZ=UTC TB --- 2011-07-16 03:08:16 - __MAKE_CONF=/dev/null TB --- 2011-07-16 03:08:16 - cd /src TB --- 2011-07-16 03:08:16 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sat Jul 16 03:08:16 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Sat Jul 16 03:11:26 UTC 2011 TB --- 2011-07-16 03:11:26 - cd /src/sys/i386/conf TB --- 2011-07-16 03:11:26 - /usr/sbin/config -m XEN TB --- 2011-07-16 03:11:26 - building XEN kernel TB --- 2011-07-16 03:11:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 03:11:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 03:11:26 - TARGET=i386 TB --- 2011-07-16 03:11:26 - TARGET_ARCH=i386 TB --- 2011-07-16 03:11:26 - TZ=UTC TB --- 2011-07-16 03:11:26 - __MAKE_CONF=/dev/null TB --- 2011-07-16 03:11:26 - cd /src TB --- 2011-07-16 03:11:26 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat Jul 16 03:11:26 UTC 2011 >>> 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 -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/xen/xen_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/mem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/minidump_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/mp_clock.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/xen/mp_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/xen/mptable.c In file included from /src/sys/i386/xen/mptable.c:41: ./x86/mptable.h:196: error: field 'sc_host_res' has incomplete type *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-16 03:16:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-16 03:16:32 - ERROR: failed to build XEN kernel TB --- 2011-07-16 03:16:32 - 8794.65 user 1635.56 system 11191.69 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 08:03:21 2011 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 A4E2D106564A; Sat, 16 Jul 2011 08:03:21 +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 666638FC0A; Sat, 16 Jul 2011 08:03:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6G83KYu061213; Sat, 16 Jul 2011 04:03:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6G83Kkr061208; Sat, 16 Jul 2011 08:03:20 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Jul 2011 08:03:20 GMT Message-Id: <201107160803.p6G83Kkr061208@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 i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 08:03:21 -0000 TB --- 2011-07-16 05:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-16 05:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-07-16 05:50:00 - cleaning the object tree TB --- 2011-07-16 05:50:28 - cvsupping the source tree TB --- 2011-07-16 05:50:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-07-16 05:50:50 - building world TB --- 2011-07-16 05:50:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 05:50:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 05:50:50 - TARGET=pc98 TB --- 2011-07-16 05:50:50 - TARGET_ARCH=i386 TB --- 2011-07-16 05:50:50 - TZ=UTC TB --- 2011-07-16 05:50:50 - __MAKE_CONF=/dev/null TB --- 2011-07-16 05:50:50 - cd /src TB --- 2011-07-16 05:50:50 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 16 05:50:51 UTC 2011 >>> 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 Sat Jul 16 07:48:24 UTC 2011 TB --- 2011-07-16 07:48:24 - generating LINT kernel config TB --- 2011-07-16 07:48:24 - cd /src/sys/pc98/conf TB --- 2011-07-16 07:48:24 - /usr/bin/make -B LINT TB --- 2011-07-16 07:48:24 - building LINT kernel TB --- 2011-07-16 07:48:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 07:48:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 07:48:24 - TARGET=pc98 TB --- 2011-07-16 07:48:24 - TARGET_ARCH=i386 TB --- 2011-07-16 07:48:24 - TZ=UTC TB --- 2011-07-16 07:48:24 - __MAKE_CONF=/dev/null TB --- 2011-07-16 07:48:24 - cd /src TB --- 2011-07-16 07:48:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 16 07:48:24 UTC 2011 >>> 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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/busdma_machdep.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/dump_machdep.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/io_apic.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/local_apic.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/mca.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/mptable.c cc1: warnings being treated as errors /src/sys/x86/x86/mptable.c:446: warning: 'mptable_walk_extended_table' defined but not used *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-16 08:03:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-16 08:03:20 - ERROR: failed to build lint kernel TB --- 2011-07-16 08:03:20 - 6266.91 user 1175.31 system 7999.56 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 08:56:52 2011 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 D86BE106564A; Sat, 16 Jul 2011 08:56:52 +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 918378FC14; Sat, 16 Jul 2011 08:56:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6G8upd7071941; Sat, 16 Jul 2011 04:56:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6G8upWV071912; Sat, 16 Jul 2011 08:56:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Jul 2011 08:56:51 GMT Message-Id: <201107160856.p6G8upWV071912@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 i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 08:56:53 -0000 TB --- 2011-07-16 05:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-16 05:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-07-16 05:50:00 - cleaning the object tree TB --- 2011-07-16 05:50:42 - cvsupping the source tree TB --- 2011-07-16 05:50:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-07-16 05:50:55 - building world TB --- 2011-07-16 05:50:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 05:50:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 05:50:55 - TARGET=i386 TB --- 2011-07-16 05:50:55 - TARGET_ARCH=i386 TB --- 2011-07-16 05:50:55 - TZ=UTC TB --- 2011-07-16 05:50:55 - __MAKE_CONF=/dev/null TB --- 2011-07-16 05:50:55 - cd /src TB --- 2011-07-16 05:50:55 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 16 05:50:56 UTC 2011 >>> 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 Sat Jul 16 07:48:38 UTC 2011 TB --- 2011-07-16 07:48:38 - generating LINT kernel config TB --- 2011-07-16 07:48:38 - cd /src/sys/i386/conf TB --- 2011-07-16 07:48:38 - /usr/bin/make -B LINT TB --- 2011-07-16 07:48:39 - building LINT kernel TB --- 2011-07-16 07:48:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 07:48:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 07:48:39 - TARGET=i386 TB --- 2011-07-16 07:48:39 - TARGET_ARCH=i386 TB --- 2011-07-16 07:48:39 - TZ=UTC TB --- 2011-07-16 07:48:39 - __MAKE_CONF=/dev/null TB --- 2011-07-16 07:48:39 - cd /src TB --- 2011-07-16 07:48:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 16 07:48:39 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jul 16 08:18:32 UTC 2011 TB --- 2011-07-16 08:18:32 - cd /src/sys/i386/conf TB --- 2011-07-16 08:18:32 - /usr/sbin/config -m GENERIC TB --- 2011-07-16 08:18:32 - building GENERIC kernel TB --- 2011-07-16 08:18:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 08:18:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 08:18:32 - TARGET=i386 TB --- 2011-07-16 08:18:32 - TARGET_ARCH=i386 TB --- 2011-07-16 08:18:32 - TZ=UTC TB --- 2011-07-16 08:18:32 - __MAKE_CONF=/dev/null TB --- 2011-07-16 08:18:32 - cd /src TB --- 2011-07-16 08:18:32 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Jul 16 08:18:32 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Jul 16 08:41:56 UTC 2011 TB --- 2011-07-16 08:41:56 - cd /src/sys/i386/conf TB --- 2011-07-16 08:41:56 - /usr/sbin/config -m PAE TB --- 2011-07-16 08:41:57 - building PAE kernel TB --- 2011-07-16 08:41:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 08:41:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 08:41:57 - TARGET=i386 TB --- 2011-07-16 08:41:57 - TARGET_ARCH=i386 TB --- 2011-07-16 08:41:57 - TZ=UTC TB --- 2011-07-16 08:41:57 - __MAKE_CONF=/dev/null TB --- 2011-07-16 08:41:57 - cd /src TB --- 2011-07-16 08:41:57 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Jul 16 08:41:57 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sat Jul 16 08:48:36 UTC 2011 TB --- 2011-07-16 08:48:38 - cd /src/sys/i386/conf TB --- 2011-07-16 08:48:38 - /usr/sbin/config -m XBOX TB --- 2011-07-16 08:48:42 - building XBOX kernel TB --- 2011-07-16 08:48:42 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 08:48:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 08:48:42 - TARGET=i386 TB --- 2011-07-16 08:48:42 - TARGET_ARCH=i386 TB --- 2011-07-16 08:48:42 - TZ=UTC TB --- 2011-07-16 08:48:42 - __MAKE_CONF=/dev/null TB --- 2011-07-16 08:48:42 - cd /src TB --- 2011-07-16 08:48:42 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sat Jul 16 08:48:43 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Sat Jul 16 08:51:46 UTC 2011 TB --- 2011-07-16 08:51:46 - cd /src/sys/i386/conf TB --- 2011-07-16 08:51:46 - /usr/sbin/config -m XEN TB --- 2011-07-16 08:51:46 - building XEN kernel TB --- 2011-07-16 08:51:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 08:51:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 08:51:46 - TARGET=i386 TB --- 2011-07-16 08:51:46 - TARGET_ARCH=i386 TB --- 2011-07-16 08:51:46 - TZ=UTC TB --- 2011-07-16 08:51:46 - __MAKE_CONF=/dev/null TB --- 2011-07-16 08:51:46 - cd /src TB --- 2011-07-16 08:51:46 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat Jul 16 08:51:46 UTC 2011 >>> 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 -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/xen/xen_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/mem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/minidump_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/mp_clock.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/xen/mp_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/xen/mptable.c In file included from /src/sys/i386/xen/mptable.c:41: ./x86/mptable.h:196: error: field 'sc_host_res' has incomplete type *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-16 08:56:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-16 08:56:51 - ERROR: failed to build XEN kernel TB --- 2011-07-16 08:56:51 - 8765.30 user 1638.19 system 11210.76 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 09:26:49 2011 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 2563E1065677; Sat, 16 Jul 2011 09:26:49 +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 E3DCF8FC0C; Sat, 16 Jul 2011 09:26:48 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 61EE68B8E1; Sat, 16 Jul 2011 11:26:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <4E20FADE.6060103@missouri.edu> Date: Sat, 16 Jul 2011 11:26:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E20FADE.6060103@missouri.edu> To: Stephen Montgomery-Smith X-Mailer: Apple Mail (2.1084) Cc: freebsd@sopwith.solgatos.com, current@freebsd.org, bug-followup@freebsd.org Subject: Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(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: Sat, 16 Jul 2011 09:26:49 -0000 Am 16.07.2011 um 04:43 schrieb Stephen Montgomery-Smith: > I was looking through the source code of pkg_add. Personally I don't = see how the "-P" or "-p" option could be made to work with pkg_add. Many = of the installation commands involve scripts which have ${PREFIX} hard = coded into them. ${PREFIX} is often hard coded when trhe package is = created by the port. In my opinion, the options "-p" and "-P" should be = removed from pkg_add. >=20 > Either that, or provide the port a way to access "@cwd" in any scripts = it installs. But this would require a major overhaul of the whole ports = system, and probably much of the software it installs as well. >=20 > Am I missing something? Yes. Not honoring the prefix is a bug in the port. If you do need to = do prefix-specific things during install, use pkg-install, see = http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html I suspect that many ports are not well tested outside of "/usr/local", = but the infrastructure is there and available. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 09:34:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 610771065672; Sat, 16 Jul 2011 09:34:45 +0000 (UTC) Date: Sat, 16 Jul 2011 09:34:45 +0000 From: Alexander Best To: John Baldwin Message-ID: <20110716093445.GA15357@freebsd.org> References: <201107151343.40065.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107151343.40065.jhb@freebsd.org> Cc: current@freebsd.org Subject: Re: [PATCH] Export per-thread resource usage via sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2011 09:34:45 -0000 On Fri Jul 15 11, John Baldwin wrote: > This change exports each individual thread's resource usage via sysctl when > individual threads are requested via KERN_PROC_INC_THREAD. This generally > works correctly with 'top -m io' after the previous change to revert top(1) > back to using KERN_PROC_PROC when threads are not enabled. There is one issue > in that top doesn't necessarily DTRT when disabling/enabling threads via 'H' > at runtime while in io mode. I may do some further work to clean that up. > However, for just top run it will now show per-thread stats instead of > duplicating the per-process stats for each thread. i'm not sure, if i understand what the patch is supposed to do. however after applying it, and recompiling/reinstalling the kernel, 'top -mio' displays the same stats for each thread of a process. if i understood you correctly, each thread should have individual stats. i'm running r224068 on amd64 and just reinstalled 'top'. anything i am missing? cheers. alex > > It also fixes a bug in that the code in calcru() to try to account for the > current thread's runtime wasn't correctly accounting charging that time to > the current thread. > > Index: sys/kern/kern_proc.c > =================================================================== > --- sys/kern/kern_proc.c (revision 224058) > +++ sys/kern/kern_proc.c (working copy) > @@ -848,6 +848,8 @@ > kp->ki_tdaddr = td; > PROC_LOCK_ASSERT(p, MA_OWNED); > > + if (preferthread) > + PROC_SLOCK(p); > thread_lock(td); > if (td->td_wmesg != NULL) > strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki_wmesg)); > @@ -899,6 +901,7 @@ > kp->ki_pri.pri_user = td->td_user_pri; > > if (preferthread) { > + rufetchtd(td, &kp->ki_rusage); > kp->ki_runtime = cputick2usec(td->td_rux.rux_runtime); > kp->ki_pctcpu = sched_pctcpu(td); > kp->ki_estcpu = td->td_estcpu; > @@ -911,6 +914,8 @@ > kp->ki_siglist = td->td_siglist; > kp->ki_sigmask = td->td_sigmask; > thread_unlock(td); > + if (preferthread) > + PROC_SUNLOCK(p); > } > > /* > Index: sys/kern/kern_resource.c > =================================================================== > --- sys/kern/kern_resource.c (revision 224058) > +++ sys/kern/kern_resource.c (working copy) > @@ -813,7 +813,7 @@ > calcru(struct proc *p, struct timeval *up, struct timeval *sp) > { > struct thread *td; > - uint64_t u; > + uint64_t runtime, u; > > PROC_LOCK_ASSERT(p, MA_OWNED); > PROC_SLOCK_ASSERT(p, MA_OWNED); > @@ -826,7 +826,9 @@ > td = curthread; > if (td->td_proc == p) { > u = cpu_ticks(); > - p->p_rux.rux_runtime += u - PCPU_GET(switchtime); > + runtime = u - PCPU_GET(switchtime); > + td->td_runtime += runtime; > + td->td_incruntime += runtime; > PCPU_SET(switchtime, u); > } > /* Make sure the per-thread stats are current. */ > @@ -838,6 +840,34 @@ > calcru1(p, &p->p_rux, up, sp); > } > > +/* Collect resource usage for a single thread. */ > +void > +rufetchtd(struct thread *td, struct rusage *ru) > +{ > + struct proc *p; > + uint64_t runtime, u; > + > + p = td->td_proc; > + PROC_SLOCK_ASSERT(p, MA_OWNED); > + THREAD_LOCK_ASSERT(td, MA_OWNED); > + /* > + * If we are getting stats for the current thread, then add in the > + * stats that this thread has accumulated in its current time slice. > + * We reset the thread and CPU state as if we had performed a context > + * switch right here. > + */ > + if (td == curthread) { > + u = cpu_ticks(); > + runtime = u - PCPU_GET(switchtime); > + td->td_runtime += runtime; > + td->td_incruntime += runtime; > + PCPU_SET(switchtime, u); > + } > + ruxagg(p, td); > + *ru = td->td_ru; > + calcru1(p, &td->td_rux, &ru->ru_utime, &ru->ru_stime); > +} > + > static void > calcru1(struct proc *p, struct rusage_ext *ruxp, struct timeval *up, > struct timeval *sp) > @@ -955,12 +985,10 @@ > > case RUSAGE_THREAD: > PROC_SLOCK(p); > - ruxagg(p, td); > - PROC_SUNLOCK(p); > thread_lock(td); > - *rup = td->td_ru; > - calcru1(p, &td->td_rux, &rup->ru_utime, &rup->ru_stime); > + rufetchtd(td, rup); > thread_unlock(td); > + PROC_SUNLOCK(p); > break; > > default: > Index: sys/sys/resourcevar.h > =================================================================== > --- sys/sys/resourcevar.h (revision 224058) > +++ sys/sys/resourcevar.h (working copy) > @@ -136,6 +136,7 @@ > void rufetch(struct proc *p, struct rusage *ru); > void rufetchcalc(struct proc *p, struct rusage *ru, struct timeval *up, > struct timeval *sp); > +void rufetchtd(struct thread *td, struct rusage *ru); > void ruxagg(struct proc *p, struct thread *td); > int suswintr(void *base, int word); > struct uidinfo > > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 11:42:53 2011 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 A0241106564A; Sat, 16 Jul 2011 11:42:53 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0395C8FC12; Sat, 16 Jul 2011 11:42:52 +0000 (UTC) Received: by fxe6 with SMTP id 6so3093381fxe.17 for ; Sat, 16 Jul 2011 04:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; bh=2ItImmKpt0N/AU8vVGvrJ7n0HEFCQSW+7ov4Qr2FAh0=; b=Ongw4eAMZtSSX910D+L1HNy0C7E9KUbr2/YSukH/tWLhHkhff+WVPu/pwkTGZZS2uk EimbpUWn5N0b2VI3W3CHufnbKpoPrrwFowjtVexH1gO/2tQVGtSKPgu978K/0yGhjb3u KRGR0XHWE2Egm544t3KPYkc+enPJNgGI+SLLM= Received: by 10.223.98.88 with SMTP id p24mr2543132fan.72.1310814994414; Sat, 16 Jul 2011 04:16:34 -0700 (PDT) Received: from localhost (tor-exit-router35-readme.formlessnetworking.net [199.48.147.35]) by mx.google.com with ESMTPS id 9sm1416640far.13.2011.07.16.04.16.31 (version=SSLv3 cipher=OTHER); Sat, 16 Jul 2011 04:16:33 -0700 (PDT) From: Pan Tsu To: Alexander Best References: <201107151343.40065.jhb@freebsd.org> <20110716093445.GA15357@freebsd.org> Date: Sat, 16 Jul 2011 15:16:20 +0400 Message-ID: <864o2mfpbv.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: current@freebsd.org Subject: Re: [PATCH] Export per-thread resource usage via sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2011 11:42:53 -0000 Alexander Best writes: > On Fri Jul 15 11, John Baldwin wrote: >> This change exports each individual thread's resource usage via sysctl when >> individual threads are requested via KERN_PROC_INC_THREAD. This generally >> works correctly with 'top -m io' after the previous change to revert top(1) >> back to using KERN_PROC_PROC when threads are not enabled. There is one issue >> in that top doesn't necessarily DTRT when disabling/enabling threads via 'H' >> at runtime while in io mode. I may do some further work to clean that up. >> However, for just top run it will now show per-thread stats instead of >> duplicating the per-process stats for each thread. > > i'm not sure, if i understand what the patch is supposed to do. however after > applying it, and recompiling/reinstalling the kernel, 'top -mio' displays the > same stats for each thread of a process. if i understood you correctly, each > thread should have individual stats. > > i'm running r224068 on amd64 and just reinstalled 'top'. anything i am missing? FWIW, I see different numbers for a few threads of firefox-bin with top-3.8b1. http://img233.imageshack.us/img233/1570/81482202.png Which is an improvement compared to how all threads showed same numbers before applying the patch. From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 11:55:39 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 66983106566B for ; Sat, 16 Jul 2011 11:55:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id F36E9150774 for ; Sat, 16 Jul 2011 11:55:37 +0000 (UTC) Message-ID: <4E217C38.2000505@FreeBSD.org> Date: Sat, 16 Jul 2011 04:55:36 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: HEADS UP: BIND 9.8 imported 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, 16 Jul 2011 11:55:39 -0000 Howdy, I wanted to let everyone know that BIND 9.8.0-P4 has just been imported to 9-current, and will be part of the 9.0-RELEASE. The 9.8 branch has many nice new features vs. 9.6.x, especially in the area of DNSSEC. You can read more about the new features in the README file included in /usr/share/doc/bind9. I also encourage you to browse through the ARM, either in HTML or PDF format as there are other interesting features for both authoritative and resolving name servers. The good news is that zone files and server configurations that work with BIND 9.6.x should work without modification in 9.8.x so migration should be painless. If you have any problems or questions feel free to follow up here on -current. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 12:00:39 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EAF51065726; Sat, 16 Jul 2011 12:00:39 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9EB8B8FC14; Sat, 16 Jul 2011 12:00:38 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F2F6A40002; Sat, 16 Jul 2011 14:00:37 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E7D4C4000D; Sat, 16 Jul 2011 14:00:37 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,FREEMAIL_FROM autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id C341640002; Sat, 16 Jul 2011 14:00:37 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 906E2119C08; Sat, 16 Jul 2011 14:00:37 +0200 (CEST) Received: from [IPv6:2001:470:dca9:1::4] (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 6FEE012B1E5; Sat, 16 Jul 2011 14:00:37 +0200 (CEST) Message-ID: <4E217D62.50000@gmail.com> Date: Sat, 16 Jul 2011 14:00:34 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Doug Barton References: <4E217C38.2000505@FreeBSD.org> In-Reply-To: <4E217C38.2000505@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@FreeBSD.org Subject: Re: HEADS UP: BIND 9.8 imported 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, 16 Jul 2011 12:00:39 -0000 On 2011-07-16 13:55, Doug Barton wrote: > Howdy, > > I wanted to let everyone know that BIND 9.8.0-P4 has just been imported > to 9-current, and will be part of the 9.0-RELEASE. The 9.8 branch has > many nice new features vs. 9.6.x, especially in the area of DNSSEC. You > can read more about the new features in the README file included in > /usr/share/doc/bind9. I also encourage you to browse through the ARM, > either in HTML or PDF format as there are other interesting features for > both authoritative and resolving name servers. > > The good news is that zone files and server configurations that work > with BIND 9.6.x should work without modification in 9.8.x so migration > should be painless. > > If you have any problems or questions feel free to follow up here on > -current. > > > Doug > Awesome! -- Niclas Z From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 12:04:58 2011 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D84C91065672; Sat, 16 Jul 2011 12:04:58 +0000 (UTC) Date: Sat, 16 Jul 2011 12:04:58 +0000 From: Alexander Best To: Pan Tsu Message-ID: <20110716120458.GA30855@freebsd.org> References: <201107151343.40065.jhb@freebsd.org> <20110716093445.GA15357@freebsd.org> <864o2mfpbv.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <864o2mfpbv.fsf@gmail.com> Cc: current@freebsd.org Subject: Re: [PATCH] Export per-thread resource usage via sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2011 12:04:58 -0000 On Sat Jul 16 11, Pan Tsu wrote: > Alexander Best writes: > > > On Fri Jul 15 11, John Baldwin wrote: > >> This change exports each individual thread's resource usage via sysctl when > >> individual threads are requested via KERN_PROC_INC_THREAD. This generally > >> works correctly with 'top -m io' after the previous change to revert top(1) > >> back to using KERN_PROC_PROC when threads are not enabled. There is one issue > >> in that top doesn't necessarily DTRT when disabling/enabling threads via 'H' > >> at runtime while in io mode. I may do some further work to clean that up. > >> However, for just top run it will now show per-thread stats instead of > >> duplicating the per-process stats for each thread. > > > > i'm not sure, if i understand what the patch is supposed to do. however after > > applying it, and recompiling/reinstalling the kernel, 'top -mio' displays the > > same stats for each thread of a process. if i understood you correctly, each > > thread should have individual stats. > > > > i'm running r224068 on amd64 and just reinstalled 'top'. anything i am missing? > > FWIW, I see different numbers for a few threads of firefox-bin with top-3.8b1. > > http://img233.imageshack.us/img233/1570/81482202.png > > Which is an improvement compared to how all threads showed same numbers > before applying the patch. hmmm...not here. i did the following: 'top -mio -b -H -d2 999999' and had a look at the second output, where if found these lines: [...] 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) 2015 1001 61 8 0 0 1 1 3.70% chromium-browser: (chrome) [...] 2068 1001 383 137 0 0 0 0 0.00% /usr/local/jdk1.6.0/bin/java -Xmx512m -jar JDownloader.jar 2068 1001 383 137 0 0 0 0 0.00% /usr/local/jdk1.6.0/bin/java -Xmx512m -jar JDownloader.jar [...] the first output seems to behave similar: [...] 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon 1881 0 656 68 15 0 41 56 0.00% /usr/local/sbin/console-kit-daemon --no-daemon [...] cheers. alex From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 13:42:21 2011 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 54EB4106566B; Sat, 16 Jul 2011 13:42:21 +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 14F518FC12; Sat, 16 Jul 2011 13:42:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6GDgJ1u033209; Sat, 16 Jul 2011 09:42:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6GDgJNT033180; Sat, 16 Jul 2011 13:42:19 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Jul 2011 13:42:19 GMT Message-Id: <201107161342.p6GDgJNT033180@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 i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 13:42:21 -0000 TB --- 2011-07-16 11:30:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-16 11:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-07-16 11:30:00 - cleaning the object tree TB --- 2011-07-16 11:30:26 - cvsupping the source tree TB --- 2011-07-16 11:30:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-07-16 11:30:58 - building world TB --- 2011-07-16 11:30:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 11:30:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 11:30:58 - TARGET=pc98 TB --- 2011-07-16 11:30:58 - TARGET_ARCH=i386 TB --- 2011-07-16 11:30:58 - TZ=UTC TB --- 2011-07-16 11:30:58 - __MAKE_CONF=/dev/null TB --- 2011-07-16 11:30:58 - cd /src TB --- 2011-07-16 11:30:58 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 16 11:30:59 UTC 2011 >>> 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 Sat Jul 16 13:27:21 UTC 2011 TB --- 2011-07-16 13:27:21 - generating LINT kernel config TB --- 2011-07-16 13:27:21 - cd /src/sys/pc98/conf TB --- 2011-07-16 13:27:21 - /usr/bin/make -B LINT TB --- 2011-07-16 13:27:21 - building LINT kernel TB --- 2011-07-16 13:27:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 13:27:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 13:27:21 - TARGET=pc98 TB --- 2011-07-16 13:27:21 - TARGET_ARCH=i386 TB --- 2011-07-16 13:27:21 - TZ=UTC TB --- 2011-07-16 13:27:21 - __MAKE_CONF=/dev/null TB --- 2011-07-16 13:27:21 - cd /src TB --- 2011-07-16 13:27:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 16 13:27:21 UTC 2011 >>> 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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/busdma_machdep.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/dump_machdep.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/io_apic.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/local_apic.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/mca.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 -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/x86/x86/mptable.c cc1: warnings being treated as errors /src/sys/x86/x86/mptable.c:446: warning: 'mptable_walk_extended_table' defined but not used *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-16 13:42:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-16 13:42:19 - ERROR: failed to build lint kernel TB --- 2011-07-16 13:42:19 - 6241.81 user 1175.96 system 7938.32 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 14:35:09 2011 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 2FDB2106564A; Sat, 16 Jul 2011 14:35:09 +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 DEEC98FC18; Sat, 16 Jul 2011 14:35:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6GEZ8Ib046321; Sat, 16 Jul 2011 10:35:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6GEZ8Y5046290; Sat, 16 Jul 2011 14:35:08 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Jul 2011 14:35:08 GMT Message-Id: <201107161435.p6GEZ8Y5046290@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 i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 14:35:09 -0000 TB --- 2011-07-16 11:30:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-16 11:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-07-16 11:30:00 - cleaning the object tree TB --- 2011-07-16 11:30:39 - cvsupping the source tree TB --- 2011-07-16 11:30:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-07-16 11:30:58 - building world TB --- 2011-07-16 11:30:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 11:30:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 11:30:58 - TARGET=i386 TB --- 2011-07-16 11:30:58 - TARGET_ARCH=i386 TB --- 2011-07-16 11:30:58 - TZ=UTC TB --- 2011-07-16 11:30:58 - __MAKE_CONF=/dev/null TB --- 2011-07-16 11:30:58 - cd /src TB --- 2011-07-16 11:30:58 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 16 11:30:59 UTC 2011 >>> 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 Sat Jul 16 13:27:49 UTC 2011 TB --- 2011-07-16 13:27:49 - generating LINT kernel config TB --- 2011-07-16 13:27:49 - cd /src/sys/i386/conf TB --- 2011-07-16 13:27:49 - /usr/bin/make -B LINT TB --- 2011-07-16 13:27:49 - building LINT kernel TB --- 2011-07-16 13:27:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 13:27:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 13:27:49 - TARGET=i386 TB --- 2011-07-16 13:27:49 - TARGET_ARCH=i386 TB --- 2011-07-16 13:27:49 - TZ=UTC TB --- 2011-07-16 13:27:49 - __MAKE_CONF=/dev/null TB --- 2011-07-16 13:27:49 - cd /src TB --- 2011-07-16 13:27:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 16 13:27:49 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jul 16 13:57:45 UTC 2011 TB --- 2011-07-16 13:57:45 - cd /src/sys/i386/conf TB --- 2011-07-16 13:57:45 - /usr/sbin/config -m GENERIC TB --- 2011-07-16 13:57:45 - building GENERIC kernel TB --- 2011-07-16 13:57:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 13:57:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 13:57:45 - TARGET=i386 TB --- 2011-07-16 13:57:45 - TARGET_ARCH=i386 TB --- 2011-07-16 13:57:45 - TZ=UTC TB --- 2011-07-16 13:57:45 - __MAKE_CONF=/dev/null TB --- 2011-07-16 13:57:45 - cd /src TB --- 2011-07-16 13:57:45 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Jul 16 13:57:45 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Jul 16 14:20:49 UTC 2011 TB --- 2011-07-16 14:20:49 - cd /src/sys/i386/conf TB --- 2011-07-16 14:20:49 - /usr/sbin/config -m PAE TB --- 2011-07-16 14:20:49 - building PAE kernel TB --- 2011-07-16 14:20:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 14:20:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 14:20:49 - TARGET=i386 TB --- 2011-07-16 14:20:49 - TARGET_ARCH=i386 TB --- 2011-07-16 14:20:49 - TZ=UTC TB --- 2011-07-16 14:20:49 - __MAKE_CONF=/dev/null TB --- 2011-07-16 14:20:49 - cd /src TB --- 2011-07-16 14:20:49 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Jul 16 14:20:49 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sat Jul 16 14:27:00 UTC 2011 TB --- 2011-07-16 14:27:00 - cd /src/sys/i386/conf TB --- 2011-07-16 14:27:00 - /usr/sbin/config -m XBOX TB --- 2011-07-16 14:27:00 - building XBOX kernel TB --- 2011-07-16 14:27:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 14:27:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 14:27:00 - TARGET=i386 TB --- 2011-07-16 14:27:00 - TARGET_ARCH=i386 TB --- 2011-07-16 14:27:00 - TZ=UTC TB --- 2011-07-16 14:27:00 - __MAKE_CONF=/dev/null TB --- 2011-07-16 14:27:00 - cd /src TB --- 2011-07-16 14:27:00 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sat Jul 16 14:27:00 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Sat Jul 16 14:30:04 UTC 2011 TB --- 2011-07-16 14:30:04 - cd /src/sys/i386/conf TB --- 2011-07-16 14:30:04 - /usr/sbin/config -m XEN TB --- 2011-07-16 14:30:04 - building XEN kernel TB --- 2011-07-16 14:30:04 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 14:30:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 14:30:04 - TARGET=i386 TB --- 2011-07-16 14:30:04 - TARGET_ARCH=i386 TB --- 2011-07-16 14:30:04 - TZ=UTC TB --- 2011-07-16 14:30:04 - __MAKE_CONF=/dev/null TB --- 2011-07-16 14:30:04 - cd /src TB --- 2011-07-16 14:30:04 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat Jul 16 14:30:04 UTC 2011 >>> 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 -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/xen/xen_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/mem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/minidump_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/mp_clock.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/xen/mp_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/xen/mptable.c In file included from /src/sys/i386/xen/mptable.c:41: ./x86/mptable.h:196: error: field 'sc_host_res' has incomplete type *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-16 14:35:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-16 14:35:07 - ERROR: failed to build XEN kernel TB --- 2011-07-16 14:35:07 - 8714.97 user 1631.60 system 11106.63 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 15:37:55 2011 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 BA0651065672; Sat, 16 Jul 2011 15:37:55 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 816338FC0A; Sat, 16 Jul 2011 15:37:55 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.4/8.14.4) with ESMTP id p6GFbrAo073668; Sat, 16 Jul 2011 10:37:54 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4E21B051.5040502@missouri.edu> Date: Sat, 16 Jul 2011 10:37:53 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stefan Bethke References: <4E20FADE.6060103@missouri.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd@sopwith.solgatos.com" , "current@freebsd.org" , "bug-followup@freebsd.org" Subject: Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(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: Sat, 16 Jul 2011 15:37:55 -0000 On 07/16/2011 04:26 AM, Stefan Bethke wrote: > Am 16.07.2011 um 04:43 schrieb Stephen Montgomery-Smith: > >> I was looking through the source code of pkg_add. Personally I don't see how the "-P" or "-p" option could be made to work with pkg_add. Many of the installation commands involve scripts which have ${PREFIX} hard coded into them. ${PREFIX} is often hard coded when trhe package is created by the port. In my opinion, the options "-p" and "-P" should be removed from pkg_add. >> >> Either that, or provide the port a way to access "@cwd" in any scripts it installs. But this would require a major overhaul of the whole ports system, and probably much of the software it installs as well. >> >> Am I missing something? > > Yes. Not honoring the prefix is a bug in the port. If you do need to do prefix-specific things during install, use pkg-install, see http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html > > I suspect that many ports are not well tested outside of "/usr/local", but the infrastructure is there and available. You are correct, this needs to be done on a port by port basis. In some ports this is going to be a big job, because in some cases the "/usr/local" is hard coded into certain binaries. For example, suppose the C source code contains something like: char applications_dir = "/usr/local/share/applications"; and this is filled in by the ./configure script. How is that handled? From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 15:53:50 2011 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 B9EC1106566C; Sat, 16 Jul 2011 15:53:50 +0000 (UTC) (envelope-from utisoft@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 7351C8FC12; Sat, 16 Jul 2011 15:53:50 +0000 (UTC) Received: by iwr19 with SMTP id 19so2380288iwr.13 for ; Sat, 16 Jul 2011 08:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zyxtn8QcB0Yqa0YnPKVRTysNXz3JGEsnuukJZieo9yo=; b=ErBht7SeQWL2cgi3/pFn4PrkP+99ojf/mA3OODAyWsulif/8h2asS57buAzTV3g40m Tlld8E8nh5Xc3DTDt95IGawtqjvueTi87VBMqWyvM42eNG5od5B6WsF1K16yAwB4QthE kaKCNGpuUK1Juxu+x/mZAPoqb2b1plMSJHsFo= MIME-Version: 1.0 Received: by 10.231.118.18 with SMTP id t18mr4213486ibq.60.1310831629204; Sat, 16 Jul 2011 08:53:49 -0700 (PDT) Received: by 10.231.67.211 with HTTP; Sat, 16 Jul 2011 08:53:49 -0700 (PDT) Received: by 10.231.67.211 with HTTP; Sat, 16 Jul 2011 08:53:49 -0700 (PDT) In-Reply-To: <4E21B051.5040502@missouri.edu> References: <4E20FADE.6060103@missouri.edu> <4E21B051.5040502@missouri.edu> Date: Sat, 16 Jul 2011 16:53:49 +0100 Message-ID: From: Chris Rees To: Stephen Montgomery-Smith X-Mailman-Approved-At: Sat, 16 Jul 2011 16:00:19 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd@sopwith.solgatos.com" , "current@freebsd.org" , "bug-followup@freebsd.org" , Stefan Bethke Subject: Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(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: Sat, 16 Jul 2011 15:53:50 -0000 On 16 Jul 2011 16:38, "Stephen Montgomery-Smith" wrote: > > On 07/16/2011 04:26 AM, Stefan Bethke wrote: >> >> Am 16.07.2011 um 04:43 schrieb Stephen Montgomery-Smith: >> >>> I was looking through the source code of pkg_add. Personally I don't see how the "-P" or "-p" option could be made to work with pkg_add. Many of the installation commands involve scripts which have ${PREFIX} hard coded into them. ${PREFIX} is often hard coded when trhe package is created by the port. In my opinion, the options "-p" and "-P" should be removed from pkg_add. >>> >>> Either that, or provide the port a way to access "@cwd" in any scripts it installs. But this would require a major overhaul of the whole ports system, and probably much of the software it installs as well. >>> >>> Am I missing something? >> >> >> Yes. Not honoring the prefix is a bug in the port. If you do need to do prefix-specific things during install, use pkg-install, see http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html >> >> I suspect that many ports are not well tested outside of "/usr/local", but the infrastructure is there and available. > > > You are correct, this needs to be done on a port by port basis. In some ports this is going to be a big job, because in some cases the "/usr/local" is hard coded into certain binaries. > > For example, suppose the C source code contains something like: > char applications_dir = "/usr/local/share/applications"; > and this is filled in by the ./configure script. > > How is that handled? > It's not. Remember what a package is, literally the files from the plist tarred with some magic +FILEs and the pkg-*install files- if paths are hardcoded in objects that's how it'll be installed. Don't touch the -p option! It's only useful for.... um.... someone help here? Chris From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 16:04:50 2011 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 942231065780; Sat, 16 Jul 2011 16:04:50 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 405D18FC08; Sat, 16 Jul 2011 16:04:50 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.4/8.14.4) with ESMTP id p6GG4miC073937; Sat, 16 Jul 2011 11:04:49 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4E21B6A0.6060908@missouri.edu> Date: Sat, 16 Jul 2011 11:04:48 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Chris Rees References: <4E20FADE.6060103@missouri.edu> <4E21B051.5040502@missouri.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd@sopwith.solgatos.com" , "current@freebsd.org" , "bug-followup@freebsd.org" , Stefan Bethke Subject: Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(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: Sat, 16 Jul 2011 16:04:50 -0000 On 07/16/2011 10:53 AM, Chris Rees wrote: > > On 16 Jul 2011 16:38, "Stephen Montgomery-Smith" > wrote: > > > > On 07/16/2011 04:26 AM, Stefan Bethke wrote: > >> > >> Am 16.07.2011 um 04:43 schrieb Stephen Montgomery-Smith: > >> > >>> I was looking through the source code of pkg_add. Personally I > don't see how the "-P" or "-p" option could be made to work with > pkg_add. Many of the installation commands involve scripts which have > ${PREFIX} hard coded into them. ${PREFIX} is often hard coded when trhe > package is created by the port. In my opinion, the options "-p" and > "-P" should be removed from pkg_add. > >>> > >>> Either that, or provide the port a way to access "@cwd" in any > scripts it installs. But this would require a major overhaul of the > whole ports system, and probably much of the software it installs as well. > >>> > >>> Am I missing something? > >> > >> > >> Yes. Not honoring the prefix is a bug in the port. If you do need > to do prefix-specific things during install, use pkg-install, see > http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html > >> > >> I suspect that many ports are not well tested outside of > "/usr/local", but the infrastructure is there and available. > > > > > > You are correct, this needs to be done on a port by port basis. In > some ports this is going to be a big job, because in some cases the > "/usr/local" is hard coded into certain binaries. > > > > For example, suppose the C source code contains something like: > > char applications_dir = "/usr/local/share/applications"; > > and this is filled in by the ./configure script. > > > > How is that handled? > > > > It's not. > > Remember what a package is, literally the files from the plist tarred > with some magic +FILEs and the pkg-*install files- if paths are > hardcoded in objects that's how it'll be installed. What if some of the installation programs are binaries, and "/usr/local" is hard coded into installation binaries or scripts provided by the software itself. > Don't touch the -p option! It's only useful for.... um.... someone help > here? I am thinking the same thing! From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 16:13:13 2011 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 2E571106566C; Sat, 16 Jul 2011 16:13:13 +0000 (UTC) (envelope-from utisoft@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 CB1F38FC08; Sat, 16 Jul 2011 16:13:12 +0000 (UTC) Received: by iwr19 with SMTP id 19so2390666iwr.13 for ; Sat, 16 Jul 2011 09:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=/Lj1crTw8sxUXPmd5j+n2Ho1CZrwremisMJqtZTsRvo=; b=YVWng1qvytWj4p2SUuMkMndVHkTDPPaqgZ8BNmMSrZS6T2O9tI6sDWtI+KGRAawB1i dqq8RZSRVBIAHZZU6glM4/VB9FObVkBhV5DIr73QylH1KtE1PNLP5rE1xiXk85E0luwC u8QgZ04sRmP7S86RqnmgYf6jZ/HQ8j53Zs6As= MIME-Version: 1.0 Received: by 10.231.92.196 with SMTP id s4mr4376188ibm.10.1310832792061; Sat, 16 Jul 2011 09:13:12 -0700 (PDT) Sender: utisoft@gmail.com Received: by 10.231.67.211 with HTTP; Sat, 16 Jul 2011 09:13:12 -0700 (PDT) Received: by 10.231.67.211 with HTTP; Sat, 16 Jul 2011 09:13:12 -0700 (PDT) In-Reply-To: References: <4E20FADE.6060103@missouri.edu> <4E21B051.5040502@missouri.edu> <4E21B6A0.6060908@missouri.edu> Date: Sat, 16 Jul 2011 17:13:12 +0100 X-Google-Sender-Auth: RO1SihIlZ2Lm2lYY2xro9N3HcJo Message-ID: From: Chris Rees To: "bug-followup@freebsd.org" , "current@freebsd.org" , "freebsd@sopwith.solgatos.com" , Stefan Bethke , Stephen Montgomery-Smith Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(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: Sat, 16 Jul 2011 16:13:13 -0000 On 16 Jul 2011 17:04, "Stephen Montgomery-Smith" wrote: > > On 07/16/2011 10:53 AM, Chris Rees wrote: >> >> >> On 16 Jul 2011 16:38, "Stephen Montgomery-Smith" > > wrote: >> > For example, suppose the C source code contains something like: >> > char applications_dir = "/usr/local/share/applications"; >> > and this is filled in by the ./configure script. >> > >> > How is that handled? >> > >> >> It's not. >> >> Remember what a package is, literally the files from the plist tarred >> with some magic +FILEs and the pkg-*install files- if paths are >> hardcoded in objects that's how it'll be installed. > > > What if some of the installation programs are binaries, and "/usr/local" is hard coded into installation binaries or scripts provided by the software itself. Sorry, poor wording on my part. If it was compiled as prefix=/usr/local, that's how it'll be installed, regardless of your -p argument. Chris From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 18:25:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDBF5106566B for ; Sat, 16 Jul 2011 18:25:22 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 30B8A8FC1C for ; Sat, 16 Jul 2011 18:25:21 +0000 (UTC) Received: by qyk30 with SMTP id 30so1038183qyk.13 for ; Sat, 16 Jul 2011 11:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ms8sOCbGX3lUWZcUFp2SkGtbm4qf/k63NrOFdORwIbU=; b=LlENYZTiJ3Md7dHmG3TmGVW21ItiUOsBhSV+fr+hD2GUKOCu/2PvZYWHa1/7B4xoGl z/TANgg8zYbV6KqtOzwompizOTBnsljGJfP+fpUJuI7X54hYvoekiE1txDt0SB7UEbOF GuRQ09smkh/qDb7BREVM/biM3DgiQmF9DmmIg= MIME-Version: 1.0 Received: by 10.229.184.6 with SMTP id ci6mr3537952qcb.202.1310840720964; Sat, 16 Jul 2011 11:25:20 -0700 (PDT) Received: by 10.229.240.141 with HTTP; Sat, 16 Jul 2011 11:25:20 -0700 (PDT) Date: Sat, 16 Jul 2011 14:25:20 -0400 Message-ID: From: Kim Culhan To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Interpreting MCA error output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2011 18:25:22 -0000 Noticed the following console message while running make world with 9.0-CURRENT on 7-16-11 Jul 16 11:15:20 delta kernel: MCA: Vendor "GenuineIntel", ID 0x106a5, APIC ID 16 Jul 16 11:15:20 delta kernel: MCA: CPU 8 COR (1) RD channel ?? memory error Jul 16 11:15:20 delta kernel: MCA: Address 0x28f261f80 Jul 16 11:15:20 delta kernel: MCA: Misc 0x1834958000001385 Jul 16 12:15:20 delta kernel: MCA: Bank 8, Status 0x8c0000400001009f Jul 16 12:15:20 delta kernel: MCA: Global Cap 0x0000000000001c09, Status 0x00000 00000000000 Jul 16 12:15:20 delta kernel: MCA: Vendor "GenuineIntel", ID 0x106a5, APIC ID 16 Jul 16 12:15:20 delta kernel: MCA: CPU 8 COR (1) RD channel ?? memory error Jul 16 12:15:20 delta kernel: MCA: Address 0x28e019f80 Jul 16 12:15:20 delta kernel: MCA: Misc 0x1834958000000588 This is with a Supermicro X8DTL-3F motherboard, dmidecode: # dmidecode 2.11 SMBIOS 2.6 present. 77 structures occupying 2976 bytes. Table at 0x0009CC00. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 1.0 Release Date: 04/10/2009 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 4096 kB Characteristics: ISA is supported PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 8.16 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Supermicro Product Name: X8DTL Version: 1234567890 Serial Number: 1234567890 UUID: 03000200-0400-0500-0006-000700080009 Wake-up Type: Power Switch SKU Number: To Be Filled By O.E.M. Family: Server Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: Supermicro Product Name: X8DTL Version: 1234567890 Serial Number: 1234567890 Asset Tag: To Be Filled By O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To Be Filled By O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: Supermicro Type: Main Server Chassis Lock: Not Present Version: 1234567890 Serial Number: 1234567890 Asset Tag: To Be Filled By O.E.M. Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 Handle 0x0004, DMI type 4, 42 bytes Processor Information Socket Designation: CPU 1 Type: Central Processor Family: Xeon Manufacturer: Intel ID: A5 06 01 00 FF FB EB BF Signature: Type 0, Family 6, Model 26, Stepping 5 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz Voltage: Unknown External Clock: 133 MHz Max Speed: 2266 MHz Current Speed: 2266 MHz Status: Populated, Enabled Upgrade: Other L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: 0x0007 Serial Number: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Part Number: To Be Filled By O.E.M. Core Count: 4 Core Enabled: 4 Thread Count: 8 Characteristics: 64-bit capable Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1-Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 256 kB Maximum Size: 256 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Parity System Type: Data Associativity: 8-way Set-associative Handle 0x0006, DMI type 7, 19 bytes Cache Information Socket Designation: L2-Cache Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 1024 kB Maximum Size: 1024 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 8-way Set-associative Handle 0x0007, DMI type 7, 19 bytes Cache Information Socket Designation: L3-Cache Configuration: Enabled, Not Socketed, Level 3 Operational Mode: Write Back Location: Internal Installed Size: 8192 kB Maximum Size: 8192 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 16-way Set-associative Handle 0x0008, DMI type 4, 42 bytes Processor Information Socket Designation: CPU 2 Type: Central Processor Family: Xeon Manufacturer: Intel ID: A5 06 01 00 FF FB EB BF Signature: Type 0, Family 6, Model 26, Stepping 5 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz Voltage: Unknown External Clock: 133 MHz Max Speed: 2266 MHz Current Speed: 2266 MHz Status: Populated, Enabled Upgrade: Other L1 Cache Handle: 0x0009 L2 Cache Handle: 0x000A L3 Cache Handle: 0x000B Serial Number: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Part Number: To Be Filled By O.E.M. Core Count: 4 Core Enabled: 4 Thread Count: 8 Characteristics: 64-bit capable Handle 0x0009, DMI type 7, 19 bytes Cache Information Socket Designation: L1-Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 256 kB Maximum Size: 256 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Parity System Type: Data Associativity: 8-way Set-associative Handle 0x000A, DMI type 7, 19 bytes Cache Information Socket Designation: L2-Cache Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 1024 kB Maximum Size: 1024 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 8-way Set-associative Handle 0x000B, DMI type 7, 19 bytes Cache Information Socket Designation: L3-Cache Configuration: Enabled, Not Socketed, Level 3 Operational Mode: Write Back Location: Internal Installed Size: 8192 kB Maximum Size: 8192 kB Supported SRAM Types: Other Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 16-way Set-associative Handle 0x000C, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J1A1 Internal Connector Type: None External Reference Designator: PS2Mouse External Connector Type: PS/2 Port Type: Mouse Port Handle 0x000D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J1A1 Internal Connector Type: None External Reference Designator: Keyboard External Connector Type: PS/2 Port Type: Keyboard Port Handle 0x000E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J2A2 Internal Connector Type: None External Reference Designator: USB1 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x000F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J2A2 Internal Connector Type: None External Reference Designator: USB2 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0010, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J4A1 Internal Connector Type: None External Reference Designator: LPT 1 External Connector Type: DB-25 male Port Type: Parallel Port ECP/EPP Handle 0x0011, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J2A1 Internal Connector Type: None External Reference Designator: COM A External Connector Type: DB-9 male Port Type: Serial Port 16550A Compatible Handle 0x0012, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6A1 Internal Connector Type: None External Reference Designator: Audio Mic In External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x0013, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6A1 Internal Connector Type: None External Reference Designator: Audio Line In External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x0014, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6B1 - AUX IN Internal Connector Type: On Board Sound Input From CD-ROM External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x0015, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6B2 - CDIN Internal Connector Type: On Board Sound Input From CD-ROM External Reference Designator: Not Specified External Connector Type: None Port Type: Audio Port Handle 0x0016, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6J2 - PRI IDE Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0017, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6J1 - SEC IDE Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0018, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J4J1 - FLOPPY Internal Connector Type: On Board Floppy External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0019, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J9H1 - FRONT PNL Internal Connector Type: 9 Pin Dual Inline (pin 10 cut) External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001A, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J1B1 - CHASSIS REAR FAN Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001B, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J2F1 - CPU FAN Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001C, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J8B4 - FRONT FAN Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J9G2 - FNT USB Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J6C3 - FP AUD Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x001F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J9G1 - CONFIG Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0020, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J8C1 - SCSI LED Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0021, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J9J2 - INTRUDER Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0022, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J9G4 - ITP Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0023, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J2H1 - MAIN POWER Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0024, DMI type 9, 17 bytes System Slot Information Designation: PCI1 Type: 32-bit PCI Current Usage: Available Length: Short ID: 1 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0025, DMI type 9, 17 bytes System Slot Information Designation: PCI2 Type: 32-bit PCI Express Current Usage: Available Length: Short ID: 2 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0026, DMI type 9, 17 bytes System Slot Information Designation: PCIE3 Type: x4 PCI Express Current Usage: Available Length: Long ID: 3 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0027, DMI type 9, 17 bytes System Slot Information Designation: PCIE4 Type: x8 PCI Express Current Usage: In Use Length: Short ID: 4 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0028, DMI type 9, 17 bytes System Slot Information Designation: PCIE5 Type: x4 PCI Express Current Usage: Available Length: Long ID: 5 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x0029, DMI type 9, 17 bytes System Slot Information Designation: PCIE6 Type: x16 PCI Express Current Usage: Available Length: Long ID: 6 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Handle 0x002A, DMI type 13, 22 bytes BIOS Language Information Language Description Format: Long Installable Languages: 1 en|US|iso8859-1 Currently Installed Language: en|US|iso8859-1 Handle 0x002B, DMI type 15, 55 bytes System Event Log Area Length: 1008 bytes Header Start Offset: 0x0810 Data Start Offset: 0x0810 Access Method: General-purpose non-volatile data functions Access Address: 0x0001 Status: Valid, Not Full Change Token: 0x00000000 Header Format: No Header Supported Log Type Descriptors: 15 Descriptor 1: OEM-specific Data Format 1: Multiple-event handle Descriptor 2: OEM-specific Data Format 2: Multiple-event handle Descriptor 3: Single-bit ECC memory error Data Format 3: Multiple-event handle Descriptor 4: Multi-bit ECC memory error Data Format 4: Multiple-event handle Descriptor 5: Parity memory error Data Format 5: Multiple-event Descriptor 6: I/O channel block Data Format 6: Multiple-event Descriptor 7: POST error Data Format 7: POST results bitmap Descriptor 8: PCI parity error Data Format 8: Multiple-event handle Descriptor 9: PCI system error Data Format 9: Multiple-event handle Descriptor 10: System limit exceeded Data Format 10: Multiple-event system management Descriptor 11: OEM-specific Data Format 11: POST results bitmap Descriptor 12: OEM-specific Data Format 12: Multiple-event handle Descriptor 13: OEM-specific Data Format 13: Multiple-event handle Descriptor 14: OEM-specific Data Format 14: Multiple-event handle Descriptor 15: OEM-specific Data Format 15: Multiple-event handle Handle 0x002C, DMI type 16, 15 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 384 GB Error Information Handle: 0x002D Number Of Devices: 3 Handle 0x002D, DMI type 18, 23 bytes 32-bit Memory Error Information Type: Bad Read Granularity: Device Level Operation: Read Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown Handle 0x002E, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000018003FF Range Size: 24577 kB Physical Array Handle: 0x002C Partition Width: 3 Handle 0x002F, DMI type 17, 28 bytes Memory Device Array Handle: 0x002C Error Information Handle: 0x0030 Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: P1_DIMM1A Bank Locator: BANK0 Type: Other Type Detail: Other Speed: 1333 MHz Manufacturer: Hyundai Serial Number: 00000C20 Asset Tag: AssetTagNum0 Part Number: HMT125R7AFP8C-H9 Rank: Unknown Handle 0x0030, DMI type 18, 23 bytes 32-bit Memory Error Information Type: Bad Read Granularity: Device Level Operation: Read Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown Handle 0x0031, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000008003FF Range Size: 8193 kB Physical Device Handle: 0x002F Memory Array Mapped Address Handle: 0x002E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0032, DMI type 17, 28 bytes Memory Device Array Handle: 0x002C Error Information Handle: 0x0033 Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: P1_DIMM2A Bank Locator: BANK1 Type: Other Type Detail: Other Speed: 1333 MHz Manufacturer: Hyundai Serial Number: 00000A20 Asset Tag: AssetTagNum1 Part Number: HMT125R7AFP8C-H9 Rank: Unknown Handle 0x0033, DMI type 18, 23 bytes 32-bit Memory Error Information Type: Unknown Granularity: Unknown Operation: Unknown Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown Handle 0x0034, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0032 Memory Array Mapped Address Handle: 0x002E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0035, DMI type 17, 28 bytes Memory Device Array Handle: 0x002C Error Information Handle: 0x0036 Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: P1_DIMM3A Bank Locator: BANK2 Type: Other Type Detail: Other Speed: 1333 MHz Manufacturer: Hyundai Serial Number: 00001040 Asset Tag: AssetTagNum2 Part Number: HMT125R7AFP8C-H9 Rank: Unknown Handle 0x0036, DMI type 18, 23 bytes 32-bit Memory Error Information Type: Unknown Granularity: Unknown Operation: Unknown Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown Handle 0x0037, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0035 Memory Array Mapped Address Handle: 0x002E Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0038, DMI type 16, 15 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 384 GB Error Information Handle: 0x0039 Number Of Devices: 3 Handle 0x0039, DMI type 18, 23 bytes 32-bit Memory Error Information Type: Unknown Granularity: Unknown Operation: Unknown Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown Handle 0x003A, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00001800000 Ending Address: 0x000030003FF Range Size: 24577 kB Physical Array Handle: 0x0038 Partition Width: 3 Handle 0x003B, DMI type 17, 28 bytes Memory Device Array Handle: 0x0038 Error Information Handle: 0x003C Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: P0_DIMM1A Bank Locator: BANK3 Type: Other Type Detail: Other Speed: 1333 MHz Manufacturer: Hyundai Serial Number: 00000B20 Asset Tag: AssetTagNum3 Part Number: HMT125R7AFP8C-H9 Rank: Unknown Handle 0x003C, DMI type 18, 23 bytes 32-bit Memory Error Information Type: Unknown Granularity: Unknown Operation: Unknown Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown Handle 0x003D, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000800000 Ending Address: 0x000010003FF Range Size: 8193 kB Physical Device Handle: 0x003B Memory Array Mapped Address Handle: 0x003A Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x003E, DMI type 17, 28 bytes Memory Device Array Handle: 0x0038 Error Information Handle: 0x003F Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: P0_DIMM2A Bank Locator: BANK4 Type: Other Type Detail: Other Speed: 1333 MHz Manufacturer: Hyundai Serial Number: 00000240 Asset Tag: AssetTagNum4 Part Number: HMT125R7AFP8C-H9 Rank: Unknown Handle 0x003F, DMI type 18, 23 bytes 32-bit Memory Error Information Type: Unknown Granularity: Unknown Operation: Unknown Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown Handle 0x0040, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x003E Memory Array Mapped Address Handle: 0x003A Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0041, DMI type 17, 28 bytes Memory Device Array Handle: 0x0038 Error Information Handle: 0x0042 Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: P0_DIMM3A Bank Locator: BANK5 Type: Other Type Detail: Other Speed: 1333 MHz Manufacturer: Hyundai Serial Number: 00000F20 Asset Tag: AssetTagNum5 Part Number: HMT125R7AFP8C-H9 Rank: Unknown Handle 0x0042, DMI type 18, 23 bytes 32-bit Memory Error Information Type: Unknown Granularity: Unknown Operation: Unknown Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown Handle 0x0043, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0041 Memory Array Mapped Address Handle: 0x003A Partition Row Position: 1 Interleave Position: Unknown Interleaved Data Depth: 2 Handle 0x0044, DMI type 16, 15 bytes Physical Memory Array Location: System Board Or Motherboard Use: Flash Memory Error Correction Type: None Maximum Capacity: 4 MB Error Information Handle: Not Provided Number Of Devices: 1 Handle 0x0045, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000003FFFFF Range Size: 4 MB Physical Array Handle: 0x0044 Partition Width: 1 Handle 0x0046, DMI type 17, 28 bytes Memory Device Array Handle: 0x0044 Error Information Handle: Not Provided Total Width: 8 bits Data Width: 8 bits Size: 4096 kB Form Factor: Other Set: None Locator: Bank Locator: Type: Flash Type Detail: Non-Volatile Speed: 33 MHz Manufacturer: ATMEL Serial Number: Asset Tag: Part Number: 26DF321 Rank: Unknown Handle 0x0047, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x000FFC00000 Ending Address: 0x000FFFFFFFF Range Size: 4 MB Physical Device Handle: 0x0046 Memory Array Mapped Address Handle: 0x0045 Partition Row Position: Handle 0x0048, DMI type 32, 20 bytes System Boot Information Status: No errors detected Handle 0x0049, DMI type 38, 18 bytes IPMI Device Information Interface Type: KCS (Keyboard Control Style) Specification Version: 1.5 I2C Slave Address: 0x10 NV Storage Device: Not Present Base Address: 0x0000000000000CA2 (I/O) Register Spacing: Successive Byte Boundaries Handle 0x004A, DMI type 41, 11 bytes Onboard Device Reference Designation: To Be Filled By O.E.M. Type: Video Status: Enabled Type Instance: 0 Handle 0x004B, DMI type 41, 11 bytes Onboard Device Reference Designation: To Be Filled By O.E.M. Type: SCSI Controller Status: Disabled Type Instance: 0 Handle 0x004C, DMI type 127, 4 bytes End Of Table Any help in identifying the source of the problem is very greatly appreciated. -kim -- From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 18:38:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5CD0106564A for ; Sat, 16 Jul 2011 18:38:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 8896C8FC0A for ; Sat, 16 Jul 2011 18:38:17 +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 p6GIcH89072982; Sat, 16 Jul 2011 11:38:17 -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 p6GIcH1w072981; Sat, 16 Jul 2011 11:38:17 -0700 (PDT) (envelope-from sgk) Date: Sat, 16 Jul 2011 11:38:17 -0700 From: Steve Kargl To: Kim Culhan Message-ID: <20110716183817.GA72898@troutmask.apl.washington.edu> References: 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: freebsd-current@freebsd.org Subject: Re: Interpreting MCA error output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Jul 2011 18:38:17 -0000 On Sat, Jul 16, 2011 at 02:25:20PM -0400, Kim Culhan wrote: > Noticed the following console message while running make world with > 9.0-CURRENT on 7-16-11 > > Jul 16 11:15:20 delta kernel: MCA: Vendor "GenuineIntel", ID 0x106a5, APIC > ID 16 > Jul 16 11:15:20 delta kernel: MCA: CPU 8 COR (1) RD channel ?? memory error > Jul 16 11:15:20 delta kernel: MCA: Address 0x28f261f80 > Jul 16 11:15:20 delta kernel: MCA: Misc 0x1834958000001385 > Jul 16 12:15:20 delta kernel: MCA: Bank 8, Status 0x8c0000400001009f > Jul 16 12:15:20 delta kernel: MCA: Global Cap 0x0000000000001c09, Status > 0x00000 > 00000000000 > Jul 16 12:15:20 delta kernel: MCA: Vendor "GenuineIntel", ID 0x106a5, APIC > ID 16 > Jul 16 12:15:20 delta kernel: MCA: CPU 8 COR (1) RD channel ?? memory error > Jul 16 12:15:20 delta kernel: MCA: Address 0x28e019f80 > Jul 16 12:15:20 delta kernel: MCA: Misc 0x1834958000000588 Copying the above into zxc, I see troutmask:kargl[212] ./mcelog --ascii < zxc mcelog: Cannot open /dev/mem for DMI decoding: Permission denied HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 8 BANK 8 MISC 1834958000000588 ADDR 28e019f80 MCG status: MCi status: MCi_MISC register valid MCi_ADDR register valid MCA: MEMORY CONTROLLER RD_CHANNELunspecified_ERR Transaction: Memory read error Memory read ECC error Memory corrected error count (CORE_ERR_CNT): 1 Memory transaction Tracker ID (RTId): 88 Memory DIMM ID of error: 0 Memory channel ID of error: 0 Memory ECC syndrome: 18349580 STATUS 8c0000400001009f MCGSTATUS 0 MCGCAP 1c09 APICID 10 SOCKETID 0 CPUID Vendor Intel Family 6 Model 26 Looks like your DIMM 0 had an error that was corrected due to ECC. From owner-freebsd-current@FreeBSD.ORG Sat Jul 16 20:14:46 2011 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 D02C0106564A; Sat, 16 Jul 2011 20:14:46 +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 9E3008FC12; Sat, 16 Jul 2011 20:14:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6GKEjvK001559; Sat, 16 Jul 2011 16:14:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6GKEjBG001448; Sat, 16 Jul 2011 20:14:45 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Jul 2011 20:14:45 GMT Message-Id: <201107162014.p6GKEjBG001448@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 i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 20:14:46 -0000 TB --- 2011-07-16 17:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-16 17:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-07-16 17:10:00 - cleaning the object tree TB --- 2011-07-16 17:10:43 - cvsupping the source tree TB --- 2011-07-16 17:10:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-07-16 17:11:00 - building world TB --- 2011-07-16 17:11:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 17:11:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 17:11:00 - TARGET=i386 TB --- 2011-07-16 17:11:00 - TARGET_ARCH=i386 TB --- 2011-07-16 17:11:00 - TZ=UTC TB --- 2011-07-16 17:11:00 - __MAKE_CONF=/dev/null TB --- 2011-07-16 17:11:00 - cd /src TB --- 2011-07-16 17:11:00 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 16 17:11:00 UTC 2011 >>> 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 Sat Jul 16 19:07:30 UTC 2011 TB --- 2011-07-16 19:07:31 - generating LINT kernel config TB --- 2011-07-16 19:07:31 - cd /src/sys/i386/conf TB --- 2011-07-16 19:07:31 - /usr/bin/make -B LINT TB --- 2011-07-16 19:07:31 - building LINT kernel TB --- 2011-07-16 19:07:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 19:07:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 19:07:31 - TARGET=i386 TB --- 2011-07-16 19:07:31 - TARGET_ARCH=i386 TB --- 2011-07-16 19:07:31 - TZ=UTC TB --- 2011-07-16 19:07:31 - __MAKE_CONF=/dev/null TB --- 2011-07-16 19:07:31 - cd /src TB --- 2011-07-16 19:07:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 16 19:07:31 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jul 16 19:37:12 UTC 2011 TB --- 2011-07-16 19:37:12 - cd /src/sys/i386/conf TB --- 2011-07-16 19:37:12 - /usr/sbin/config -m GENERIC TB --- 2011-07-16 19:37:12 - building GENERIC kernel TB --- 2011-07-16 19:37:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 19:37:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 19:37:12 - TARGET=i386 TB --- 2011-07-16 19:37:12 - TARGET_ARCH=i386 TB --- 2011-07-16 19:37:12 - TZ=UTC TB --- 2011-07-16 19:37:12 - __MAKE_CONF=/dev/null TB --- 2011-07-16 19:37:12 - cd /src TB --- 2011-07-16 19:37:12 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Jul 16 19:37:13 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Jul 16 20:00:13 UTC 2011 TB --- 2011-07-16 20:00:13 - cd /src/sys/i386/conf TB --- 2011-07-16 20:00:13 - /usr/sbin/config -m PAE TB --- 2011-07-16 20:00:13 - building PAE kernel TB --- 2011-07-16 20:00:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 20:00:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 20:00:13 - TARGET=i386 TB --- 2011-07-16 20:00:13 - TARGET_ARCH=i386 TB --- 2011-07-16 20:00:13 - TZ=UTC TB --- 2011-07-16 20:00:13 - __MAKE_CONF=/dev/null TB --- 2011-07-16 20:00:13 - cd /src TB --- 2011-07-16 20:00:13 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Jul 16 20:00:13 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sat Jul 16 20:06:20 UTC 2011 TB --- 2011-07-16 20:06:20 - cd /src/sys/i386/conf TB --- 2011-07-16 20:06:20 - /usr/sbin/config -m XBOX TB --- 2011-07-16 20:06:21 - building XBOX kernel TB --- 2011-07-16 20:06:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 20:06:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 20:06:21 - TARGET=i386 TB --- 2011-07-16 20:06:21 - TARGET_ARCH=i386 TB --- 2011-07-16 20:06:21 - TZ=UTC TB --- 2011-07-16 20:06:21 - __MAKE_CONF=/dev/null TB --- 2011-07-16 20:06:21 - cd /src TB --- 2011-07-16 20:06:21 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sat Jul 16 20:06:21 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Sat Jul 16 20:09:27 UTC 2011 TB --- 2011-07-16 20:09:27 - cd /src/sys/i386/conf TB --- 2011-07-16 20:09:27 - /usr/sbin/config -m XEN TB --- 2011-07-16 20:09:27 - building XEN kernel TB --- 2011-07-16 20:09:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 20:09:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 20:09:27 - TARGET=i386 TB --- 2011-07-16 20:09:27 - TARGET_ARCH=i386 TB --- 2011-07-16 20:09:27 - TZ=UTC TB --- 2011-07-16 20:09:27 - __MAKE_CONF=/dev/null TB --- 2011-07-16 20:09:27 - cd /src TB --- 2011-07-16 20:09:27 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat Jul 16 20:09:27 UTC 2011 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh XEN cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug mptable_pci.o: In function `mptable_hostb_attach': /src/sys/x86/x86/mptable_pci.c:73: undefined reference to `mptable_pci_host_res_init' *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-16 20:14:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-16 20:14:44 - ERROR: failed to build XEN kernel TB --- 2011-07-16 20:14:44 - 8695.02 user 1624.04 system 11084.23 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full