From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 03:33:47 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7ECFC406; Sun, 21 Jul 2013 03:33:47 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) by mx1.freebsd.org (Postfix) with ESMTP id B9CCEFB5; Sun, 21 Jul 2013 03:33:46 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id r6L3Dg9B011888; Sat, 20 Jul 2013 22:33:39 -0500 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp1.rice.edu with ESMTP id 1dpkf2gyjc-1; Sat, 20 Jul 2013 22:33:39 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel Received: from [192.168.5.116] (unknown [12.107.116.132]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id BECC440125; Sat, 20 Jul 2013 22:33:36 -0500 (CDT) Subject: Re: Fix for sys_munlock(2) with racct Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Alan Cox In-Reply-To: <20130720112218.GD13628@caravan.chchile.org> Date: Sat, 20 Jul 2013 20:33:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <115EDC04-4B95-4FB5-9092-515188D8ADA7@rice.edu> References: <20130720112218.GD13628@caravan.chchile.org> To: Jeremie Le Hen X-Mailer: Apple Mail (2.1085) X-Proofpoint-SSN: Sensitivity3 Cc: Alan Cox , Konstantin Belousov , freebsd-current@FreeBSD.org, trasz@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 03:33:47 -0000 On Jul 20, 2013, at 4:22 AM, Jeremie Le Hen wrote: > Hi Edward, Alan, >=20 > I plan to commit the following patch: > http://people.freebsd.org/~jlh/racct_munlock.diff >=20 > This solves the following panic: >=20 > panic: racct_sub: freeing 301989888 of resource 5, which is more than = allocated 73728 for pwsafe (pid 4177) >=20 > The problem is that the racct code in sys_munlock() trusts too much = the > user's input. vm_map_unwire_count() now returns how much memory has > really been unwired. >=20 > Any objection? Can you elaborate on what you mean by "sys_munlock() trusts too much the = user's input." munlock(2) is supposed to return ENOMEM if any = addresses within the specified range are not backed by valid mappings. = (Valid mappings with PROT_NONE access are something of a gray area = here.) However, it is not error for a to call munlock() on a range that = isn't locked, or to call it a second, third, etc. time on the same = range. Is that what is provoking your panic? By the way, sys_mlock() uses a simpler approach to deal with a similar = situation: error =3D vm_map_wire(map, start, end,=20 VM_MAP_WIRE_USER | VM_MAP_WIRE_NOHOLES); #ifdef RACCT if (error !=3D KERN_SUCCESS) { PROC_LOCK(proc); racct_set(proc, RACCT_MEMLOCK, ptoa(pmap_wired_count(map->pmap))); PROC_UNLOCK(proc); } #endif However, the code in sys_mlock() for maintaining RACCT_MEMLOCK, = including the above snippet, is race-y. Two simultaneous callers to = sys_mlock() will produce incorrect results. (I haven't looked at = sys_mlockall() or vm_map_growstack().) Also, a wired mapping can be destroyed by calling munmap(2) without = first calling munlock(2), in which case, RACCT_MEMLOCK will be = incorrect. =20 Alan From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 07:18:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 555A7A00 for ; Sun, 21 Jul 2013 07:18:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id DBAB0812 for ; Sun, 21 Jul 2013 07:18:53 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6L7IhPV002544; Sun, 21 Jul 2013 10:18:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6L7IhPV002544 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6L7IgVf002543; Sun, 21 Jul 2013 10:18:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Jul 2013 10:18:42 +0300 From: Konstantin Belousov To: Oliver Pinter Subject: Re: Panic when starting X with Intel KMS Message-ID: <20130721071842.GZ5991@kib.kiev.ua> References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V1B6tgkYnQOXc079" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Gustau P?rez i Querol , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 07:18:54 -0000 --V1B6tgkYnQOXc079 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 20, 2013 at 01:20:56PM +0200, Oliver Pinter wrote: > On 7/20/13, Gustau P?rez i Querol wrote: > > Reading the backtrace I see this: > > > > panic: pmap_release: pmap resident count -398580 !=3D 0 > > > > which comes from amd64/amd64/pmap.c:1936. I suspect that > > pmap->pm_stats.resident_count being negative is a bug. The issue happened somewhere before the process exit. Try the patch below, the idea is that your overflow count is really big, so the wrong-doer could cause underflow when acting. diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c index 19be4e0..fcdc6af 100644 --- a/sys/amd64/amd64/pmap.c +++ b/sys/amd64/amd64/pmap.c @@ -465,6 +465,9 @@ pmap_resident_count_dec(pmap_t pmap, int count) { =20 PMAP_LOCK_ASSERT(pmap, MA_OWNED); + KASSERT(pmap->pm_stats.resident_count >=3D count, + ("pmap %p resident count underflow %ld %d", pmap, + pmap->pm_stats.resident_count, count)); pmap->pm_stats.resident_count -=3D count; } =20 --V1B6tgkYnQOXc079 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR64tRAAoJEJDCuSvBvK1BX8IQAJQyhTy9XCMNw1Gvio80YJ5c /B+Y1TGVSQ8n2rOuZFqdqYFYzFhxglimvZIWLn1gOu2n30rHciRYlffP6fqxUkG/ ZoNPtsFyvzBruuUEZgttRECJ0m7zi0y9PAIpFqYc3jSPHp/xfrjulj13YKSG3p0M oz1c1PRMg7cJLdVSBhdL2cVlTjLFhiwTU2Clo+XNeAuWyALIxpoT8q+6a/SM7U/u SLT804ROjQ+lbABaiPMpBR5X6VxcG5yuMb4kFvLcI8WrK97Pj1ZgOulbixSwKYZe 98EY0EDRAHxa3Gk716vEblsm0CLqXYrk5JxhYmDSacMiEJnzt/DIBuQAAUGDmqam LnYO/ygj9rkvX5HLvZUPTvv9E4qQFMvyflrgXv5beBa7dwrHhSs7f/k0F8LcxF5+ XlvSbHJ5ozWqCwV2v4/wj6JNJYPdA/w0k01kP+7BabiSr/14swkXGr5fH91OrgDq EQbHme23oWeSS3niqiinlgnRWkrI3oG97ra8+Nx6NZntABxO+xWdS1MklrTmXEKQ 0WR+Au2w3GluSg54gshDFFxHCZWnG1T0u7kQ6NplmTcBnLzhD9lI8Q351vSX/KeR 0vA+M4eBEvjLQFmKRE/EQkjwdBjJ+roMXImvwLMhiLyJz6zK7ehH12zRpMMOkR9y SY7+b2tkyd9KwwGXp8Wt =rlWz -----END PGP SIGNATURE----- --V1B6tgkYnQOXc079-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 07:20:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 788D3BBC; Sun, 21 Jul 2013 07:20:58 +0000 (UTC) (envelope-from joel@freebsd.org) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id 3A382841; Sun, 21 Jul 2013 07:20:57 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 81EF2E3F07A; Sun, 21 Jul 2013 09:20:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl27mxjVp8ip; Sun, 21 Jul 2013 09:20:48 +0200 (CEST) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 4BEC6E3F079; Sun, 21 Jul 2013 09:20:48 +0200 (CEST) Date: Sun, 21 Jul 2013 09:20:45 +0200 From: Joel Dahl To: current@freebsd.org Subject: Re: Lenovo x220 - hangs on shutdown Message-ID: <20130721072045.GB56585@devbox.vnode.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kib@freebsd.org, neel@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 07:20:58 -0000 On Tue, Jul 16, 2013 at 10:48:35PM +0200, Joel Dahl wrote: > Hi, > > Yesterday I upgraded my Lenovo x220 to the latest current (r253368). Now it hangs when I do a shutdown from an xterm. The screen just goes black and the fan never spins down. It doesn't respond to ping. > > It didn't do this while I was running a current from mid-June. > > Any specific revision I should try to back out before I start a time consuming binary search? I found it. r252652 works. r252653 does not. -- Joel From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 09:31:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0EF243C for ; Sun, 21 Jul 2013 09:31:44 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 533CCE41 for ; Sun, 21 Jul 2013 09:31:43 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id r6L9Va1D019066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Jul 2013 11:31:36 +0200 Received: from [192.168.1.110] (174.Red-79-153-75.dynamicIP.rima-tde.net [79.153.75.174]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id r6L9VYqZ016639 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 21 Jul 2013 11:31:36 +0200 Message-ID: <51EBAA76.8020100@entel.upc.edu> Date: Sun, 21 Jul 2013 11:31:34 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD current Subject: Re: Panic when starting X with Intel KMS References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> <20130721071842.GZ5991@kib.kiev.ua> In-Reply-To: <20130721071842.GZ5991@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Sun, 21 Jul 2013 11:31:36 +0200 (CEST) Cc: Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 09:31:44 -0000 > The issue happened somewhere before the process exit. Try the patch > below, the idea is that your overflow count is really big, so the > wrong-doer could cause underflow when acting. > > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 19be4e0..fcdc6af 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -465,6 +465,9 @@ pmap_resident_count_dec(pmap_t pmap, int count) > { > > PMAP_LOCK_ASSERT(pmap, MA_OWNED); > + KASSERT(pmap->pm_stats.resident_count >= count, > + ("pmap %p resident count underflow %ld %d", pmap, > + pmap->pm_stats.resident_count, count)); > pmap->pm_stats.resident_count -= count; > } > Hi, the assert doesn't happen (that's resident_count is not bigger than count). You can find the complete core at: https://dl.dropboxusercontent.com/u/2094962/core.txt.5 I'm no expert on that, but would this mean that the process, while freeying mem, causes the kernel to free more maps than the process has? Any other info during the panic, let me know (I have a second machine and I can connect to it via serial port). OTOH, in puzzled because the stack gets corrupted an thus I can't check which is the offending process (I don't know if that would be of any use in this situation). It is my understanding that isn't the process who should be fixed but the kernel side. In this case the stack corruption isn't that very important (at least this is what I think), but sometimes it is very handy. -- Salut i força, Gustau --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 08:19:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DC56C72D; Sun, 21 Jul 2013 08:19:21 +0000 (UTC) (envelope-from chris.torek@gmail.com) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 79DF1A96; Sun, 21 Jul 2013 08:19:21 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id gf12so2975092vcb.11 for ; Sun, 21 Jul 2013 01:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1ffgzGBwyZ7ub7dQiGlHTq9vKnTMKv5C5otLsmC34Rw=; b=JXa/YonM8gzL15IS14J8HF5Xr4wwfaKNTFiHA1Iu99acRXv3ArNgov+fC/G4H5iXxJ zs2mxJqgnaDvddk5Y3yYPi4Q0vHr/FMRJPR0BiUKx/kWOeV8665L3w+ktBnBEmAiaQqv ARgGY/Iepf1dxtqepzjxgxyBaB6Vx8E5jB7Ni2PzP6gRDLJ8+y2phaHwPpXr8cS8Uxm7 PJoiT/9EB+HO+h+OzBr5Zt5nnwb4ubFdWaTB24uYIWbeyxda0h7ePU5DxZJ6UQhdGjmh V2bwgQC3q6oEM2FmZURVZrvhOAnIwZd05x5Fjat+RNlayWDRd7u4UXCanhmGeSqAHFM/ U6bg== MIME-Version: 1.0 X-Received: by 10.58.200.73 with SMTP id jq9mr7913402vec.53.1374394761086; Sun, 21 Jul 2013 01:19:21 -0700 (PDT) Received: by 10.220.187.197 with HTTP; Sun, 21 Jul 2013 01:19:21 -0700 (PDT) In-Reply-To: References: <201306190832.r5J8WZFE082135@elf.torek.net> Date: Sun, 21 Jul 2013 02:19:21 -0600 Message-ID: Subject: Re: expanding past 1 TB on amd64 From: Chris Torek To: alc@freebsd.org X-Mailman-Approved-At: Sun, 21 Jul 2013 11:31:28 +0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current , neel@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 08:19:21 -0000 (Apologies for delay in reply, family issues) I'd be fine with 4 TB instead of 16; and, at this point, with the latest patches, it's easily tuned. The auto-sizing of the direct map is not affected by sparse space as it keys off Maxmem, which is not actually physical size, but rather "one past last valid physical page". The direct map limit might not need to be "twice kernel virtual size" but on Intel memory-controller systems needs to be "greater than KVM size" due to moving DRAM up past the PCI hole. Unless the restriction that the direct-map area be a power of two size is removed, that winds up meaning "twice". (Removing the restriction seems easy enough=97instead of "pa | highbits" to obtain VA and "va &~ highbits" to obtain PA, just use "phys + offset" and "virt - offset". I didn't see a reason to bother with the effort, though.) Chris From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 13:21:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B1DD9209 for ; Sun, 21 Jul 2013 13:21:57 +0000 (UTC) (envelope-from robin@snow-hamster.de) Received: from tokio.snow-hamster.de (tokio.snow-hamster.de [78.46.229.119]) by mx1.freebsd.org (Postfix) with ESMTP id 7A2F2BDC for ; Sun, 21 Jul 2013 13:21:57 +0000 (UTC) Received: from [192.168.1.103] (ip-37-24-118-90.unitymediagroup.de [37.24.118.90]) by tokio.snow-hamster.de (Postfix) with ESMTPSA id BEC91BA0B1 for ; Sun, 21 Jul 2013 15:13:58 +0200 (CEST) Date: Sun, 21 Jul 2013 15:13:57 +0200 Subject: where is the startkde file of kde4 Message-ID: From: Robin Lehrmann To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 13:21:57 -0000 aGVsbG8gbWFpbGluZy1saXN0LCAKSSBoYXZlIGluc3RhbGxlZCBrZGU0IG9uIHRoZSBjdXJyZW50 IGZyZWVic2QuIAoKTm93IEkgd2FudCB0byBzdGFydCBpdCBidXQgSSBkb24ndCBmaW5kIHRoZSBz dGFydCBzY3JpcHQgaW4gL3Vzci9sb2NhbC9rZGU0L2JpbgoKSSB0cnkgdGhlIHNjcmlwdHMga2Rl NCBrZGVkNCBrZGVpbml0NCBidXQgSSBnZXQgYWx3YXlzIHRoZSBlcnJvciAiJERpc3BsYXkgaXMg Tm90IFNldCIgCgpob3cgY2FuIEkgc2V0IHRoZSBkaXNwbGF5IG9yIHN0YXJ0IGtkZTQ/CgotIFJv YmluIExlaHJtYW5u From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 13:44:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C16D3908; Sun, 21 Jul 2013 13:44:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by mx1.freebsd.org (Postfix) with ESMTP id DDE69D0B; Sun, 21 Jul 2013 13:44:58 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id k10so1034805wiv.17 for ; Sun, 21 Jul 2013 06:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VoX3KMpKZ2KqGs7/TiZUlYjIZugZyNYCizPBFfmvjHs=; b=cZgRmPH/JWm69J0k2KNATYNInvNVk1cyOvSEM/Fu0RGQhPGukwjZH4Cw+gg9u43RJY w+vvMwTaIBdygCaM+CnEtabbyNAK6vyzTavi8by5reXHpb1tHmJLzxivIAYKnSIcofkX DzOtf8J09lHDQBcMA/UPRgZLcmCtMyZ75Sqt9AQIVI3uhuuWw6A3etPZtYnhdzty5+Gz Qx4xcPQ6EEt6q+uD4UbLhDDvzwyKhK0oICspoUJaQrz0Zx/Lrrodsfa/gOjIm58mxRoX K1Tjw/XOBtSdZgYoJ6blq5Dxp1xYxNry265VIwa1uHEvwb359HzT/3GmQCkycSQlreqR gqqg== MIME-Version: 1.0 X-Received: by 10.194.11.72 with SMTP id o8mr17145402wjb.0.1374414298098; Sun, 21 Jul 2013 06:44:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 21 Jul 2013 06:44:58 -0700 (PDT) In-Reply-To: <20130721072045.GB56585@devbox.vnode.local> References: <20130721072045.GB56585@devbox.vnode.local> Date: Sun, 21 Jul 2013 06:44:58 -0700 X-Google-Sender-Auth: lQWMIOoqfWMvfqSz1fFkTxe8cx0 Message-ID: Subject: Re: Lenovo x220 - hangs on shutdown From: Adrian Chadd To: Joel Dahl Content-Type: text/plain; charset=ISO-8859-1 Cc: kib@freebsd.org, current@freebsd.org, neel@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 13:44:59 -0000 Hi! Great catch! Neel - any ideas why this change would stop Joel's machine from cleanly shutting down? -adrian On 21 July 2013 00:20, Joel Dahl wrote: > On Tue, Jul 16, 2013 at 10:48:35PM +0200, Joel Dahl wrote: >> Hi, >> >> Yesterday I upgraded my Lenovo x220 to the latest current (r253368). Now it hangs when I do a shutdown from an xterm. The screen just goes black and the fan never spins down. It doesn't respond to ping. >> >> It didn't do this while I was running a current from mid-June. >> >> Any specific revision I should try to back out before I start a time consuming binary search? > > I found it. r252652 works. r252653 does not. > > -- > Joel > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 16:12:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 49F2B97E; Sun, 21 Jul 2013 16:12:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B3C65880; Sun, 21 Jul 2013 16:12:36 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6LGCXZK014924; Sun, 21 Jul 2013 19:12:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6LGCXZK014924 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6LGCX3G014923; Sun, 21 Jul 2013 19:12:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Jul 2013 19:12:33 +0300 From: Konstantin Belousov To: Joel Dahl Subject: Re: Lenovo x220 - hangs on shutdown Message-ID: <20130721161233.GB5991@kib.kiev.ua> References: <20130721072045.GB56585@devbox.vnode.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O2v8LnVIcZ+EDjcF" Content-Disposition: inline In-Reply-To: <20130721072045.GB56585@devbox.vnode.local> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org, neel@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 16:12:37 -0000 --O2v8LnVIcZ+EDjcF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 21, 2013 at 09:20:45AM +0200, Joel Dahl wrote: > On Tue, Jul 16, 2013 at 10:48:35PM +0200, Joel Dahl wrote: > > Hi, > >=20 > > Yesterday I upgraded my Lenovo x220 to the latest current (r253368). No= w it hangs when I do a shutdown from an xterm. The screen just goes black a= nd the fan never spins down. It doesn't respond to ping. > >=20 > > It didn't do this while I was running a current from mid-June. > >=20 > > Any specific revision I should try to back out before I start a time co= nsuming binary search? >=20 > I found it. r252652 works. r252653 does not. What is the chipset on your machine ? Do you have AMT ? If yes, please configure serial over LAN using AMT and use it for the console, to obtain the usual debugging information =66rom the kernel. At least, 'ps' output from ddb is needed. --O2v8LnVIcZ+EDjcF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR7AhwAAoJEJDCuSvBvK1B3aEP/0T6aVg6UsVVDFUHPdcUWH52 qI/q4TCvfpWtgGGzghLPI9PyUtnCy+i4vsdHlwzuFxfa99U/gaV4hQudGMelnpXU 62XTrf4nU3n51gl0qwKLeJU4ObM2IXpGmsDTukIBX22Vxqwtxh1KthMBrh+nACTH P25UjEg87Ed67oHHUJbIl3vTp6p2OIzLQ9gLfjHz2cdlNhga49IlsK1G4vcX69lP Q/PGUsk6FfC62XCzI+wdptTUhCfVKB2YOoCCWdIWSL+Shi245XWv2pYlJ22gizIk /B9G+Yc/Gk5NQ4hVtpIax9tjY7XNwK1elnTRaBpU+YPX0LE7iYlriXtz6e52Nwhg hUnSeXU+oZzyYMFZ6DFQnzLVgdogkF6jqyOhUQrR2m1EqjUemcaU/UhaccCKK8wW wPa8P+pnDFuROMjwoWVodRZy7ZsBBVT0juDnSVY5180ANPiaRdXSSKM5jTqbWPmG L6Ij3QVqzu6WKelGK+suXBAFBe9E/IDZfP+PtB+uE+4rwSEdvbGI+5L5HGGKdcMi vX89ykOWKCctjqTegsxRVOMTY2kpfwodZI5Is3VtTZP2w6zctgcdZIGfqgVoypC8 VkPlQvFG/VDGe98xlS7f+HcVrayozlrh5lztcVo6ljBG7vLIRcczgSukj28G9mQv PTi6EykzfPaD7m3bLoSA =/ZhK -----END PGP SIGNATURE----- --O2v8LnVIcZ+EDjcF-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 17:46:22 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8BF90FC8; Sun, 21 Jul 2013 17:46:22 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 45AA4B3A; Sun, 21 Jul 2013 17:46:21 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r6LHk4Pg086716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 02:46:14 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r6LHk2RV017158; Mon, 22 Jul 2013 02:46:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 22 Jul 2013 02:45:13 +0900 (JST) Message-Id: <20130722.024513.95685108976349294.hrs@allbsd.org> To: current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: CFT: cloned_interfaces and gifconfig in rc.d/netif From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Mon_Jul_22_02_45_13_2013_666)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 22 Jul 2013 02:46:14 +0900 (JST) X-Spam-Status: No, score=-90.4 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,QENCPTR2,RCVD_IN_PBL,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: freebsd-rc@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 17:46:22 -0000 ----Security_Multipart0(Mon_Jul_22_02_45_13_2013_666)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Jul_22_02_45_13_2013_191)--" Content-Transfer-Encoding: 7bit ----Next_Part(Mon_Jul_22_02_45_13_2013_191)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, The attached patch allows rc.d/netif to create IFs in $cloned_interfaces when interface name(s) is specified. For example, when the following lines are in rc.conf: cloned_interfaces="bridge0 bridge1" ifconfig_bridge0="..." ifconfig_bridge1="..." The following commands create the interfaces and destroy them. # /etc/rc.d/netif start bridge0 bridge1 # /etc/rc.d/netif stop bridge0 bridge1 netif cloneup/clonedown does this without the patch, but it cannot configure the interfaces and does not support clean teardown. Also, routines which handle $gif_interfaces are merged into ones for $cloned_interfaces. ifconfig_gifN and other variants did not work with gif interfaces defined in $gif_interfaces. The patch solves this issue. Basically there should be no functionality regression for the existing configurations. Can anyone who are using $gif_interfaces and/or $cloned_interfaces test this? I would like to know if there is regression or not. -- Hiroki ----Next_Part(Mon_Jul_22_02_45_13_2013_191)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="network.subr.gifconfig.20130722-1.diff" Index: etc/network.subr =================================================================== --- etc/network.subr (revision 253520) +++ etc/network.subr (working copy) @@ -660,6 +660,11 @@ IFS="$_ifs" for _inet in $inetList ; do # get rid of extraneous line + case $_inet in + "") break ;; + inet\ *) ;; + *) continue ;; + esac [ -z "$_inet" ] && break _inet=`expr "$_inet" : '.*\(inet \([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}\).*'` @@ -1192,12 +1197,17 @@ # clone_up() { - local _prefix _list ifn + local _prefix _list ifn _iflist _n tmpargs _prefix= _list= + _iflist=$* # create_args_IF for ifn in ${cloned_interfaces}; do + case $_iflist in + ""|$ifn|$ifn\ *|*\ $ifn\ *|*\ $ifn) ;; + *) continue ;; + esac ${IFCONFIG_CMD} ${ifn} create `get_if_var ${ifn} create_args_IF` if [ $? -eq 0 ]; then _list="${_list}${_prefix}${ifn}" @@ -1204,6 +1214,30 @@ [ -z "$_prefix" ] && _prefix=' ' fi done + if [ -n "$gif_interfaces" ]; then + warn "\$gif_interfaces is obsolete. Use \$cloned_interfaces instead." + fi + for ifn in ${gif_interfaces}; do + case $_iflist in + ""|$ifn|$ifn\ *|*\ $ifn\ *|*\ $ifn) ;; + *) continue ;; + esac + case $ifn in + gif[0-9]*) + ${IFCONFIG_CMD} $ifn create + ;; + *) + _n=$(${IFCONFIG_CMD} gif create) + ${IFCONFIG_CMD} $_n name $ifn + ;; + esac + if [ $? -eq 0 ]; then + _list="${_list}${_prefix}${ifn}" + [ -z "$_prefix" ] && _prefix=' ' + fi + tmpargs=$(get_if_var $ifn gifconfig_IF) + eval ifconfig_${ifn}=\"tunnel \$tmpargs\" + done debug "Cloned: ${_list}" } @@ -1213,11 +1247,16 @@ # clone_down() { - local _prefix _list ifn + local _prefix _list ifn _iflist _prefix= _list= + _iflist=$* - for ifn in ${cloned_interfaces}; do + for ifn in ${cloned_interfaces} ${gif_interfaces}; do + case $_iflist in + ""|$ifn|$ifn\ *|*\ $ifn\ *|*\ $ifn) ;; + *) continue ;; + esac ${IFCONFIG_CMD} -n ${ifn} destroy if [ $? -eq 0 ]; then _list="${_list}${_prefix}${ifn}" @@ -1224,6 +1263,9 @@ [ -z "$_prefix" ] && _prefix=' ' fi done + if [ -n "${_list}" ]; then + echo "Destroyed clone interfaces: ${_list}." + fi debug "Destroyed clones: ${_list}" } @@ -1347,32 +1389,6 @@ done } -# gif_up -# Create gif(4) tunnel interfaces. -gif_up() -{ - local i peers - - for i in ${gif_interfaces}; do - peers=`get_if_var $i gifconfig_IF` - case ${peers} in - '') - continue - ;; - *) - if expr $i : 'gif[0-9][0-9]*$' >/dev/null 2>&1; then - ${IFCONFIG_CMD} $i create >/dev/null 2>&1 - else - gif=`${IFCONFIG_CMD} gif create` - ${IFCONFIG_CMD} $gif name $i - fi - ${IFCONFIG_CMD} $i tunnel ${peers} - ${IFCONFIG_CMD} $i up - ;; - esac - done -} - # ng_fec_create ifn # Configure Fast EtherChannel for interface $ifn. Returns 0 if # FEC arguments were found and configured; returns !0 otherwise. Index: etc/rc.d/netif =================================================================== --- etc/rc.d/netif (revision 253505) +++ etc/rc.d/netif (working copy) @@ -60,18 +60,15 @@ # disable SIGINT (Ctrl-c) when running at startup trap : 2 - # Create cloned interfaces - clone_up - # Create Fast EtherChannel interfaces fec_up + fi - # Create IPv6<-->IPv4 tunnels - gif_up + # Create cloned interfaces + clone_up $cmdifn - # Rename interfaces. - ifnet_rename - fi + # Rename interfaces. + ifnet_rename $cmdifn # Configure the interface(s). network_common ifn_start @@ -101,6 +98,9 @@ # Deconfigure the interface(s) network_common ifn_stop + # Destroy cloned interfaces + clone_down $cmdifn + if [ -f /etc/rc.d/routing -a -n "$cmdifn" ] ; then for _if in $cmdifn; do /etc/rc.d/routing stop any $_if ----Next_Part(Mon_Jul_22_02_45_13_2013_191)---- ----Security_Multipart0(Mon_Jul_22_02_45_13_2013_666)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHsHikACgkQTyzT2CeTzy0BogCdE5YAjK6IoMYAGLRNQtJb85kO uusAoIAK/yibxY5FiY3h67CIL1oXaOjB =uK+4 -----END PGP SIGNATURE----- ----Security_Multipart0(Mon_Jul_22_02_45_13_2013_666)---- From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 18:42:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 319AF123; Sun, 21 Jul 2013 18:42:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5D8CDB; Sun, 21 Jul 2013 18:42:23 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ey16so1176649wid.4 for ; Sun, 21 Jul 2013 11:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=gvEo9R1FYNTezaMP6/i/HNBCRFqut7EFcb0InalTpH4=; b=fIjlLYWhp/C2+hCBaPNHck2jgoCiQ8Y8P3NjpiOBrhZBTinbn685zEiKWReUvc/7xH iizNIlV7ECZbUyJtPEPylurLHb1f5Y+Y8bDVpIwyY3AFSNFJGlQtTtA6vpkEmFRapMkc ug74gUaXEkyUKx7/S71mqkL2mrRc/3WvU6MQ+XRawy54W8cSsm1PC2Y5RZHIoi354lXo mQF3s1vbZK6Y2SGJs/b8rbbQuu++01YBBr6uI5Nu+kP1p84LuhKf8WRBkzfd38GL5VQ+ AzGJQu4rpQVzGYuzcN8AMnstW8/ZAUDG9hyR5qck8qtw5oZbiC97iVWa7mnrf1LZwozu /l1g== MIME-Version: 1.0 X-Received: by 10.180.185.148 with SMTP id fc20mr16628538wic.0.1374432142860; Sun, 21 Jul 2013 11:42:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 21 Jul 2013 11:42:22 -0700 (PDT) Date: Sun, 21 Jul 2013 11:42:22 -0700 X-Google-Sender-Auth: VAgu6KUL3xs6DlCZun0z8LBNGC8 Message-ID: Subject: Enabling clang/llvm for MIPS? From: Adrian Chadd To: freebsd-mips@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 18:42:24 -0000 Hiya, I'd like to start doing test builds of the mips stuff (specifically mips4kc, mips24k and mips74k) on freebsd-head with clang/llvm. What changes are needed to the makefile framework to enable this? Thanks, -Adrian From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 18:51:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8CE5D2FE for ; Sun, 21 Jul 2013 18:51:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA5BD32 for ; Sun, 21 Jul 2013 18:51:55 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6LIpjmp054045; Sun, 21 Jul 2013 21:51:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6LIpjmp054045 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6LIpjFk054044; Sun, 21 Jul 2013 21:51:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Jul 2013 21:51:45 +0300 From: Konstantin Belousov To: Gustau P?rez i Querol Subject: Re: Panic when starting X with Intel KMS Message-ID: <20130721185145.GE5991@kib.kiev.ua> References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> <20130721071842.GZ5991@kib.kiev.ua> <51EBAA76.8020100@entel.upc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mB/CYmFGQzL2EujR" Content-Disposition: inline In-Reply-To: <51EBAA76.8020100@entel.upc.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 18:51:56 -0000 --mB/CYmFGQzL2EujR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 21, 2013 at 11:31:34AM +0200, Gustau P?rez i Querol wrote: >=20 > > The issue happened somewhere before the process exit. Try the patch > > below, the idea is that your overflow count is really big, so the > > wrong-doer could cause underflow when acting. > > > > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > > index 19be4e0..fcdc6af 100644 > > --- a/sys/amd64/amd64/pmap.c > > +++ b/sys/amd64/amd64/pmap.c > > @@ -465,6 +465,9 @@ pmap_resident_count_dec(pmap_t pmap, int count) > > { > > =20 > > PMAP_LOCK_ASSERT(pmap, MA_OWNED); > > + KASSERT(pmap->pm_stats.resident_count >=3D count, > > + ("pmap %p resident count underflow %ld %d", pmap, > > + pmap->pm_stats.resident_count, count)); > > pmap->pm_stats.resident_count -=3D count; > > } > > =20 > Hi, >=20 > the assert doesn't happen (that's resident_count is not bigger than= =20 > count). You can find the complete core at: >=20 > https://dl.dropboxusercontent.com/u/2094962/core.txt.5 I do not understand what do you mean, it seems that core.txt.5 has exactly the assertion fired which I added. Show me the verbose dmesg, including the i915 driver attach. Did the issue started at some moment, or it is a new install which exhibit the problem from the beginning ? As a blind shot, try to revert r252653. I am sure that the serial console would be useful, but I did not decided yet on where to start looking. --mB/CYmFGQzL2EujR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR7C3AAAoJEJDCuSvBvK1BgxgQAKAxBX0NCHdq6+cxEM0lEuy9 y495wag8tzwkues91FnBU0NeverKjOOjaOEEXod4Zez5MkZwPo7TJMM1OTC5P7Zc sRNI7gHZe32ov0ZhZl1W3nEL/v/E2B24aqd3CaG2WqTJpKRXAwWJ89zvmTwjzGyb etJKWKcTaaf7Pd6epKjWOb/idSiqaNfUQ/fPNoaPuMb4QF39kRnNj/LYu8oZVTDD EdxPDfbnukMUoZfTl2uEKt22CI37SzBURy6NwIqem6VNyyN/Yh4Nf38K5auTvXlb QmdWAirapSs3p4dz4zGihW4H0Tu4iCd4cqPojzHFqk+Fs5UaS01Xi3RXpmdB3yyw wcZDaI3bOG68bQxYjb6JPRUFM3xcnsEM/8BHgn0iAkKDivgf/ZBGOz82PKY0Xn6d RAg242RrKCiahPZyIzoIeapKB8JHEtLELO7HKW/pZhdJ5kQRtbs4xKe0AoUEW/nz q39YQcX4WPfLGO+S3olwn6fUXL05dX3M5d+WKyWeGyu+7oRmwjY/f4Op8IsfnZ3T L2o5I2LL+mSQMxf3sDyv7U6IVBMwN/TUn++JoSZa0MDMiY/GUCylzChMMmd5M05Q Q4/6rRRV/TQXwjkLUa59dx6u6ntBBT0I3pdC3OuO1NqkCiLFffvfyWypLkunv+1U fnCI+Ndautk5mvKJkLBF =qgnA -----END PGP SIGNATURE----- --mB/CYmFGQzL2EujR-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 20:05:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1CFBAEF2; Sun, 21 Jul 2013 20:05:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id D67AEFDF; Sun, 21 Jul 2013 20:05:06 +0000 (UTC) Received: from [192.168.1.106] (249-086-128-083.dynamic.caiway.nl [83.128.86.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 560235C5A; Sun, 21 Jul 2013 22:04:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Enabling clang/llvm for MIPS? From: Dimitry Andric In-Reply-To: Date: Sun, 21 Jul 2013 22:04:55 +0200 Content-Transfer-Encoding: 7bit Message-Id: <333C8EE2-1ADC-41EE-A474-9CE12B6E11EA@FreeBSD.org> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1508) Cc: freebsd-current@freebsd.org, freebsd-mips@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 20:05:07 -0000 On Jul 21, 2013, at 20:42, Adrian Chadd wrote: > I'd like to start doing test builds of the mips stuff (specifically > mips4kc, mips24k and mips74k) on freebsd-head with clang/llvm. > > What changes are needed to the makefile framework to enable this? In share/mk/bsd.own.mk, modify these parts: # Clang is only for x86, powerpc and little-endian arm right now, by default. .if ${__T} == "amd64" || ${__T} == "i386" || ${__T:Mpowerpc*} __DEFAULT_YES_OPTIONS+=CLANG CLANG_FULL .elif ${__T} == "arm" || ${__T} == "armv6" __DEFAULT_YES_OPTIONS+=CLANG # GCC is unable to build the full clang on arm, disable it by default. __DEFAULT_NO_OPTIONS+=CLANG_FULL .else __DEFAULT_NO_OPTIONS+=CLANG CLANG_FULL .endif # Clang the default system compiler only on little-endian arm and x86. .if ${__T} == "amd64" || ${__T} == "arm" || ${__T} == "armv6" || \ ${__T} == "i386" __DEFAULT_YES_OPTIONS+=CLANG_IS_CC .else __DEFAULT_NO_OPTIONS+=CLANG_IS_CC .endif The first part enables building clang, the second makes it the default compiler. I take it you only want the first one for now? -Dimitry From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 20:25:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1DA4C26C for ; Sun, 21 Jul 2013 20:25:36 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id A486EFB for ; Sun, 21 Jul 2013 20:25:35 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id r6LKPW4Q029485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Jul 2013 22:25:32 +0200 Received: from [192.168.1.110] (174.Red-79-153-75.dynamicIP.rima-tde.net [79.153.75.174]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id r6LKPU6E020220 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 21 Jul 2013 22:25:32 +0200 Message-ID: <51EC43BA.1000800@entel.upc.edu> Date: Sun, 21 Jul 2013 22:25:30 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleiBpIFF1ZXJvbA==?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Panic when starting X with Intel KMS References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> <20130721071842.GZ5991@kib.kiev.ua> <51EBAA76.8020100@entel.upc.edu> <20130721185145.GE5991@kib.kiev.ua> In-Reply-To: <20130721185145.GE5991@kib.kiev.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Sun, 21 Jul 2013 22:25:32 +0200 (CEST) Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 20:25:36 -0000 Al 21/07/2013 20:51, En/na Konstantin Belousov ha escrit: > > Hi, > > the assert doesn't happen (that's resident_count is not bigger than > count). You can find the complete core at: > > https://dl.dropboxusercontent.com/u/2094962/core.txt.5 > I do not understand what do you mean, it seems that core.txt.5 has > exactly the assertion fired which I added. I was trying to state what you suspected: the condition in the assert did not hold so the kernel paniced. > Show me the verbose dmesg, including the i915 driver attach. Will do it tomorrow morning (I'm UTC+1). > > Did the issue started at some moment, or it is a new install which > exhibit the problem from the beginning ? It was an update of a three months old head machine. A dicotomic search would be a long process (I'd say). > As a blind shot, try to > revert r252653. I tried 252528 (I picked that randomly, only wanting to try to avoid r252695 and r252653 because they state they had to do with pmaps) and it works fine. Tomorrow I'm gonna revert to 252653 and 252652 and see what happens. OFFTOPIC: I used to track src via gitorious but they lag behind and the github repo hasn't the svn revisionm does anyone know of any other git repo with the svn revision? > > I am sure that the serial console would be useful, but I did not decided > yet on where to start looking. Well, if you need some testing via serial be sure it will be possible. -- Salut i força, Gustau --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 20:33:57 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C22473FA for ; Sun, 21 Jul 2013 20:33:57 +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 F0D76147 for ; Sun, 21 Jul 2013 20:33:56 +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 XAA03013; Sun, 21 Jul 2013 23:33:53 +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 1V10KG-000KVj-OY; Sun, 21 Jul 2013 23:33:52 +0300 Message-ID: <51EC4577.4020602@FreeBSD.org> Date: Sun, 21 Jul 2013 23:32:55 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?R3VzdGF1IFDDqXJleiBpIFF1ZXJvbA==?= Subject: Re: Panic when starting X with Intel KMS References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> <20130721071842.GZ5991@kib.kiev.ua> <51EBAA76.8020100@entel.upc.edu> <20130721185145.GE5991@kib.kiev.ua> <51EC43BA.1000800@entel.upc.edu> In-Reply-To: <51EC43BA.1000800@entel.upc.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 20:33:57 -0000 on 21/07/2013 23:25 Gustau Pérez i Querol said the following: > github repo hasn't the svn revision The github repo does have svn revision numbers -- as git notes (google for this term). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 20:52:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7C216846; Sun, 21 Jul 2013 20:52:25 +0000 (UTC) (envelope-from joel@freebsd.org) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id 3F70A237; Sun, 21 Jul 2013 20:52:24 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id E4118E3F07A; Sun, 21 Jul 2013 22:52:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhh6Yir8GNXt; Sun, 21 Jul 2013 22:52:20 +0200 (CEST) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 51C46E3F079; Sun, 21 Jul 2013 22:52:20 +0200 (CEST) Date: Sun, 21 Jul 2013 22:52:18 +0200 From: Joel Dahl To: Konstantin Belousov Subject: Re: Lenovo x220 - hangs on shutdown Message-ID: <20130721205218.GC56585@devbox.vnode.local> References: <20130721072045.GB56585@devbox.vnode.local> <20130721161233.GB5991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130721161233.GB5991@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org, neel@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 20:52:25 -0000 On Sun, Jul 21, 2013 at 07:12:33PM +0300, Konstantin Belousov wrote: > On Sun, Jul 21, 2013 at 09:20:45AM +0200, Joel Dahl wrote: > > On Tue, Jul 16, 2013 at 10:48:35PM +0200, Joel Dahl wrote: > > > Hi, > > > > > > Yesterday I upgraded my Lenovo x220 to the latest current (r253368). Now it hangs when I do a shutdown from an xterm. The screen just goes black and the fan never spins down. It doesn't respond to ping. > > > > > > It didn't do this while I was running a current from mid-June. > > > > > > Any specific revision I should try to back out before I start a time consuming binary search? > > > > I found it. r252652 works. r252653 does not. > > What is the chipset on your machine ? Intel Core i7-2640M / Mobile Intel QM67 Express Chipset > Do you have AMT ? If yes, please configure serial over LAN using AMT > and use it for the console, to obtain the usual debugging information > from the kernel. At least, 'ps' output from ddb is needed. I found "Intel (R) AMT Control" in the BIOS. It's enabled. I haven't figured out how it works yet though. -- Joel From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 21:06:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 75A68B7C for ; Sun, 21 Jul 2013 21:06:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by mx1.freebsd.org (Postfix) with ESMTP id 5049E306 for ; Sun, 21 Jul 2013 21:06:53 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rr13so6250488pbb.20 for ; Sun, 21 Jul 2013 14:06:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Tx6hGYUu44lAldF2HaRJr5CPdS3/U/h5pnJkqDZ1yXQ=; b=efxYdY3zzdRdV9KMxQVpYlVptjXcHLKTqywYkZzzXeOeWy5dey1AcrC8t2iRSlFhLQ RCRgRWCtppxxtTk5dSIJ0fMY5MUJn4QYuRltnN/q8AiwfOcda4amKu6Zg2TA5XCMH/gZ McL34CDW+gkMOv9EUeNhjJlbkSjETlPfyZU6+vYiz7h8V3hDHpH7HxLhkXV/e6IcNE3z XA8KIoXnqgb8zdbEUuFcxxGdisDTOs8LSmaGTmwqvrXDpVQ2FiX8nkGEUa3l2Wl+YvdV HjUDPrfudrtcs7LfJZ4H43VsoRy/z5sfozhrIZx3qSJeBNE2c0DkWiDqDmuo5Vzlg+KZ Dtvw== X-Received: by 10.66.139.227 with SMTP id rb3mr28634909pab.121.1374440807672; Sun, 21 Jul 2013 14:06:47 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ss8sm15852544pab.6.2013.07.21.14.06.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 14:06:46 -0700 (PDT) Sender: Warner Losh Subject: Re: Enabling clang/llvm for MIPS? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <333C8EE2-1ADC-41EE-A474-9CE12B6E11EA@FreeBSD.org> Date: Sun, 21 Jul 2013 15:06:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <685512EE-BEB7-4D42-95D1-AC0454C90AB9@bsdimp.com> References: <333C8EE2-1ADC-41EE-A474-9CE12B6E11EA@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQm2ga4/+nf1cI7IE2VzTTNL5cMKdUy6KNUh6GUT5t+5RjBsaB/jS5w2HRs17hkmVONXGdcD Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-mips@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 21:06:53 -0000 On Jul 21, 2013, at 2:04 PM, Dimitry Andric wrote: >=20 > On Jul 21, 2013, at 20:42, Adrian Chadd wrote: >> I'd like to start doing test builds of the mips stuff (specifically >> mips4kc, mips24k and mips74k) on freebsd-head with clang/llvm. >>=20 >> What changes are needed to the makefile framework to enable this? >=20 > In share/mk/bsd.own.mk, modify these parts: >=20 > # Clang is only for x86, powerpc and little-endian arm right now, by = default. > .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "i386" || ${__T:Mpowerpc*} > __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_FULL > .elif ${__T} =3D=3D "arm" || ${__T} =3D=3D "armv6" > __DEFAULT_YES_OPTIONS+=3DCLANG > # GCC is unable to build the full clang on arm, disable it by default. > __DEFAULT_NO_OPTIONS+=3DCLANG_FULL > .else > __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_FULL > .endif > # Clang the default system compiler only on little-endian arm and x86. > .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "arm" || ${__T} =3D=3D = "armv6" || \ > ${__T} =3D=3D "i386" > __DEFAULT_YES_OPTIONS+=3DCLANG_IS_CC > .else > __DEFAULT_NO_OPTIONS+=3DCLANG_IS_CC > .endif >=20 > The first part enables building clang, the second makes it the default > compiler. I take it you only want the first one for now? make buildworld WITH_CLANG=3Dt WITHOUT_CLANG_FULL=3Dt = WITHOUT_CLANG_IS_CC=3Dt Warner= From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 21:50:46 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B58D3F4; Sun, 21 Jul 2013 21:50:46 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) by mx1.freebsd.org (Postfix) with ESMTP id 56D5D627; Sun, 21 Jul 2013 21:50:45 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id A7ECFBDD4E; Sun, 21 Jul 2013 21:50:38 +0000 (UTC) Date: Sun, 21 Jul 2013 23:50:38 +0200 From: Jeremie Le Hen To: Alan Cox Subject: Re: Fix for sys_munlock(2) with racct Message-ID: <20130721215038.GE13628@caravan.chchile.org> Mail-Followup-To: Alan Cox , trasz@FreeBSD.org, Alan Cox , freebsd-current@FreeBSD.org, Konstantin Belousov References: <20130720112218.GD13628@caravan.chchile.org> <115EDC04-4B95-4FB5-9092-515188D8ADA7@rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <115EDC04-4B95-4FB5-9092-515188D8ADA7@rice.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jeremie Le Hen , Alan Cox , freebsd-current@FreeBSD.org, trasz@FreeBSD.org, Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 21:50:46 -0000 On Sat, Jul 20, 2013 at 08:33:35PM -0700, Alan Cox wrote: > > On Jul 20, 2013, at 4:22 AM, Jeremie Le Hen wrote: > > > Hi Edward, Alan, > > > > I plan to commit the following patch: > > http://people.freebsd.org/~jlh/racct_munlock.diff > > > > This solves the following panic: > > > > panic: racct_sub: freeing 301989888 of resource 5, which is more than allocated 73728 for pwsafe (pid 4177) > > > > The problem is that the racct code in sys_munlock() trusts too much the > > user's input. vm_map_unwire_count() now returns how much memory has > > really been unwired. > > > > Any objection? > > > Can you elaborate on what you mean by "sys_munlock() trusts too much > the user's input." munlock(2) is supposed to return ENOMEM if any > addresses within the specified range are not backed by valid mappings. > (Valid mappings with PROT_NONE access are something of a gray area > here.) However, it is not error for a to call munlock() on a range > that isn't locked, or to call it a second, third, etc. time on the > same range. Is that what is provoking your panic? I'm using sysutils/pwsafe and it seems to mlock(2) 18 pages (end - start = 73728 bytes) but then munlock(2) 73728 pages :-). vm_map_unwire() seems to do the right thing with those buggy boundaries, but then the racct code assumes that those boundaries were correct as long as vm_map_unwire() returned successfully. This is what causes the assertion failure. > By the way, sys_mlock() uses a simpler approach to deal with a similar > situation: > > error = vm_map_wire(map, start, end, > VM_MAP_WIRE_USER | VM_MAP_WIRE_NOHOLES); > #ifdef RACCT > if (error != KERN_SUCCESS) { > PROC_LOCK(proc); > racct_set(proc, RACCT_MEMLOCK, > ptoa(pmap_wired_count(map->pmap))); > PROC_UNLOCK(proc); > } > #endif > > However, the code in sys_mlock() for maintaining RACCT_MEMLOCK, > including the above snippet, is race-y. Two simultaneous callers to > sys_mlock() will produce incorrect results. (I haven't looked at > sys_mlockall() or vm_map_growstack().) Ok, I will commit that as the first bandaid then. > Also, a wired mapping can be destroyed by calling munmap(2) without > first calling munlock(2), in which case, RACCT_MEMLOCK will be > incorrect. So I think the right way to tackle this is to handle racct in the vm layer rather than at the syscall layer. vm_fault_{wire,unwire}() look like natural places for this, but racct functions require the struct proc to be locked. Any idea how to handle this? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 22:41:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 816CD620 for ; Sun, 21 Jul 2013 22:41:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6E9823 for ; Sun, 21 Jul 2013 22:41:13 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEANdi7FGDaFve/2dsb2JhbABahAuDCr0mgSx0gk6BCwINGQJfiCOWRY5+kG+BKI46gxiBIQOpKoMuIIFu X-IronPort-AV: E=Sophos;i="4.89,715,1367985600"; d="scan'208";a="40819562" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 21 Jul 2013 18:41:12 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A00DBB411A for ; Sun, 21 Jul 2013 18:41:12 -0400 (EDT) Date: Sun, 21 Jul 2013 18:41:12 -0400 (EDT) From: Rick Macklem To: FreeBSD Current Message-ID: <1345133141.362200.1374446472640.JavaMail.root@uoguelph.ca> Subject: NFSv4.1 server for testing/review MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 21 Jul 2013 22:41:14 -0000 Hi, Just in case anyone is interested, I have put an experimental NFSv4.1 server in the svn repository under: projects/nfsv4.1-server It lacks required support for backchannels. However, since it never issues delegations at this point, it seems to work ok against the extant NFSv4.1 clients that I have had the opportunity to test it against. I will be adding backchannel support sometime soon and hope to merge it into head sometime after that. rick From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 07:30:40 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9BF07ADA; Mon, 22 Jul 2013 07:30:40 +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 58C7E2680; Mon, 22 Jul 2013 07:30:39 +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 KAA09015; Mon, 22 Jul 2013 10:30:37 +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 1V1AZp-000OET-5E; Mon, 22 Jul 2013 10:30:37 +0300 Message-ID: <51ECDF64.2020704@FreeBSD.org> Date: Mon, 22 Jul 2013 10:29:40 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current , freebsd-fs@FreeBSD.org Subject: Re: r253070 and "disappearing" zpool References: <20130710180548.GA2151@glenbarber.us> In-Reply-To: <20130710180548.GA2151@glenbarber.us> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Glen Barber X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 07:30:40 -0000 [turning this into a public discussion with Glen's permission] on 10/07/2013 21:05 Glen Barber said the following: > Hi, > > My setup is like this: > > root@nucleus:/usr/src # zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > zboot0 9.94G 379M 9.57G 3% 1.00x ONLINE - > zroot0 159G 113G 46.2G 70% 1.00x ONLINE - > > root@nucleus:/usr/src # zpool get bootfs > NAME PROPERTY VALUE SOURCE > zboot0 bootfs - default > zroot0 bootfs - default > > root@nucleus:/usr/src # zfs list zboot0 > NAME USED AVAIL REFER MOUNTPOINT > zboot0 379M 9.41G 281M /bootdir > > root@nucleus:/usr/src # zfs list zroot0 > NAME USED AVAIL REFER MOUNTPOINT > zroot0 113G 43.7G 147M / > > 'zroot0' is a GELI-backed pool, so I have this to fix the boot process: > > root@nucleus:/usr/src # ll /boot > lrwxr-xr-x 1 root wheel 12 Aug 25 2012 /boot@ -> bootdir/boot > > I upgraded from head/ on July 1 to r253159, and when I rebooted the > system, I could correctly boot from the "/bootdir/boot". Once I enter > the GELI passphrase, "/" (from zroot0) is mounted. Normally, everything > would be okay at that point, but since the upgrade, "/bootdir/boot" > disappears because the zboot0 pool is not imported as it was before. > > Any thoughts? I think that this setup (on ZFS level) is quite untypical, although not impossible on FreeBSD (and perhaps only FreeBSD). It's untypical because you have separate boot pool (where loader, loader.conf and kernel are taken from) and root pool (where "/" is mounted from). There is this "magic" zpool.cache file that essentially tells what pools should be automatically imported. On FreeBSD this file lives in /boot/zfs directory while originally (in Solaris and its descendants) its home is /etc/zfs. Until recently FreeBSD could use only zpool.cache from a boot pool and, in fact, if a root pool was different from a boot pool the root pool had to be in zpool.cache. I changed things a little bit and now a root pool does not have to be in zpool.cache. Also, now zpool.cache is taken from the root pool, or to be more precise from a root filesystem (whatever happens to be /boot/zfs/zpool.cache after "/" is mounted). I am considering if perhaps now we should move zpool.cache back to /etc/zfs/. So, I see three ways of resolving the problem that my changes caused for your configuration. 1. [the easiest] Put zpool.cache loading instructions that used to be in defaults/loader.conf into your loader.conf. This way everything should work as before -- zpool.cache would be loaded from your boot pool. 2. Somehow (I don't want to go into any technical details here) arrange that your root pool has /boot/zfs/zpool.cache that describes your boot pool. This is probably hard given that your /boot is a symlink at the moment. This probably would be easier to achieve if zpool.cache lived in /etc/zfs. 3. [my favorite] Remove an artificial difference between your boot and root pools, so that they are a single root+boot pool (as zfs gods intended). As far as I understand your setup, you use GELI to protect some sensitive data. Apparently your kernel is not sensitive data, so I wonder if your /bin/sh or /sbin/init are really sensitive either. So perhaps you can arrange your unencrypted pool to hold all of the base system (boot + root) and put all your truly sensitive filesystems (like e.g. /home or /var/data or /opt/xyz) onto your encrypted pool. ZFS is really flexible, you can use mountpoint and canmount properties to place your filesystems from same or different pools into whatever file namespace hierarchy you desire. Remember that your filesystem hierarchy in the mount namespace does not always have to be the same as your ZFS dataset hierarchy. I hope that this makes sense to you. If you have any additional questions, please do not hesitate. P.S. ZFS/FreeBSD boot process is extremely flexible. For example zfsboot can take zfsloader from pool1/fsA, zfsloader can boot kernel from pool2/fsB and kernel can mount / from pool3/fsC. Of these 3 filesystems from where should zpool.cache be taken? My firm opinion is that it should be taken from / (pool3/fsC in the example above). Because it is the root filesystem that defines what a system is going to do ultimately: what daemons are started, with what configurations, etc. And thus it should also determine what pools to auto-import. We can say that zpool.cache is analogous to /etc/fstab in this respect. So I understand that my change causes a problem for a setup like yours, but I believe that the change is correct. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 08:59:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 08AD8E44 for ; Mon, 22 Jul 2013 08:59:38 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from graal.it-profi.org.ua (graal.shurik.kiev.ua [193.239.74.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B8D162B9A for ; Mon, 22 Jul 2013 08:59:36 +0000 (UTC) Received: from [217.76.201.82] (helo=thinkpad.it-profi.org.ua) by graal.it-profi.org.ua with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V1BIO-000LG7-93 for freebsd-current@freebsd.org; Mon, 22 Jul 2013 11:16:40 +0300 Message-ID: <51ECEA63.9010508@shurik.kiev.ua> Date: Mon, 22 Jul 2013 11:16:35 +0300 From: Alexandr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 217.76.201.82 X-SA-Exim-Mail-From: shuriku@shurik.kiev.ua X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on graal.it-profi.org.ua X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 Subject: Re: where is the startkde file of kde4 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on graal.it-profi.org.ua) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 08:59:38 -0000 21.07.2013 16:13, Robin Lehrmann пишет: > hello mailing-list, > I have installed kde4 on the current freebsd. > > Now I want to start it but I don't find the start script in /usr/local/kde4/bin > > I try the scripts kde4 kded4 kdeinit4 but I get always the error "$Display is Not Set" > > how can I set the display or start kde4? > > - Robin Lehrmann > Do you have kdm4_enable="YES" in your rc.conf? If you not, please add it and use service kdm4 start From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 09:51:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ECE0ED8B; Mon, 22 Jul 2013 09:51:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8C97E2F20; Mon, 22 Jul 2013 09:51:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6M9pOj6047533; Mon, 22 Jul 2013 12:51:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6M9pOj6047533 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6M9pOi1047532; Mon, 22 Jul 2013 12:51:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 22 Jul 2013 12:51:24 +0300 From: Konstantin Belousov To: Joel Dahl Subject: Re: Lenovo x220 - hangs on shutdown Message-ID: <20130722095124.GH5991@kib.kiev.ua> References: <20130721072045.GB56585@devbox.vnode.local> <20130721161233.GB5991@kib.kiev.ua> <20130721205218.GC56585@devbox.vnode.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QdA8+0Hc+u1HcecE" Content-Disposition: inline In-Reply-To: <20130721205218.GC56585@devbox.vnode.local> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org, neel@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 09:51:31 -0000 --QdA8+0Hc+u1HcecE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 21, 2013 at 10:52:18PM +0200, Joel Dahl wrote: > On Sun, Jul 21, 2013 at 07:12:33PM +0300, Konstantin Belousov wrote: > > On Sun, Jul 21, 2013 at 09:20:45AM +0200, Joel Dahl wrote: > > > On Tue, Jul 16, 2013 at 10:48:35PM +0200, Joel Dahl wrote: > > > > Hi, > > > >=20 > > > > Yesterday I upgraded my Lenovo x220 to the latest current (r253368)= =2E Now it hangs when I do a shutdown from an xterm. The screen just goes b= lack and the fan never spins down. It doesn't respond to ping. > > > >=20 > > > > It didn't do this while I was running a current from mid-June. > > > >=20 > > > > Any specific revision I should try to back out before I start a tim= e consuming binary search? > > >=20 > > > I found it. r252652 works. r252653 does not. > >=20 > > What is the chipset on your machine ? >=20 > Intel Core i7-2640M / Mobile Intel QM67 Express Chipset >=20 > > Do you have AMT ? If yes, please configure serial over LAN using AMT > > and use it for the console, to obtain the usual debugging information > > from the kernel. At least, 'ps' output from ddb is needed. >=20 > I found "Intel (R) AMT Control" in the BIOS. It's enabled. I haven't figu= red > out how it works yet though. You need another machine, where you should install amtterm. On the target, use the loader.conf to redirect console to=20 AMT Serial over LAN device. On my test machine, I have (output from pciconf -lv) uart2@pci0:0:22:3: class=3D0x070002 card=3D0x200a8086 chip=3D0x1c3d8086 r= ev=3D0x04 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family KT Controller' class =3D simple comms subclass =3D UART and then I put into loader.conf console=3D"comconsole" comconsole_pcidev=3D"0:22:3" Connect to the target with amtterm. Note that during the PCI bus scan the connection could be lost, you would need to reconnect. You need to set up AMT in the BIOS, including enable of the SoL, remote connections, password etc. Intel policy on the password strength is distinctly annoying. --QdA8+0Hc+u1HcecE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR7QCcAAoJEJDCuSvBvK1ByAIP/jmGCKUpcMtifeLiHbXx1C+b Q26igffDy7u6kCsye6ZAjQYVBGwuaqwRTEWTi772+FEPu9zs3caKlOyczcr/2h2o f0sCwKu93zRwVg1UjdJGhdwptYc/hPIg7LQg4Hqc+8TBoLa7QD/tI5WGIP+vMdKu AnR0smRshmP7Kp047o5i/aMkLBfGGyY+fPZY7lCRr6GFwDKZpVZEuceNJIzDMMxX kW4AYa2WmC5EXPB0Cwbe9jlkPlkABMtTmgvNfX4ngqI9DBJo2pd8LsJjUfUB2WR/ AtIXft0XX45ObXNiULYWW+0EHgbx6h8lgzYPeFHCjmEauJ85VuZrEPaZdiWj36bz fGkllYZfcPgaJnKQAFrokDz5tK45S5cTGzNMmQoVH4BndcFaTj5VanX8uH/x28OO b812GyPBiMUOc/PIny03b4Ty0ZzCaOXsxLgEfPZ+r6zBA7e/mBRt7T+ClyMRVtN4 9tXpt9FclcD6sFJyQxbKEY8RB3ur71Jne4vgVGHRycbt4ZudmMWs4v2FwamJ/Rna Mwpk3+CUd6RqxAcm7m2GLVBqLtEOKEvI72oj2iWNuvJ+WN/mxaX6QXPH3YjA58Ai 1x3WZWVzjkGDxjV9yBo3MymHC4X50oill6BYInU9exjyvuQmxLP4L+ELf2DeEg9/ BEomWvs5tmXjyFLV97ye =q4CO -----END PGP SIGNATURE----- --QdA8+0Hc+u1HcecE-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 10:44:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A7BEFCD4 for ; Mon, 22 Jul 2013 10:44:01 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38A0222FD for ; Mon, 22 Jul 2013 10:44:00 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id r6MAhwWQ005993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Jul 2013 12:43:58 +0200 Received: from [10.0.2.151] ([147.83.40.10]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id r6MAhukZ004208 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 12:43:58 +0200 Message-ID: <51ED0CEC.80307@entel.upc.edu> Date: Mon, 22 Jul 2013 12:43:56 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleiBpIFF1ZXJvbA==?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Panic when starting X with Intel KMS References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> <20130721071842.GZ5991@kib.kiev.ua> <51EBAA76.8020100@entel.upc.edu> <20130721185145.GE5991@kib.kiev.ua> <51EC43BA.1000800@entel.upc.edu> In-Reply-To: <51EC43BA.1000800@entel.upc.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Mon, 22 Jul 2013 12:43:58 +0200 (CEST) Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 10:44:01 -0000 >> Show me the verbose dmesg, including the i915 driver attach. > > Will do it tomorrow morning (I'm UTC+1). > > Here you have the verbose dmesg and the i915 before the panic: https://dl.dropboxusercontent.com/u/2094962/panic_r252653.tar.gz >> As a blind shot, try to >> revert r252653. r252652 works OK. r252653 panics. Any other info let me you. -- Salut i força, Gustau --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 11:19:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16D4AF4 for ; Mon, 22 Jul 2013 11:19:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7FF1A26ED for ; Mon, 22 Jul 2013 11:19:47 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6MBJeE9065514; Mon, 22 Jul 2013 14:19:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6MBJeE9065514 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6MBJeOg065513; Mon, 22 Jul 2013 14:19:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 22 Jul 2013 14:19:40 +0300 From: Konstantin Belousov To: Gustau P??rez i Querol Subject: Re: Panic when starting X with Intel KMS Message-ID: <20130722111940.GK5991@kib.kiev.ua> References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> <20130721071842.GZ5991@kib.kiev.ua> <51EBAA76.8020100@entel.upc.edu> <20130721185145.GE5991@kib.kiev.ua> <51EC43BA.1000800@entel.upc.edu> <51ED0CEC.80307@entel.upc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cjNfFEtZoUGcCUIb" Content-Disposition: inline In-Reply-To: <51ED0CEC.80307@entel.upc.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 11:19:48 -0000 --cjNfFEtZoUGcCUIb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2013 at 12:43:56PM +0200, Gustau P??rez i Querol wrote: > >> As a blind shot, try to > >> revert r252653. >=20 > r252652 works OK. r252653 panics. What if, instead of reverting r252653, apply the following: diff --git a/sys/vm/vm_phys.c b/sys/vm/vm_phys.c index 66f3b0c..78f07f7 100644 --- a/sys/vm/vm_phys.c +++ b/sys/vm/vm_phys.c @@ -547,6 +547,8 @@ vm_phys_fictitious_reg_range(vm_paddr_t start, vm_paddr= _t end, pi =3D atop(start); if (pi >=3D first_page && atop(end) < vm_page_array_size) { fp =3D &vm_page_array[pi - first_page]; + for (i =3D 0; i < page_count; i++) + fp[i].flags =3D 0; malloced =3D FALSE; } else #endif ? --cjNfFEtZoUGcCUIb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR7RVLAAoJEJDCuSvBvK1B5BcP/3W/hNXi2lORMMEwRZhz6v6h Wzkj9STFRV1UqIkmem0s8XHwasKx5u7zThmZeYOXT+fEyD97gJrgwKyulBu+CaCP JezhKlvNncvZWeUvFviFjfbDxzqBiecqo8+UfYXJG6kjfBnwr8PDs5FUQff3/owj HG7ptcqUHDhOqdfxPzjsgMNFgo5gA94zeNxrxHlNvuWkw9AiwH7mPzppJ8UCt1a8 qrEekGiEde30mmWpp1J2HLxJzDxMiK6L+TKKQNywzRvpjigoazU/jPeaxcihgozM 0eZrb5PY6c+Ni/zdsYfRQj2C2wpRopbgwokxlYAbKmTOy7dqT+K4vLUgGgLFjXi9 5xGO0Qe9iB7tBhdZruX0R2oVPbcvMB0qIKIufz5yBvy+P2eOm/NS0glGz9U+k5Vp gmhE6pJg9zC0cOPBEhHE5vycoIHUUJHoyHisV4oMlOvIbKJbORwZgmC8yyxJ6D/J 7AoLnMf49rCucH6h4e42AonFIU0XxgnKC4CIb6ozeFImi7KldOkxjLkhBO8J1ZE+ 1l7Px26wbSawUjuntXvRZFpxKnix6Alx4sESsNII17eVLa2uxgUYO+pK7jnI7DoX UMZojA50rZ6sWK59b+aCr677Z8Bgi48r4vhhBlyK7Pms8QlZ5oX2F2DIesCv1xzU Ub5T9AC5rxablWwj/8Te =1n0e -----END PGP SIGNATURE----- --cjNfFEtZoUGcCUIb-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 12:28:54 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7CD13560; Mon, 22 Jul 2013 12:28:54 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4312F2AFF; Mon, 22 Jul 2013 12:28:53 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id r6MCSqTI029435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 22 Jul 2013 07:28:52 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Mon, 22 Jul 2013 07:28:43 -0500 From: "Teske, Devin" To: Andriy Gapon Subject: Re: r253070 and "disappearing" zpool Thread-Topic: r253070 and "disappearing" zpool Thread-Index: AQHOhq1kEkFm6CmVtUilt1UjZinLKZlw9HiA Date: Mon, 22 Jul 2013 12:28:43 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FD4633@ltcfiswmsgmb21> References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> In-Reply-To: <51ECDF64.2020704@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-22_02:2013-07-19,2013-07-22,1970-01-01 signatures=0 Cc: "freebsd-fs@freebsd.org" , Glen Barber , FreeBSD Current , Devin Teske X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 12:28:54 -0000 On Jul 22, 2013, at 12:29 AM, Andriy Gapon wrote: >=20 > [turning this into a public discussion with Glen's permission] >=20 > on 10/07/2013 21:05 Glen Barber said the following: >> Hi, >>=20 >> My setup is like this: >>=20 >> root@nucleus:/usr/src # zpool list >> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >> zboot0 9.94G 379M 9.57G 3% 1.00x ONLINE - >> zroot0 159G 113G 46.2G 70% 1.00x ONLINE - >>=20 >> root@nucleus:/usr/src # zpool get bootfs >> NAME PROPERTY VALUE SOURCE >> zboot0 bootfs - default >> zroot0 bootfs - default >>=20 >> root@nucleus:/usr/src # zfs list zboot0 >> NAME USED AVAIL REFER MOUNTPOINT >> zboot0 379M 9.41G 281M /bootdir >>=20 >> root@nucleus:/usr/src # zfs list zroot0 >> NAME USED AVAIL REFER MOUNTPOINT >> zroot0 113G 43.7G 147M / >>=20 >> 'zroot0' is a GELI-backed pool, so I have this to fix the boot process: >>=20 >> root@nucleus:/usr/src # ll /boot >> lrwxr-xr-x 1 root wheel 12 Aug 25 2012 /boot@ -> bootdir/boot >>=20 >> I upgraded from head/ on July 1 to r253159, and when I rebooted the >> system, I could correctly boot from the "/bootdir/boot". Once I enter >> the GELI passphrase, "/" (from zroot0) is mounted. Normally, everything >> would be okay at that point, but since the upgrade, "/bootdir/boot" >> disappears because the zboot0 pool is not imported as it was before. >>=20 >> Any thoughts? >=20 > I think that this setup (on ZFS level) is quite untypical, although not > impossible on FreeBSD (and perhaps only FreeBSD). > It's untypical because you have separate boot pool (where loader, loader.= conf > and kernel are taken from) and root pool (where "/" is mounted from). >=20 > There is this "magic" zpool.cache file that essentially tells what pools = should > be automatically imported. On FreeBSD this file lives in /boot/zfs direc= tory > while originally (in Solaris and its descendants) its home is /etc/zfs. >=20 > Until recently FreeBSD could use only zpool.cache from a boot pool and, i= n fact, > if a root pool was different from a boot pool the root pool had to be in > zpool.cache. > I changed things a little bit and now a root pool does not have to be in > zpool.cache. Also, now zpool.cache is taken from the root > pool, or to be more precise from a root filesystem (whatever happens to be > /boot/zfs/zpool.cache after "/" is mounted). I am considering if perhaps= now we > should move zpool.cache back to /etc/zfs/. >=20 > So, I see three ways of resolving the problem that my changes caused for = your > configuration. >=20 > 1. [the easiest] Put zpool.cache loading instructions that used to be in > defaults/loader.conf into your loader.conf. This way everything should w= ork as > before -- zpool.cache would be loaded from your boot pool. >=20 > 2. Somehow (I don't want to go into any technical details here) arrange t= hat > your root pool has /boot/zfs/zpool.cache that describes your boot pool. = This is > probably hard given that your /boot is a symlink at the moment. This pro= bably > would be easier to achieve if zpool.cache lived in /etc/zfs. >=20 > 3. [my favorite] Remove an artificial difference between your boot and r= oot > pools, so that they are a single root+boot pool (as zfs gods intended). = As far > as I understand your setup, you use GELI to protect some sensitive data. > Apparently your kernel is not sensitive data, so I wonder if your /bin/sh= or > /sbin/init are really sensitive either. > So perhaps you can arrange your unencrypted pool to hold all of the base = system > (boot + root) and put all your truly sensitive filesystems (like e.g. /ho= me or > /var/data or /opt/xyz) onto your encrypted pool. > ZFS is really flexible, you can use mountpoint and canmount properties to= place > your filesystems from same or different pools into whatever file namespace > hierarchy you desire. Remember that your filesystem hierarchy in the mou= nt > namespace does not always have to be the same as your ZFS dataset hierarc= hy. >=20 > I hope that this makes sense to you. > If you have any additional questions, please do not hesitate. >=20 > P.S. > ZFS/FreeBSD boot process is extremely flexible. For example zfsboot can = take > zfsloader from pool1/fsA, zfsloader can boot kernel from pool2/fsB and ke= rnel > can mount / from pool3/fsC. Of these 3 filesystems from where should > zpool.cache be taken? > My firm opinion is that it should be taken from / (pool3/fsC in the examp= le > above). Because it is the root filesystem that defines what a system is = going > to do ultimately: what daemons are started, with what configurations, etc. > And thus it should also determine what pools to auto-import. > We can say that zpool.cache is analogous to /etc/fstab in this respect. >=20 > So I understand that my change causes a problem for a setup like yours, b= ut I > believe that the change is correct. >=20 +1 for zpool.cache on / (pool3/fsC in last example) --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 14:38:07 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7838CDB5; Mon, 22 Jul 2013 14:38:07 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE94D223D; Mon, 22 Jul 2013 14:38:06 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r6MEbmN1014935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 23:37:59 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r6MEbl1T030354; Mon, 22 Jul 2013 23:37:48 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 22 Jul 2013 23:37:04 +0900 (JST) Message-Id: <20130722.233704.43939809189059350.hrs@allbsd.org> To: current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: CFT: cloned_interfaces and gifconfig in rc.d/netif From: Hiroki Sato In-Reply-To: <20130722.024513.95685108976349294.hrs@allbsd.org> References: <20130722.024513.95685108976349294.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Mon_Jul_22_23_37_04_2013_579)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 22 Jul 2013 23:37:59 +0900 (JST) X-Spam-Status: No, score=-90.4 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,QENCPTR2,RCVD_IN_PBL,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: freebsd-rc@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 14:38:07 -0000 ----Security_Multipart0(Mon_Jul_22_23_37_04_2013_579)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Jul_22_23_37_04_2013_233)--" Content-Transfer-Encoding: 7bit ----Next_Part(Mon_Jul_22_23_37_04_2013_233)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiroki Sato wrote in <20130722.024513.95685108976349294.hrs@allbsd.org>: hr> Hi, hr> hr> The attached patch allows rc.d/netif to create IFs in hr> $cloned_interfaces when interface name(s) is specified. For example, hr> when the following lines are in rc.conf: hr> hr> cloned_interfaces="bridge0 bridge1" hr> ifconfig_bridge0="..." hr> ifconfig_bridge1="..." hr> hr> The following commands create the interfaces and destroy them. hr> hr> # /etc/rc.d/netif start bridge0 bridge1 hr> # /etc/rc.d/netif stop bridge0 bridge1 hr> hr> netif cloneup/clonedown does this without the patch, but it cannot hr> configure the interfaces and does not support clean teardown. hr> hr> Also, routines which handle $gif_interfaces are merged into ones for hr> $cloned_interfaces. ifconfig_gifN and other variants did not work hr> with gif interfaces defined in $gif_interfaces. The patch solves hr> this issue. hr> hr> Basically there should be no functionality regression for the hr> existing configurations. Can anyone who are using $gif_interfaces hr> and/or $cloned_interfaces test this? I would like to know if there is hr> regression or not. A revised version based on feedback which I received in private emails is attached. This includes rc.conf(5) change explaining the new variables. The following is a brief description of the changes: ----- - Reimplement gif_interfaces as a variant of $cloned_interfaces. Newly-configured systems should use $cloned_interfaces. - Call clone_{up,down}() in rc.d/netif {start,stop}. - Add rc.d/netif clear. The "clear" argument is basically equivalent to "stop" but it does not call clone_down(). - Add "ifname:sticky" keyword into $cloned_interfaces. If :sticky is specified, the interface will not be destroyed in rc.d/netif stop. - Add cloned_interfaces_sticky={YES,NO}. This variable globally sets :sticky keyword above for all interfaces. The default value is NO. ---- -- Hiroki ----Next_Part(Mon_Jul_22_23_37_04_2013_233)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="network.subr.gifconfig.20130722-2.diff" - Reimplement gif_interfaces as a variant of $cloned_interfaces. Newly-configured systems should use $cloned_interfaces. - Call clone_{up,down}() in rc.d/netif {start,stop}. - Add rc.d/netif clear. The "clear" argument is basically equivalent to "stop" but it does not call clone_down(). - Add "ifname:sticky" keyword into $cloned_interfaces. If :sticky is specified, the interface will not be destroyed in rc.d/netif stop. - Add cloned_interfaces_sticky={YES,NO}. This variable globally sets :sticky keyword above for all interfaces. The default value is NO. MFC after: 3 days ==== Index: etc/network.subr =================================================================== --- etc/network.subr (revision 253520) +++ etc/network.subr (working copy) @@ -660,6 +660,11 @@ ipv4_down() IFS="$_ifs" for _inet in $inetList ; do # get rid of extraneous line + case $_inet in + "") break ;; + inet\ *) ;; + *) continue ;; + esac [ -z "$_inet" ] && break _inet=`expr "$_inet" : '.*\(inet \([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}\).*'` @@ -1192,12 +1197,23 @@ ifscript_down() # clone_up() { - local _prefix _list ifn + local _prefix _list ifn ifopt _iflist _n tmpargs _prefix= _list= + _iflist=$* # create_args_IF for ifn in ${cloned_interfaces}; do + # Parse ifn:ifopt. + OIFS=$IFS; IFS=:; set -- $ifn; ifn=$1; ifopt=$2; IFS=$OIFS + case $_iflist in + ""|$ifn|$ifn\ *|*\ $ifn\ *|*\ $ifn) ;; + *) continue ;; + esac + # Skip if ifn already exists. + if ${IFCONFIG_CMD} $ifn > /dev/null 2>&1; then + continue + fi ${IFCONFIG_CMD} ${ifn} create `get_if_var ${ifn} create_args_IF` if [ $? -eq 0 ]; then _list="${_list}${_prefix}${ifn}" @@ -1204,6 +1220,39 @@ clone_up() [ -z "$_prefix" ] && _prefix=' ' fi done + if [ -n "$gif_interfaces" ]; then + warn "\$gif_interfaces is obsolete. Use \$cloned_interfaces instead." + fi + for ifn in ${gif_interfaces}; do + # Parse ifn:ifopt. + OIFS=$IFS; IFS=:; set -- $ifn; ifn=$1; ifopt=$2; IFS=$OIFS + case $_iflist in + ""|$ifn|$ifn\ *|*\ $ifn\ *|*\ $ifn) ;; + *) continue ;; + esac + # Skip if ifn already exists. + if ${IFCONFIG_CMD} $ifn > /dev/null 2>&1; then + continue + fi + case $ifn in + gif[0-9]*) + ${IFCONFIG_CMD} $ifn create + ;; + *) + _n=$(${IFCONFIG_CMD} gif create) + ${IFCONFIG_CMD} $_n name $ifn + ;; + esac + if [ $? -eq 0 ]; then + _list="${_list}${_prefix}${ifn}" + [ -z "$_prefix" ] && _prefix=' ' + fi + tmpargs=$(get_if_var $ifn gifconfig_IF) + eval ifconfig_${ifn}=\"tunnel \$tmpargs\" + done + if [ -n "${_list}" ]; then + echo "Created clone interfaces: ${_list}." + fi debug "Cloned: ${_list}" } @@ -1213,11 +1262,29 @@ clone_up() # clone_down() { - local _prefix _list ifn + local _prefix _list ifn ifopt _iflist _prefix= _list= + _iflist=$* - for ifn in ${cloned_interfaces}; do + : ${cloned_interfaces_sticky:=NO} + if checkyesno cloned_interfaces_sticky; then + return 1 + fi + for ifn in ${cloned_interfaces} ${gif_interfaces}; do + # Parse ifn:ifopt. + OIFS=$IFS; IFS=:; set -- $ifn; ifn=$1; ifopt=$2; IFS=$OIFS + case $ifopt in + sticky) continue ;; + esac + case $_iflist in + ""|$ifn|$ifn\ *|*\ $ifn\ *|*\ $ifn) ;; + *) continue ;; + esac + # Skip if ifn does not exist. + if ! ${IFCONFIG_CMD} $ifn > /dev/null 2>&1; then + continue + fi ${IFCONFIG_CMD} -n ${ifn} destroy if [ $? -eq 0 ]; then _list="${_list}${_prefix}${ifn}" @@ -1224,6 +1291,9 @@ clone_down() [ -z "$_prefix" ] && _prefix=' ' fi done + if [ -n "${_list}" ]; then + echo "Destroyed clone interfaces: ${_list}." + fi debug "Destroyed clones: ${_list}" } @@ -1347,32 +1417,6 @@ ng_create_one() done } -# gif_up -# Create gif(4) tunnel interfaces. -gif_up() -{ - local i peers - - for i in ${gif_interfaces}; do - peers=`get_if_var $i gifconfig_IF` - case ${peers} in - '') - continue - ;; - *) - if expr $i : 'gif[0-9][0-9]*$' >/dev/null 2>&1; then - ${IFCONFIG_CMD} $i create >/dev/null 2>&1 - else - gif=`${IFCONFIG_CMD} gif create` - ${IFCONFIG_CMD} $gif name $i - fi - ${IFCONFIG_CMD} $i tunnel ${peers} - ${IFCONFIG_CMD} $i up - ;; - esac - done -} - # ng_fec_create ifn # Configure Fast EtherChannel for interface $ifn. Returns 0 if # FEC arguments were found and configured; returns !0 otherwise. Index: etc/rc.d/netif =================================================================== --- etc/rc.d/netif (revision 253505) +++ etc/rc.d/netif (working copy) @@ -38,7 +38,8 @@ start_cmd="network_start" stop_cmd="network_stop" cloneup_cmd="clone_up" clonedown_cmd="clone_down" -extra_commands="cloneup clonedown" +clear_cmd="clear" +extra_commands="cloneup clonedown clear" cmdifn= set_rcvar_obsolete ipv6_enable ipv6_activate_all_interfaces @@ -60,18 +61,15 @@ network_start() # disable SIGINT (Ctrl-c) when running at startup trap : 2 - # Create cloned interfaces - clone_up - # Create Fast EtherChannel interfaces fec_up + fi - # Create IPv6<-->IPv4 tunnels - gif_up + # Create cloned interfaces + clone_up $cmdifn - # Rename interfaces. - ifnet_rename - fi + # Rename interfaces. + ifnet_rename $cmdifn # Configure the interface(s). network_common ifn_start @@ -92,6 +90,18 @@ network_start() network_stop() { + _clone_down=1 + network_stop0 $* +} + +clear() +{ + _clone_down= + network_stop0 $* +} + +network_stop0() +{ local _if # Set the list of interfaces to work on. @@ -101,6 +111,11 @@ network_stop() # Deconfigure the interface(s) network_common ifn_stop + # Destroy cloned interfaces + if [ -n "$_clone_down" ]; then + clone_down $cmdifn + fi + if [ -f /etc/rc.d/routing -a -n "$cmdifn" ] ; then for _if in $cmdifn; do /etc/rc.d/routing stop any $_if @@ -142,6 +157,16 @@ network_common() _fail= _ok= for ifn in ${_cooked_list}; do + # Skip if ifn does not exist. + case $_func in + ifn_stop) + if ! ${IFCONFIG_CMD} $ifn > /dev/null 2>&1; then + warn "$ifn does not exist. Skipped." + _fail="${_fail} ${ifn}" + continue + fi + ;; + esac if ${_func} ${ifn} $2; then _ok="${_ok} ${ifn}" if ipv6if ${ifn}; then Index: share/man/man5/rc.conf.5 =================================================================== --- share/man/man5/rc.conf.5 (revision 253545) +++ share/man/man5/rc.conf.5 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd July 12, 2013 +.Dd July 22, 2013 .Dt RC.CONF 5 .Os .Sh NAME @@ -1651,11 +1651,29 @@ Further cloning arguments may be passed to the command for each interface by setting the .Va create_args_ Ns Aq Ar interface variable. +If an interface name is specified with +.Dq :sticky +keyword, +the interface will not be destroyed even when +.Pa rc.d/netif +script is invoked with +.Dq stop +argument. +This is useful when reconfiguring the interface without destroying it. Entries in .Va cloned_interfaces are automatically appended to .Va network_interfaces for configuration. +.It Va cloned_interfaces_sticky +.Pq Vt bool +This variable is to globally enable functionality of +.Dq :sticky +keyword in +.Va cloned_interfaces +for all interfaces. +The default value is +.Dq NO . .It Va fec_interfaces .Pq Vt str Set to the list of @@ -1685,6 +1703,8 @@ ifconfig_fec0="DHCP" .Ed .It Va gif_interfaces .Pq Vt str +This variable is deprecated in favor of +.Va cloned_interfaces . Set to the list of .Xr gif 4 tunnel interfaces to configure on this host. ----Next_Part(Mon_Jul_22_23_37_04_2013_233)---- ----Security_Multipart0(Mon_Jul_22_23_37_04_2013_579)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHtQ5AACgkQTyzT2CeTzy3AyQCg0dtCgRIbHAiH+qim8X50xTBJ RNcAn0OBevMIpxXxjMi0ZXf66CAAwOkp =nMwt -----END PGP SIGNATURE----- ----Security_Multipart0(Mon_Jul_22_23_37_04_2013_579)---- From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 15:16:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76B6875F for ; Mon, 22 Jul 2013 15:16:04 +0000 (UTC) (envelope-from alie@afflemedialab.com) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3EEB523DA for ; Mon, 22 Jul 2013 15:16:03 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id n1so3654948qcx.36 for ; Mon, 22 Jul 2013 08:15:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=YpW4hnBX6KifhVvW2oYWNv0ThIPoVoMZa+SuqDsZ0x8=; b=COP5bXhXiuXi7qWUPh/onubz7yJyNlDVFvK649LkS4RJSzrMasoLnh9dfyAflCt9vV XqzicC3ap8rTsUQ2kGhyfOKXU01R5SyXBreLoFxvhVA7tyvXybzgZVUuYFCUtyxJVxPG votdEFB/mRzMvaYWu1TKM1PlYdZFAXW0aOhlAaMwjZgtxyYszQHtnIFo7BvGrtixIFeD C6pmx+J/+mZ/KGUUsFCNh2o1wvofl1NknSBhozc/mbm2nz9qzBH9JIdeurM1y0BwIYai xNndBFSxMyxN0RAs6IszJ9ArCUdyBXaX86RndjRL1K1Hel/OZ9odA/ZMbNa9czmOlo3b g+Xg== MIME-Version: 1.0 X-Received: by 10.49.84.72 with SMTP id w8mr32858458qey.14.1374506157389; Mon, 22 Jul 2013 08:15:57 -0700 (PDT) Received: by 10.49.84.168 with HTTP; Mon, 22 Jul 2013 08:15:57 -0700 (PDT) Date: Mon, 22 Jul 2013 23:15:57 +0800 Message-ID: Subject: USB gadget examples From: Alie Tan To: freebsd-current@freebsd.org X-Gm-Message-State: ALoCoQk7MsDE+druM2oAbfZgXrbekt+4TQq+7Qv8MxS64VrPk8qEOsmUSnMmX3CcZ17b0zvI5HN4 X-Mailman-Approved-At: Mon, 22 Jul 2013 15:46:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 15:16:04 -0000 Hi, May I know what is this USB gadget examples for? http://svnweb.freebsd.org/base?view=revision&revision=253544 http://svnweb.freebsd.org/base?view=revision&revision=253546 Regards, Alie T From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 15:49:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1BD78B7A for ; Mon, 22 Jul 2013 15:49:49 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id D0985258A for ; Mon, 22 Jul 2013 15:49:48 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 4AE027A0D7; Mon, 22 Jul 2013 17:49:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id D4E948EF83D; Mon, 22 Jul 2013 17:49:51 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxuxvLOTLc5T; Mon, 22 Jul 2013 17:49:51 +0200 (CEST) Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 4B6C38EF83C; Mon, 22 Jul 2013 17:49:51 +0200 (CEST) Message-ID: <51ED54FA.5080907@bitfrost.no> Date: Mon, 22 Jul 2013 17:51:22 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alie Tan Subject: Re: USB gadget examples References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 15:49:49 -0000 On 07/22/13 17:15, Alie Tan wrote: > Hi, > > May I know what is this USB gadget examples for? > http://svnweb.freebsd.org/base?view=revision&revision=253544 > http://svnweb.freebsd.org/base?view=revision&revision=253546 > > Regards, > Alie T Hi, These examples are for implementing a real USB device, I.E. not the driver on the host side, but for the firmware in the device itself. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 17:52:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A7D4F79E; Mon, 22 Jul 2013 17:52:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E79D82B71; Mon, 22 Jul 2013 17:52:56 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hq4so2208564wib.2 for ; Mon, 22 Jul 2013 10:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qUQXNf9s8t3lAbr/Flza1EMiVJL0/MsmXOCqUuJOvXg=; b=H/xcQfivhT/2I97g+WSkr96WXZPkSJjVd+KIEM0rkAGnzwNSUQqohYvQY7OAtXuxUE g0mz4Dhiv6Gdqz3KZGlpteN1Pugj9uMHwSKwWgrewA1SvdpiWSwYoqy5krIkcy3V6FLf SJCnwpJDc4cX/k4m+ctRMaeu3LNNr+1rBlAeJaw7JciqT7RW1SyyoCyG0ENzPBnSb7rq Mr6wdJVruX3Vd58BQqmdPt+FPP93N18ouxkMuk3iPaLo52i4a6cMmusx9AknP+DcTkht P6+t9xOvzyjWFXR4r+KyenFJ9MOUwcPiteaVAHCmcZv0PCT/5lvpd/reEzmN8Hs7Pp2c TgZg== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr19449629wik.30.1374515575206; Mon, 22 Jul 2013 10:52:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Mon, 22 Jul 2013 10:52:55 -0700 (PDT) In-Reply-To: <20130722095124.GH5991@kib.kiev.ua> References: <20130721072045.GB56585@devbox.vnode.local> <20130721161233.GB5991@kib.kiev.ua> <20130721205218.GC56585@devbox.vnode.local> <20130722095124.GH5991@kib.kiev.ua> Date: Mon, 22 Jul 2013 10:52:55 -0700 X-Google-Sender-Auth: 3R01ncLsL0fDg66_mK-vYrzA5EI Message-ID: Subject: Re: Lenovo x220 - hangs on shutdown From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: neel@freebsd.org, current@freebsd.org, Joel Dahl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 17:52:57 -0000 Hi kib, Is there a wiki page or some other kind of documentation descibing how AMT works? I'd like to set this up at home on some newer machines (read: buy machines that have this) but I don't know what/where to start. Thanks! -adrian On 22 July 2013 02:51, Konstantin Belousov wrote: > On Sun, Jul 21, 2013 at 10:52:18PM +0200, Joel Dahl wrote: >> On Sun, Jul 21, 2013 at 07:12:33PM +0300, Konstantin Belousov wrote: >> > On Sun, Jul 21, 2013 at 09:20:45AM +0200, Joel Dahl wrote: >> > > On Tue, Jul 16, 2013 at 10:48:35PM +0200, Joel Dahl wrote: >> > > > Hi, >> > > > >> > > > Yesterday I upgraded my Lenovo x220 to the latest current (r253368). Now it hangs when I do a shutdown from an xterm. The screen just goes black and the fan never spins down. It doesn't respond to ping. >> > > > >> > > > It didn't do this while I was running a current from mid-June. >> > > > >> > > > Any specific revision I should try to back out before I start a time consuming binary search? >> > > >> > > I found it. r252652 works. r252653 does not. >> > >> > What is the chipset on your machine ? >> >> Intel Core i7-2640M / Mobile Intel QM67 Express Chipset >> >> > Do you have AMT ? If yes, please configure serial over LAN using AMT >> > and use it for the console, to obtain the usual debugging information >> > from the kernel. At least, 'ps' output from ddb is needed. >> >> I found "Intel (R) AMT Control" in the BIOS. It's enabled. I haven't figured >> out how it works yet though. > > You need another machine, where you should install amtterm. > On the target, use the loader.conf to redirect console to > AMT Serial over LAN device. > > On my test machine, I have (output from pciconf -lv) > > uart2@pci0:0:22:3: class=0x070002 card=0x200a8086 chip=0x1c3d8086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = '6 Series/C200 Series Chipset Family KT Controller' > class = simple comms > subclass = UART > > and then I put into loader.conf > > console="comconsole" > comconsole_pcidev="0:22:3" > > Connect to the target with amtterm. Note that during the PCI bus scan > the connection could be lost, you would need to reconnect. > > You need to set up AMT in the BIOS, including enable of the SoL, remote > connections, password etc. Intel policy on the password strength is > distinctly annoying. From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 19:39:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C70BD9A for ; Mon, 22 Jul 2013 19:39:01 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2DFA72079 for ; Mon, 22 Jul 2013 19:39:00 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id r6MJcwuO002620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Jul 2013 21:38:58 +0200 Received: from [192.168.1.184] (174.Red-79-153-75.dynamicIP.rima-tde.net [79.153.75.174]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id r6MJcuNX019070 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 21:38:57 +0200 Message-ID: <51ED8A4F.8050506@entel.upc.edu> Date: Mon, 22 Jul 2013 21:38:55 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Panic when starting X with Intel KMS References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> <20130721071842.GZ5991@kib.kiev.ua> <51EBAA76.8020100@entel.upc.edu> <20130721185145.GE5991@kib.kiev.ua> <51EC43BA.1000800@entel.upc.edu> <51ED0CEC.80307@entel.upc.edu> <20130722111940.GK5991@kib.kiev.ua> In-Reply-To: <20130722111940.GK5991@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Mon, 22 Jul 2013 21:38:58 +0200 (CEST) Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 19:39:01 -0000 Al 22/07/2013 13:19, En/na Konstantin Belousov ha escrit: > On Mon, Jul 22, 2013 at 12:43:56PM +0200, Gustau P??rez i Querol wrote: >>>> As a blind shot, try to >>>> revert r252653. >> r252652 works OK. r252653 panics. > What if, instead of reverting r252653, apply the following: > > diff --git a/sys/vm/vm_phys.c b/sys/vm/vm_phys.c > index 66f3b0c..78f07f7 100644 > --- a/sys/vm/vm_phys.c > +++ b/sys/vm/vm_phys.c > @@ -547,6 +547,8 @@ vm_phys_fictitious_reg_range(vm_paddr_t start, vm_paddr_t end, > pi = atop(start); > if (pi >= first_page && atop(end) < vm_page_array_size) { > fp = &vm_page_array[pi - first_page]; > + for (i = 0; i < page_count; i++) > + fp[i].flags = 0; > malloced = FALSE; > } else > #endif > > ? After applying the patch the system panics for the same reason and the KASSERT didn't evaluate like before. The count now when the system panics seem to have been overflowed again, you can find the core at: https://dl.dropboxusercontent.com/u/2094962/core.txt.6 -- Salut i força, Gustau --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 20:03:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0BB2654A for ; Mon, 22 Jul 2013 20:03:28 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D8EBD21CB for ; Mon, 22 Jul 2013 20:03:26 +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 Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id BBA546148; Mon, 22 Jul 2013 16:03:15 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=COHtJkKUmTAI+TL8pLBRXQr1tIOa5Wae/e2bqUfI8aH29lUmL9H9PywWQiV4hhBDH TYOW5Cr5v5jdgH11h5tsi8D3rtzRkxRIrMeuTtEzv6g38WhycjEzhZ/SmG6XYQ+ Message-ID: <51ED9001.4020809@protected-networks.net> Date: Mon, 22 Jul 2013 16:03:13 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130710 Thunderbird/17.0.7 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Panic when starting X with Intel KMS References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> <20130721071842.GZ5991@kib.kiev.ua> In-Reply-To: <20130721071842.GZ5991@kib.kiev.ua> X-Enigmail-Version: 1.5.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 20:03:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/21/13 03:18, Konstantin Belousov wrote: > On Sat, Jul 20, 2013 at 01:20:56PM +0200, Oliver Pinter wrote: >> On 7/20/13, Gustau P?rez i Querol wrote: >>> Reading the backtrace I see this: >>> >>> panic: pmap_release: pmap resident count -398580 != 0 >>> >>> which comes from amd64/amd64/pmap.c:1936. I suspect that >>> pmap->pm_stats.resident_count being negative is a bug. > > The issue happened somewhere before the process exit. Try the patch > below, the idea is that your overflow count is really big, so the > wrong-doer could cause underflow when acting. > > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 19be4e0..fcdc6af 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -465,6 +465,9 @@ pmap_resident_count_dec(pmap_t pmap, int count) > { > > PMAP_LOCK_ASSERT(pmap, MA_OWNED); > + KASSERT(pmap->pm_stats.resident_count >= count, > + ("pmap %p resident count underflow %ld %d", pmap, > + pmap->pm_stats.resident_count, count)); > pmap->pm_stats.resident_count -= count; > } > > Post SVN r252653, I have experienced a similar problem but I'm not sure it's related .. root@toshi:/var/crash # less info.1 Dump header from device /dev/ada0s3b Architecture: i386 Architecture Version: 2 Dump Length: 205541376B (196 MB) Blocksize: 512 Dumptime: Sat Jul 20 15:21:39 2013 Hostname: toshi.auburn.protected-networks.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.0-CURRENT #5 r253505M: Sat Jul 20 14:48:32 EDT 2013 imb@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI Panic String: bad pte Dump Parity: 854235148 Bounds: 1 Dump Status: good root@toshi:/var/crash # kgdb /boot/kernel.old/kernel vmcore.1 [ snip ] #0 0xc07b814c in doadump () (kgdb) bt #0 0xc07b814c in doadump () #1 0xc07b86ec in kern_reboot () #2 0xc07b8b68 in panic () #3 0xc0b20b1d in pmap_remove_pages () #4 0xc0aa43dd in vmspace_exit () #5 0xc07814bf in exit1 () #6 0xc07ba5d5 in sigexit () #7 0xc07bd35f in postsig () #8 0xc0804e1b in ast () #9 0xc0b132b7 in doreti_ast () #10 0xf1633d08 in ?? () #11 0x2c00003b in ?? () # -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEARECAAYFAlHtkAAACgkQQv9rrgRC1JIILgCfRP+I8n2Jq2+RFxO1HJLJQv3s t0IAn0TRPBvQYrNvRcihBKi5BuASxtkT =FpMp -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 20:36:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 809FDF0D; Mon, 22 Jul 2013 20:36:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CFF6D2339; Mon, 22 Jul 2013 20:36:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6MKa3aN083857; Mon, 22 Jul 2013 23:36:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6MKa3aN083857 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6MKa31T083856; Mon, 22 Jul 2013 23:36:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 22 Jul 2013 23:36:03 +0300 From: Konstantin Belousov To: Adrian Chadd Subject: Re: Lenovo x220 - hangs on shutdown Message-ID: <20130722203603.GO5991@kib.kiev.ua> References: <20130721072045.GB56585@devbox.vnode.local> <20130721161233.GB5991@kib.kiev.ua> <20130721205218.GC56585@devbox.vnode.local> <20130722095124.GH5991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hun9kSK4g7A5t+iU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: neel@freebsd.org, current@freebsd.org, Joel Dahl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 20:36:10 -0000 --hun9kSK4g7A5t+iU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2013 at 10:52:55AM -0700, Adrian Chadd wrote: > Hi kib, >=20 > Is there a wiki page or some other kind of documentation descibing how > AMT works? It is Intel documentation for vPro. Setting up AMT on the motherboard is specific to the motherboard BIOS, you should look at the hardware vendor documentation. Random googling for you revealed e.g. http://wiki.debian.org/AMT which is actually good introduction (i.e. there is not much to say about AMT usage in fact). >=20 > I'd like to set this up at home on some newer machines (read: buy > machines that have this) but I don't know what/where to start. For the controlling side of things, I use amttools, available in ports collection as comms/amtterm. The manual pages are brief but useful. Amttools provide amttool(1) for power control, and amtterm/gamt for console. --hun9kSK4g7A5t+iU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR7ZeyAAoJEJDCuSvBvK1B19EQAJa14qkfJfQN+6hZfq6BAT4m eTAZ/Fhsp4T7e+VyI206T7qSqK7LwrANPsT2liy2X5fxvDK9giJOMmr9nXoy8bDV 8176cqpaWG5VbzhSkbNTOU81groSDQ+eNvoU2wF6mpDSabpk4dDWUDRsAR6+dy7v FQPvQPNPvlRegTAZF93iI3utfJCo6KztphnJtMBCZo37rQzZc9hMMJoDpa/OjEqw GLzE8sCpm3RRPug+8qL6sKPSCDpm7ohNtXWHzWj0pZwgLlP+ODtQO6N50yYlGcmt IQrYWAcvFR7/BkYsnaFxaOKNt6LWnAqNIhD00faJ6p3Lf01zie0yqIiAoHjEbl/H 6rXfadLQY8M/srjMi1eJpd0Hho7RpRAO37z61Hhl1g5S05emJ36+s7aXufzb/Upr zBqlUBhECw9cPR93c5jIGmn5Nu/uFUuJttirodHi1nvdGe2RgRTVl5ajxGuDpB74 lnW7adEqcrhpIs5RoXXP/8pd45ihi6I7iT65q0LY9s5uUEXGRjbe42QvQe1+gMSh czmw2CUvX4iWHed5SPZ6ckl6mgKj3/R04Au3RO33QPCBQONKcKg2XgmivgS///QD kS8O93VoJtQ9MnwfuD6SvKdg8ycTOwOMxvlCJddhIwxrxr7X9AFB8eG9Y21kXdKc POlQOyt8G4614u3oD2wJ =wgc2 -----END PGP SIGNATURE----- --hun9kSK4g7A5t+iU-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 20:38:14 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D594D7; Mon, 22 Jul 2013 20:38:14 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6D764235B; Mon, 22 Jul 2013 20:38:12 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 0E1D144D; Mon, 22 Jul 2013 22:33:16 +0200 (CEST) Date: Mon, 22 Jul 2013 22:38:53 +0200 From: Pawel Jakub Dawidek To: Andriy Gapon Subject: Re: r253070 and "disappearing" zpool Message-ID: <20130722203853.GB1400@garage.freebsd.pl> References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline In-Reply-To: <51ECDF64.2020704@FreeBSD.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org, Glen Barber , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 20:38:14 -0000 --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2013 at 10:29:40AM +0300, Andriy Gapon wrote: > I think that this setup (on ZFS level) is quite untypical, although not > impossible on FreeBSD (and perhaps only FreeBSD). > It's untypical because you have separate boot pool (where loader, loader.= conf > and kernel are taken from) and root pool (where "/" is mounted from). As I said elsewhere, it is pretty typical when full disk encryption is used. The /boot/ has to be unencrypted and can be stored on eg. USB pendrive which is never left unattended, unlike laptop which can be left in eg. a hotel room, but with entire disk encrypted. > So, I see three ways of resolving the problem that my changes caused for = your > configuration. >=20 > 1. [the easiest] Put zpool.cache loading instructions that used to be in > defaults/loader.conf into your loader.conf. This way everything should w= ork as > before -- zpool.cache would be loaded from your boot pool. >=20 > 2. Somehow (I don't want to go into any technical details here) arrange t= hat > your root pool has /boot/zfs/zpool.cache that describes your boot pool. = This is > probably hard given that your /boot is a symlink at the moment. This pro= bably > would be easier to achieve if zpool.cache lived in /etc/zfs. >=20 > 3. [my favorite] Remove an artificial difference between your boot and r= oot > pools, so that they are a single root+boot pool (as zfs gods intended). = As far > as I understand your setup, you use GELI to protect some sensitive data. > Apparently your kernel is not sensitive data, so I wonder if your /bin/sh= or > /sbin/init are really sensitive either. > So perhaps you can arrange your unencrypted pool to hold all of the base = system > (boot + root) and put all your truly sensitive filesystems (like e.g. /ho= me or > /var/data or /opt/xyz) onto your encrypted pool. If all you care about is laptop being stolen, then that would work. If you however want to be protected from someone replacing your /sbin/init with something evil then you use encryption or even better integrity verification also supported by GELI. Remember, tools not policies. There is also option number 4 - backing out your commit. When I saw your commit removing those entries from defaults/loader.conf, I thought it is fine, as we now don't require zpool.cache to import the root pool, which was, BTW, very nice and handy improvement. Now that we know it breaks existing installations I'd prefer the commit to be backed out. This is because apart from breaking some existing installations it doesn't gain us anything. > So I understand that my change causes a problem for a setup like yours, b= ut I > believe that the change is correct. The change is clearly incorrect or incomplete as it breaks existing installations and doesn't allow for full disk encryption configuration on ZFS-only systems. BTW. If moving zpool.cache to /etc/zfs/ will work for both cases that's fine by me, although the migration might be tricky. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHtmF0ACgkQForvXbEpPzThTgCgw4sjqVzDo2SQTz60mA67V9gy 7GoAn1bOXMhOJ3EEoAZT2h1URfGHu9Y2 =dUcf -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 22 21:27:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 360D2D05 for ; Mon, 22 Jul 2013 21:27:39 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0962D25E1 for ; Mon, 22 Jul 2013 21:27:38 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id a11so16766675iee.34 for ; Mon, 22 Jul 2013 14:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UfF/pcaZLspNm2z8yoB1IxEbAUpQJ1zw+DCeSd2DobA=; b=nxlWR7hmLof9XlkEt67ZStv5f7+s7dAE5/7SHR+C4usBz7p4H2LnWXhqcrUcevbsY0 7881HcJfGWTJPbN13w2WAHS44ytpMFUBNwq6xRKz+PBZz7OotHsXfKJ6OufD6VaNXZgG 0riZkF98/K/+Og94dLA9MihsYocJiIZtgQFbfe6kebTzAiIk53GVvr2QjKemk6Gx32YB TPOh7ncfTisgXgo+vUj2zdf5MAmuRJgAb94R4WrI82Ng9wkgGLnlKahlpdteBo68Bhoa HsN2lHrA8hIQsTA5t6UCrx9smth8PjXAxyMtqiXAKgCLmjbeZVBmidqlOzjMnl7y4p8O a4yw== MIME-Version: 1.0 X-Received: by 10.50.11.13 with SMTP id m13mr20341248igb.32.1374528458542; Mon, 22 Jul 2013 14:27:38 -0700 (PDT) Received: by 10.42.151.74 with HTTP; Mon, 22 Jul 2013 14:27:38 -0700 (PDT) In-Reply-To: <51ED8A4F.8050506@entel.upc.edu> References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> <20130721071842.GZ5991@kib.kiev.ua> <51EBAA76.8020100@entel.upc.edu> <20130721185145.GE5991@kib.kiev.ua> <51EC43BA.1000800@entel.upc.edu> <51ED0CEC.80307@entel.upc.edu> <20130722111940.GK5991@kib.kiev.ua> <51ED8A4F.8050506@entel.upc.edu> Date: Mon, 22 Jul 2013 14:27:38 -0700 Message-ID: Subject: Re: Panic when starting X with Intel KMS From: Neel Natu To: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Konstantin Belousov , FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 21:27:39 -0000 Hi Gustau, On Mon, Jul 22, 2013 at 12:38 PM, Gustau P=E9rez i Querol wrote: > Al 22/07/2013 13:19, En/na Konstantin Belousov ha escrit: > >> On Mon, Jul 22, 2013 at 12:43:56PM +0200, Gustau P??rez i Querol wrote: >>>>> >>>>> As a blind shot, try to >>>>> revert r252653. >>> >>> r252652 works OK. r252653 panics. >> >> What if, instead of reverting r252653, apply the following: >> >> diff --git a/sys/vm/vm_phys.c b/sys/vm/vm_phys.c >> index 66f3b0c..78f07f7 100644 >> --- a/sys/vm/vm_phys.c >> +++ b/sys/vm/vm_phys.c >> @@ -547,6 +547,8 @@ vm_phys_fictitious_reg_range(vm_paddr_t start, >> vm_paddr_t end, >> pi =3D atop(start); >> if (pi >=3D first_page && atop(end) < vm_page_array_size) { >> fp =3D &vm_page_array[pi - first_page]; >> + for (i =3D 0; i < page_count; i++) >> + fp[i].flags =3D 0; >> malloced =3D FALSE; >> } else >> #endif >> >> ? > > > After applying the patch the system panics for the same reason and the > KASSERT didn't evaluate like before. The count now when the system panics > seem to have been overflowed again, you can find the core at: > > https://dl.dropboxusercontent.com/u/2094962/core.txt.6 > Could you apply the following patch to amd64/amd64/pmap.c and see if it fixes the problem: http://people.freebsd.org/~neel/patches/pmap_remove_pages.patch best Neel > > > > > > > > -- > Salut i for=E7a, > > Gustau > > -------------------------------------------------------------------------= -- > Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting > Stop top-posting : http://en.wikipedia.org/wiki/Posting_style > > O O O Gustau P=E9rez i Querol > O O O Unitat de Gesti=F3 dels departaments > O O O Matem=E0tica Aplicada IV i Enginyeria Telem=E0tica > > Universitat Polit=E8cnica de Catalunya > Edifici C3 - Despatx S101-B > UPC Campus Nord UPC > C/ Jordi Girona, 1-3 > 08034 - Barcelona > > _______________________________________________ > 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 22 21:32:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 02989E6C; Mon, 22 Jul 2013 21:32:07 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF318261B; Mon, 22 Jul 2013 21:32:06 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id 17so4342254iea.3 for ; Mon, 22 Jul 2013 14:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7NOWBoibqNbWyrY3pEODSGW3JMK13gaHzmPKDnGGUBw=; b=JBHss5OaLKd5tLYwXmdo7GN6xaxFPgzGWhDlFk7VStSpxjT87vHTaJHJbtJQYwxrxs yQ6W/xtOh55dcCQ9WP2dnM4jfiUJg1lowkyhahbCwvcO0TZipdrDR0HIPuGEaGByAOwj P1QgILtiwx3ktNjaO5P67Qz/AHCJAATldIeTaMS2zoWnCZC4j2wB6iOAbyf5tWIR/oTr dRob26qJLrH+0OlTqAg7vm7NbxL4YFDqOW6I8JjSVkxYCwVSNGmzIJYwLKbY/ze1S2Cd e4ggrDsgCgz+CyJoILL8f9X9i0PRanaNRjCzPmrgKwqbjP4is73xTNwIMebSe2oeLAgC 8Zxg== MIME-Version: 1.0 X-Received: by 10.42.36.3 with SMTP id s3mr18497287icd.42.1374528726276; Mon, 22 Jul 2013 14:32:06 -0700 (PDT) Received: by 10.42.151.74 with HTTP; Mon, 22 Jul 2013 14:32:06 -0700 (PDT) In-Reply-To: <20130722203603.GO5991@kib.kiev.ua> References: <20130721072045.GB56585@devbox.vnode.local> <20130721161233.GB5991@kib.kiev.ua> <20130721205218.GC56585@devbox.vnode.local> <20130722095124.GH5991@kib.kiev.ua> <20130722203603.GO5991@kib.kiev.ua> Date: Mon, 22 Jul 2013 14:32:06 -0700 Message-ID: Subject: Re: Lenovo x220 - hangs on shutdown From: Neel Natu To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: Adrian Chadd , neel@freebsd.org, current@freebsd.org, Joel Dahl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 22 Jul 2013 21:32:07 -0000 Hi Joel, On Mon, Jul 22, 2013 at 1:36 PM, Konstantin Belousov wrote: > On Mon, Jul 22, 2013 at 10:52:55AM -0700, Adrian Chadd wrote: >> Hi kib, >> >> Is there a wiki page or some other kind of documentation descibing how >> AMT works? > It is Intel documentation for vPro. Setting up AMT on the motherboard > is specific to the motherboard BIOS, you should look at the hardware > vendor documentation. > > Random googling for you revealed e.g. http://wiki.debian.org/AMT > which is actually good introduction (i.e. there is not much to say > about AMT usage in fact). > >> >> I'd like to set this up at home on some newer machines (read: buy >> machines that have this) but I don't know what/where to start. > For the controlling side of things, I use amttools, available in > ports collection as comms/amtterm. The manual pages are brief > but useful. > > Amttools provide amttool(1) for power control, and amtterm/gamt for console. Could you apply the following patch to amd64/amd64/pmap.c and see if it helps? http://people.freebsd.org/~neel/patches/pmap_remove_pages.patch best Neel From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 02:54:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 05E0BB53; Tue, 23 Jul 2013 02:54:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4795D20E8; Tue, 23 Jul 2013 02:54:17 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y10so3087857wgg.0 for ; Mon, 22 Jul 2013 19:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=ArOW21+syw7+7BVO9YgDepBRilKBR4O020i1X3s5hUE=; b=WZo7uboShIpeGuoV5d59CV6m7ZLEXeuO7iGX4LyvNkAAt9vrnNuKPbhtCfDXt++0rC xDOOTzVKpgOLuWAvA8WlcfT7gBIMtzqqP6gTb1RDAIkcAgG0QWsXMVdsFmjwVgpQOA4t ATDasA3Y4vdT/OIH91UGApXI9X9jOrRXaN64x6etyKzIPqEKAUGFrdawwY5Ua/GIysaZ vNTxa79GQjtUdYNAiqK/qNmRd9okQl/Xoaw15qa+nyfR3PhvF6zkBV8LtgQ4URm2/zfW cb93BdsTIfFpWR9ZPOW9HmCTFcdhBPQMywA9vpIPIaJ7Ty8nYTmEZeZUv3bk0xDQ27zu hH8A== MIME-Version: 1.0 X-Received: by 10.194.11.72 with SMTP id o8mr21941742wjb.0.1374548055644; Mon, 22 Jul 2013 19:54:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Mon, 22 Jul 2013 19:54:15 -0700 (PDT) Date: Mon, 22 Jul 2013 19:54:15 -0700 X-Google-Sender-Auth: 2QvaLZkA24TsxikzWYQD5dd6BtE Message-ID: Subject: [ixgbe] Register txd/rxd sysctl values From: Adrian Chadd To: Jack F Vogel , FreeBSD Net , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 02:54:18 -0000 Hi, This patch adds and hw.ixgbe tree and adds rxd/txd. These are already tunables but it wasn't easy to see if these were being set. I'd like to commit this soon. Thanks! -adrian adrian@freebsd-10-hack2:~/work/freebsd/head/src/sys/dev/ixgbe % svn diff . Index: ixgbe.c =================================================================== --- ixgbe.c (revision 253553) +++ ixgbe.c (working copy) @@ -234,6 +234,8 @@ ** TUNEABLE PARAMETERS: */ +static SYSCTL_NODE(_hw, OID_AUTO, ixgbe, CTLFLAG_RD, 0, "IXGBE driver parameters"); + /* ** AIM: Adaptive Interrupt Moderation ** which means that the interrupt rate @@ -291,6 +293,11 @@ static int ixgbe_rxd = PERFORM_RXD; TUNABLE_INT("hw.ixgbe.rxd", &ixgbe_rxd); +SYSCTL_INT(_hw_ixgbe, OID_AUTO, rxd, CTLFLAG_RDTUN, &ixgbe_rxd, 0, + "Number of receive descriptors per queue"); +SYSCTL_INT(_hw_ixgbe, OID_AUTO, txd, CTLFLAG_RDTUN, &ixgbe_txd, 0, + "Number of transmit descriptors per queue"); + /* ** Defining this on will allow the use ** of unsupported SFP+ modules, note that adrian@freebsd-10-hack2:~/work/freebsd/head/src/sys/dev/ixgbe % From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 05:54:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1DE3EC81; Tue, 23 Jul 2013 05:54:32 +0000 (UTC) (envelope-from joel@freebsd.org) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id D2FF2284B; Tue, 23 Jul 2013 05:54:31 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 419F9E3F07B; Tue, 23 Jul 2013 07:54:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+jW7yJuAv9F; Tue, 23 Jul 2013 07:54:22 +0200 (CEST) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 62062E3F079; Tue, 23 Jul 2013 07:54:21 +0200 (CEST) Date: Tue, 23 Jul 2013 07:54:19 +0200 From: Joel Dahl To: Neel Natu Subject: Re: Lenovo x220 - hangs on shutdown Message-ID: <20130723055419.GD56585@devbox.vnode.local> References: <20130721072045.GB56585@devbox.vnode.local> <20130721161233.GB5991@kib.kiev.ua> <20130721205218.GC56585@devbox.vnode.local> <20130722095124.GH5991@kib.kiev.ua> <20130722203603.GO5991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , Adrian Chadd , neel@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 05:54:32 -0000 On Mon, Jul 22, 2013 at 02:32:06PM -0700, Neel Natu wrote: > Hi Joel, > > On Mon, Jul 22, 2013 at 1:36 PM, Konstantin Belousov > wrote: > > On Mon, Jul 22, 2013 at 10:52:55AM -0700, Adrian Chadd wrote: > >> Hi kib, > >> > >> Is there a wiki page or some other kind of documentation descibing how > >> AMT works? > > It is Intel documentation for vPro. Setting up AMT on the motherboard > > is specific to the motherboard BIOS, you should look at the hardware > > vendor documentation. > > > > Random googling for you revealed e.g. http://wiki.debian.org/AMT > > which is actually good introduction (i.e. there is not much to say > > about AMT usage in fact). > > > >> > >> I'd like to set this up at home on some newer machines (read: buy > >> machines that have this) but I don't know what/where to start. > > For the controlling side of things, I use amttools, available in > > ports collection as comms/amtterm. The manual pages are brief > > but useful. > > > > Amttools provide amttool(1) for power control, and amtterm/gamt for console. > > Could you apply the following patch to amd64/amd64/pmap.c and see if it helps? > http://people.freebsd.org/~neel/patches/pmap_remove_pages.patch Yes, it helps. I can shutdown the machine from X again. -- Joel From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 07:26:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 58645F0F for ; Tue, 23 Jul 2013 07:26:06 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EED2D2BA2 for ; Tue, 23 Jul 2013 07:26:05 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id b10so5765868vea.30 for ; Tue, 23 Jul 2013 00:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JLPAFfKFEp6sjuEnfW6ZGIQaU7GTNLSPUj5G/oB1Bno=; b=JnVAV415jtteab93AHgO+9DgCFIYCfn4Bx0eIwPRamFfQycGLCbyQ1HwWMpqfFtLLk MTKgZYsxxWkfZHErpjHXFK5hsumCRdxtw+/QjB5G/QCYxHVOBGmRZGIZm1YR1S9+OsRk TA3a6tWezUSQ863uHkvLV9y8dUW0m29PcAk4MQtmWEyPNLVmlYi68nIGHkNvvxlL49aP z9RZUK4GyQpxGOT1nwOnHd5gC2Dv5VdGPeaRD3mQB7Jf3lZGW3jbIEsoNdgsIsp/SmTs Fxk+HPDmW5RwegIDhKwaIcSFfTuqL1NZqByLTN/zr8YNMUwK0TD6NaEoiabw0mr9miwI tRPQ== MIME-Version: 1.0 X-Received: by 10.220.101.81 with SMTP id b17mr1664565vco.79.1374564365080; Tue, 23 Jul 2013 00:26:05 -0700 (PDT) Received: by 10.221.8.135 with HTTP; Tue, 23 Jul 2013 00:26:04 -0700 (PDT) Date: Tue, 23 Jul 2013 03:26:04 -0400 Message-ID: Subject: Network card issues ifconfig down ifconfig up required From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 07:26:06 -0000 Hello list, I decided to use a Old Asus Motherboard, for a Router / Firewall I decided to use -HEAD to get the latest WIFI support... I seem to have to ifconfig down and ifconfig up the interfaces before they become active... is there any way to fix this? I have a full dmesg, pciconf -lcbv, kenv | grep smbios, as well as a ifconfig below root@Border:~ # dmesg Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #2 r253560: Tue Jul 23 04:49:04 UTC 2013 root@Border:/usr/obj/usr/src/sys/BORDER amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2400.03-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Family = 0x6 Model = 0xf Stepping = 7 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7968894976 (7599 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfdf0000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfeff0000-0xfeff03ff irq 0,8 on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 950 atrtc0: port 0x70-0x73 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 1.4 (no driver attached) pci0: at device 1.5 (no driver attached) pci0: at device 1.6 (no driver attached) pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) pci0: at device 2.2 (no driver attached) pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) ohci0: mem 0xeffff000-0xefffffff irq 21 at device 11.0 on pci0 usbus0 on ohci0 ehci0: mem 0xefffe000-0xefffe0ff irq 22 at device 11.1 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 13.0 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem 0xefffd000-0xefffdfff irq 23 at device 14.0 on pci0 ata2: at channel 0 on atapci1 ata3: at channel 1 on atapci1 atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf200-0xf20f mem 0xefffc000-0xefffcfff irq 20 at device 14.1 on pci0 ata4: at channel 0 on atapci2 ata5: at channel 1 on atapci2 atapci3: port 0xf100-0xf107,0xf000-0xf003,0xef00-0xef07,0xee00-0xee03,0xed00-0xed0f mem 0xefffb000-0xefffbfff irq 21 at device 14.2 on pci0 ata6: at channel 0 on atapci3 ata7: at channel 1 on atapci3 pcib1: at device 15.0 on pci0 pci1: on pcib1 re0: port 0xdc00-0xdcff mem 0xefdff000-0xefdff0ff irq 16 at device 6.0 on pci1 re0: Chip rev. 0x10000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:14:d1:25:d8:23 re1: port 0xd800-0xd8ff mem 0xefdfe000-0xefdfe0ff irq 17 at device 7.0 on pci1 re1: Chip rev. 0x10000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re1: Ethernet address: 00:14:d1:25:d8:44 pci1: at device 11.0 (no driver attached) nfe0: port 0xec00-0xec07 mem 0xefffa000-0xefffafff,0xefff9000-0xefff90ff,0xefff8000-0xefff800f irq 22 at device 17.0 on pci0 miibus2: on nfe0 e1000phy0: PHY 19 on miibus2 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow nfe0: Ethernet address: 00:1a:92:46:e0:44 nfe1: port 0xeb00-0xeb07 mem 0xefff7000-0xefff7fff,0xefff6000-0xefff60ff,0xefff5000-0xefff500f irq 23 at device 18.0 on pci0 miibus3: on nfe1 e1000phy1: PHY 1 on miibus3 e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow nfe1: Ethernet address: 00:1a:92:46:ed:f7 pcib2: at device 19.0 on pci0 pci2: on pcib2 vgapci0: mem 0xec000000-0xecffffff,0xd0000000-0xdfffffff,0xed000000-0xedffffff irq 16 at device 0.0 on pci2 pcib3: at device 22.0 on pci0 pci3: on pcib3 siis0: port 0xbc00-0xbc7f mem 0xefcff000-0xefcff07f,0xefcf8000-0xefcfbfff irq 16 at device 0.0 on pci3 siisch0: at channel 0 on siis0 siisch1: at channel 1 on siis0 pcib4: at device 23.0 on pci0 pci4: on pcib4 ath0: mem 0xefac0000-0xefadffff irq 16 at device 0.0 on pci4 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 3 RX streams; 3 TX streams ath0: AR9380 mac 448.3 RF5110 phy 0.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 orm0: at iomem 0xd0000-0xd3fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est1 attach returned 6 p4tcc1: on cpu1 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est2 attach returned 6 p4tcc2: on cpu2 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est3 attach returned 6 p4tcc3: on cpu3 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 uhub1: 10 ports with 10 removable, self powered uhub0: 10 ports with 10 removable, self powered ada0 at ata2 bus 0 scbus2 target 0 lun 0 ada0: ATA-7 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada0: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ata3 bus 0 scbus3 target 0 lun 0 ada1: ATA-7 SATA 1.x device ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada1: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC-low" frequency 1200012795 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus1 Trying to mount root from zfs:Puffy []... ugen0.2: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetCTSTimeout: called ar9300_Stub_GetAntennaSwitch: called ar9300_Stub_GetAntennaSwitch: called wlan0: Ethernet address: 7c:c3:a1:b3:fc:af uhid0: on usbus0 re0: link state changed to DOWN re0: link state changed to UP nfe1: link state changed to DOWN nfe1: link state changed to UP root@Border:~ # pciconf -lcbv hostb0@pci0:0:0:0: class=0x060000 card=0x00000000 chip=0x03a110de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Host Bridge' class = bridge subclass = HOST-PCI cap 08[40] = HT host none0@pci0:0:0:1: class=0x050000 card=0x00000000 chip=0x03ac10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none1@pci0:0:0:2: class=0x050000 card=0x00000000 chip=0x03aa10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none2@pci0:0:0:3: class=0x050000 card=0x00000000 chip=0x03a910de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none3@pci0:0:0:4: class=0x050000 card=0x00000000 chip=0x03ab10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none4@pci0:0:0:5: class=0x050000 card=0x00000000 chip=0x03a810de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none5@pci0:0:0:6: class=0x050000 card=0x00000000 chip=0x03b510de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none6@pci0:0:0:7: class=0x050000 card=0x00000000 chip=0x03b410de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none7@pci0:0:1:0: class=0x050000 card=0x00000000 chip=0x03ad10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none8@pci0:0:1:1: class=0x050000 card=0x00000000 chip=0x03ae10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none9@pci0:0:1:2: class=0x050000 card=0x00000000 chip=0x03af10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none10@pci0:0:1:3: class=0x050000 card=0x00000000 chip=0x03b010de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none11@pci0:0:1:4: class=0x050000 card=0x00000000 chip=0x03b110de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none12@pci0:0:1:5: class=0x050000 card=0x00000000 chip=0x03b210de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none13@pci0:0:1:6: class=0x050000 card=0x00000000 chip=0x03b310de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none14@pci0:0:2:0: class=0x050000 card=0x00000000 chip=0x03b610de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none15@pci0:0:2:1: class=0x050000 card=0x00000000 chip=0x03bc10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none16@pci0:0:2:2: class=0x050000 card=0x00000000 chip=0x03ba10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'C55 Memory Controller' class = memory subclass = RAM none17@pci0:0:9:0: class=0x050000 card=0xcb841043 chip=0x036910de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP55 Memory Controller' class = memory subclass = RAM cap 08[44] = HT slave cap 00[e0] = unknown isab0@pci0:0:10:0: class=0x060100 card=0xcb841043 chip=0x036010de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP55 LPC Bridge' class = bridge subclass = PCI-ISA none18@pci0:0:10:1: class=0x0c0500 card=0xcb841043 chip=0x036810de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP55 SMBus' class = serial bus subclass = SMBus bar [10] = type I/O Port, range 32, base 0xff00, size 64, enabled bar [20] = type I/O Port, range 32, base 0x1c00, size 64, enabled bar [24] = type I/O Port, range 32, base 0x1c80, size 64, enabled cap 01[44] = powerspec 2 supports D0 D3 current D0 ohci0@pci0:0:11:0: class=0x0c0310 card=0xcb841043 chip=0x036c10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP55 USB Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xeffff000, size 4096, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 ehci0@pci0:0:11:1: class=0x0c0320 card=0xcb841043 chip=0x036d10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP55 USB Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xefffe000, size 256, enabled cap 0a[44] = EHCI Debug Port at offset 0x98 in map 0x14 cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 atapci0@pci0:0:13:0: class=0x01018a card=0xcb841043 chip=0x036e10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP55 IDE' class = mass storage subclass = ATA bar [20] = type I/O Port, range 32, base 0xfc00, size 16, enabled cap 01[44] = powerspec 2 supports D0 D3 current D0 atapci1@pci0:0:14:0: class=0x010185 card=0xcb841043 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x9f0, size 8, enabled bar [14] = type I/O Port, range 32, base 0xbf0, size 4, enabled bar [18] = type I/O Port, range 32, base 0x970, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xb70, size 4, enabled bar [20] = type I/O Port, range 32, base 0xf700, size 16, enabled bar [24] = type Memory, range 32, base 0xefffd000, size 4096, enabled cap 01[44] = powerspec 2 supports D0 D3 current D0 cap 05[b0] = MSI supports 4 messages, 64 bit cap 08[cc] = HT MSI fixed address window disabled at 0xfee00000 atapci2@pci0:0:14:1: class=0x010185 card=0xcb841043 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x9e0, size 8, enabled bar [14] = type I/O Port, range 32, base 0xbe0, size 4, enabled bar [18] = type I/O Port, range 32, base 0x960, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xb60, size 4, enabled bar [20] = type I/O Port, range 32, base 0xf200, size 16, enabled bar [24] = type Memory, range 32, base 0xefffc000, size 4096, enabled cap 01[44] = powerspec 2 supports D0 D3 current D0 cap 05[b0] = MSI supports 4 messages, 64 bit cap 08[cc] = HT MSI fixed address window disabled at 0xfee00000 atapci3@pci0:0:14:2: class=0x010185 card=0xcb841043 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xf100, size 8, enabled bar [14] = type I/O Port, range 32, base 0xf000, size 4, enabled bar [18] = type I/O Port, range 32, base 0xef00, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xee00, size 4, enabled bar [20] = type I/O Port, range 32, base 0xed00, size 16, enabled bar [24] = type Memory, range 32, base 0xefffb000, size 4096, enabled cap 01[44] = powerspec 2 supports D0 D3 current D0 cap 05[b0] = MSI supports 4 messages, 64 bit cap 08[cc] = HT MSI fixed address window disabled at 0xfee00000 pcib1@pci0:0:15:0: class=0x060401 card=0xcb8410de chip=0x037010de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'MCP55 PCI bridge' class = bridge subclass = PCI-PCI cap 0d[b8] = PCI Bridge card=0xcb8410de cap 08[8c] = HT MSI address window disabled at 0xfee00000 nfe0@pci0:0:17:0: class=0x068000 card=0xcb841043 chip=0x037310de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP55 Ethernet' class = bridge bar [10] = type Memory, range 32, base 0xefffa000, size 4096, enabled bar [14] = type I/O Port, range 32, base 0xec00, size 8, enabled bar [18] = type Memory, range 32, base 0xefff9000, size 256, enabled bar [1c] = type Memory, range 32, base 0xefff8000, size 16, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 11[70] = MSI-X supports 8 messages, enabled Table in map 0x18[0x0], PBA in map 0x1c[0x0] cap 05[50] = MSI supports 8 messages, 64 bit, vector masks cap 08[6c] = HT MSI fixed address window enabled at 0xfee00000 nfe1@pci0:0:18:0: class=0x068000 card=0xcb841043 chip=0x037310de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP55 Ethernet' class = bridge bar [10] = type Memory, range 32, base 0xefff7000, size 4096, enabled bar [14] = type I/O Port, range 32, base 0xeb00, size 8, enabled bar [18] = type Memory, range 32, base 0xefff6000, size 256, enabled bar [1c] = type Memory, range 32, base 0xefff5000, size 16, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 11[70] = MSI-X supports 8 messages, enabled Table in map 0x18[0x0], PBA in map 0x1c[0x0] cap 05[50] = MSI supports 8 messages, 64 bit, vector masks cap 08[6c] = HT MSI fixed address window enabled at 0xfee00000 pcib2@pci0:0:19:0: class=0x060400 card=0x000010de chip=0x037610de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'MCP55 PCI Express bridge' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x000010de cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 2 messages, 64 bit cap 08[60] = HT MSI address window disabled at 0xfee00000 cap 10[80] = PCI-Express 1 root port slot max data 128(256) link x8(x8) speed 2.5(2.5) ASPM disabled(L0s/L1) ecap 0002[100] = VC 1 max VC0 pcib3@pci0:0:22:0: class=0x060400 card=0x000010de chip=0x037810de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'MCP55 PCI Express bridge' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x000010de cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 2 messages, 64 bit cap 08[60] = HT MSI address window disabled at 0xfee00000 cap 10[80] = PCI-Express 1 root port slot max data 256(256) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) ecap 0002[100] = VC 1 max VC0 pcib4@pci0:0:23:0: class=0x060400 card=0x000010de chip=0x037510de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'MCP55 PCI Express bridge' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x000010de cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 2 messages, 64 bit cap 08[60] = HT MSI address window disabled at 0xfee00000 cap 10[80] = PCI-Express 1 root port slot max data 128(256) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) ecap 0002[100] = VC 1 max VC0 re0@pci0:1:6:0: class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8169 PCI Gigabit Ethernet Controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0xdc00, size 256, enabled bar [14] = type Memory, range 32, base 0xefdff000, size 256, enabled cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 re1@pci0:1:7:0: class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8169 PCI Gigabit Ethernet Controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled bar [14] = type Memory, range 32, base 0xefdfe000, size 256, enabled cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 none19@pci0:1:11:0: class=0x0c0010 card=0x81fe1043 chip=0x30441106 rev=0xc0 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller' class = serial bus subclass = FireWire bar [10] = type Memory, range 32, base 0xefdfd000, size 2048, enabled bar [14] = type I/O Port, range 32, base 0xd400, size 128, enabled cap 01[50] = powerspec 2 supports D0 D2 D3 current D0 vgapci0@pci0:2:0:0: class=0x030000 card=0x99101462 chip=0x016110de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NV44 [GeForce 6200 TurboCache(TM)]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xec000000, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xd0000000, size 268435456, enabled bar [1c] = type Memory, range 64, base 0xed000000, size 16777216, enabled cap 01[60] = powerspec 2 supports D0 D3 current D0 cap 05[68] = MSI supports 1 message, 64 bit cap 10[78] = PCI-Express 1 endpoint max data 128(128) link x8(x16) speed 2.5(2.5) ASPM disabled(L0s/L1) ecap 0002[100] = VC 1 max VC0 ecap 0004[128] = Power Budgeting 1 siis0@pci0:3:0:0: class=0x018000 card=0x819f1043 chip=0x31321095 rev=0x01 hdr=0x00 vendor = 'Silicon Image, Inc.' device = 'SiI 3132 Serial ATA Raid II Controller' class = mass storage bar [10] = type Memory, range 64, base 0xefcff000, size 128, enabled bar [18] = type Memory, range 64, base 0xefcf8000, size 16384, enabled bar [20] = type I/O Port, range 32, base 0xbc00, size 128, enabled cap 01[54] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[5c] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint max data 256(1024) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ath0@pci0:4:0:0: class=0x028000 card=0x009a106b chip=0x0030168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR9300 Wireless LAN adaptor' class = network bar [10] = type Memory, range 64, base 0xefac0000, size 131072, enabled cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 4 messages, 64 bit, vector masks cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[300] = Serial 1 0000000000000000 root@Border:~ # root@Border:~ # kenv | grep smbios smbios.bios.reldate="04/28/2009" smbios.bios.vendor="Phoenix Technologies, LTD" smbios.bios.version="ASUS StrikerExtreme ACPI BIOS Revision 1901" smbios.chassis.maker="Chassis Manufacture" smbios.chassis.serial="EVAL " smbios.chassis.tag="123456789000" smbios.chassis.version="Chassis Version" smbios.memory.enabled="8388608" smbios.planar.maker="ASUSTeK Computer INC." smbios.planar.product="StrikerExtreme" smbios.planar.serial="123456789000" smbios.planar.version="1.XX " smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="System manufacturer" smbios.system.product="System Product Name" smbios.system.serial="System Serial Number" smbios.system.uuid="becbf4de-e6e7-53eb-eafa-1c0fc0145223" smbios.system.version="System Version" smbios.version="2.4" root@Border:~ # root@Border:~ # ifconfig re0: flags=8843 metric 0 mtu 1500 options=8209b ether 00:14:d1:25:d8:23 inet 99.55.241.27 netmask 0xfffffc00 broadcast 99.55.243.255 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active re1: flags=8843 metric 0 mtu 1500 options=8209b ether 00:14:d1:25:d8:44 inet 192.168.12.1 netmask 0xffffff00 broadcast 192.168.12.255 inet6 fe80::214:d1ff:fe25:d844%re1 prefixlen 64 scopeid 0x2 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active nfe0: flags=8802 metric 0 mtu 1500 options=c219b ether 00:1a:92:46:e0:44 nd6 options=29 media: Ethernet autoselect (none) status: no carrier nfe1: flags=8843 metric 0 mtu 1500 options=c219b ether 00:1a:92:46:ed:f7 inet 75.133.75.194 netmask 0xfffffff8 broadcast 75.133.75.199 inet6 fe80::21a:92ff:fe46:edf7%nfe1 prefixlen 64 scopeid 0x4 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active ath0: flags=8843 metric 0 mtu 2290 ether 7c:c3:a1:b3:fc:af nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng status: running lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 wlan0: flags=8843 metric 0 mtu 1500 ether 7c:c3:a1:b3:fc:af inet 192.168.13.1 netmask 0xffffff00 broadcast 192.168.13.255 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng status: running ssid BlackBox channel 6 (2437 MHz 11g ht/20) bssid 7c:c3:a1:b3:fc:af regdomain 100 indoor ecm authmode OPEN privacy OFF txpower 20 scanvalid 60 protmode RTSCTS ampdulimit 64k ampdudensity 8 shortgi wme burst dtimperiod 15 -dfs bintval 1000 pflog0: flags=141 metric 0 mtu 33152 nd6 options=9 root@Border:~ # -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 07:32:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) by hub.freebsd.org (Postfix) with ESMTP id A3E3B159; Tue, 23 Jul 2013 07:32:04 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 753684919; Tue, 23 Jul 2013 07:32:03 +0000 (UTC) Message-ID: <51EE309D.2030106@FreeBSD.org> Date: Tue, 23 Jul 2013 11:28:29 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Taku YAMAMOTO Subject: Re: IPSEC crashes after r253088 References: <20130721054323.915f865769e6042c7dc62d08@tackymt.homeip.net> In-Reply-To: <20130721054323.915f865769e6042c7dc62d08@tackymt.homeip.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 07:32:04 -0000 On 21.07.2013 00:43, Taku YAMAMOTO wrote: > After r253088, systems with IPSEC and KSTACK_PAGES < 4 crashes on > booting into multi-user mode. > > The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with > kernel stack overflow. > where type is struct ipsecstat which is 12560 bytes of size (larger than > 3 pages) of size when processing net.inet.ipsec.ipsecstats. Hi, Only few fields of struct ipsecstat is used, the rest fields are never updated. We can split it to several structures, or just remove unused fields. What is better? -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 10:54:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C07AD14D for ; Tue, 23 Jul 2013 10:54:34 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 82B402740 for ; Tue, 23 Jul 2013 10:54:34 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1V1aEb-000D8m-6v ; Tue, 23 Jul 2013 13:54:25 +0300 Date: Tue, 23 Jul 2013 13:54:25 +0300 From: Vitalij Satanivskij To: freebsd-current@freebsd.org Subject: Mysql5.5 MariaDB 5.5 built fail after r253321 Message-ID: <20130723105425.GA42334@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: satan@ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 10:54:34 -0000 Hello. After changes commited in Revision 253321 diff is - http://svnweb.freebsd.org/base/head/lib/msun/src/math.h?r1=253319&r2=253321&sortby=rev Build of databases/mysql55-server and databases/mariadb55-server/ failed. Both with same error. [ 47%] Building CXX object sql/CMakeFiles/sql.dir/item_func.cc.o In file included from /usr/ports/databases/mysql55-server/work/mysql-5.5.32/sql/item_func.cc:27: In file included from /usr/ports/databases/mysql55-server/work/mysql-5.5.32/include/my_global.h:351: /usr/include/include/sys/timeb.h:42:2: warning: "this file includes which is deprecated" [-W#warnings] #warning "this file includes which is deprecated" ^ /usr/ports/databases/mysql55-server/work/mysql-5.5.32/sql/item_func.cc:2344:29: error: controlling expression type 'volatile double' not compatible with any generic association type else if (!dec_negative && my_isinf(value_mul_tmp)) ^~~~~~~~~~~~~~~~~~~~~~~ /usr/ports/databases/mysql55-server/work/mysql-5.5.32/include/my_global.h:814:21: note: expanded from macro 'my_isinf' #define my_isinf(X) isinf(X) ^~~~~~~~ /usr/include/include/math.h:107:18: note: expanded from macro 'isinf' #define isinf(x) __fp_type_select(x, __isinff, __isinf, __isinfl) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/include/math.h:86:49: note: expanded from macro '__fp_type_select' #define __fp_type_select(x, f, d, ld) _Generic((0,(x)), \ ^~~~~ 1 warning and 1 error generated. --- sql/CMakeFiles/sql.dir/item_func.cc.o --- *** [sql/CMakeFiles/sql.dir/item_func.cc.o] Error code 1 make: stopped in /usr/ports/databases/mysql55-server/work/mysql-5.5.32 3 warnings generated. 1 warning generated. 1 warning generated. 1 error make: stopped in /usr/ports/databases/mysql55-server/work/mysql-5.5.32 *** Error code 2 Stop. make: stopped in /usr/ports/databases/mysql55-server/work/mysql-5.5.32 --- all --- *** [all] Error code 1 make: stopped in /usr/ports/databases/mysql55-server/work/mysql-5.5.32 1 error make: stopped in /usr/ports/databases/mysql55-server/work/mysql-5.5.32 After manual rollback, build finished successfuly. Question - is ports must be fixed or maybe system? From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 11:28:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36827A51 for ; Tue, 23 Jul 2013 11:28:35 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A09BA28C1 for ; Tue, 23 Jul 2013 11:28:34 +0000 (UTC) Received: (qmail 46612 invoked from network); 23 Jul 2013 12:16:50 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Jul 2013 12:16:50 -0000 Message-ID: <51EE68D8.9020603@freebsd.org> Date: Tue, 23 Jul 2013 13:28:24 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: IPSEC crashes after r253088 References: <20130721054323.915f865769e6042c7dc62d08@tackymt.homeip.net> <51EE309D.2030106@FreeBSD.org> In-Reply-To: <51EE309D.2030106@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , Taku YAMAMOTO , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 11:28:35 -0000 On 23.07.2013 09:28, Andrey V. Elsukov wrote: > On 21.07.2013 00:43, Taku YAMAMOTO wrote: >> After r253088, systems with IPSEC and KSTACK_PAGES < 4 crashes on >> booting into multi-user mode. >> >> The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with >> kernel stack overflow. > >> where type is struct ipsecstat which is 12560 bytes of size (larger than >> 3 pages) of size when processing net.inet.ipsec.ipsecstats. > > Hi, > > Only few fields of struct ipsecstat is used, the rest fields are never > updated. We can split it to several structures, or just remove unused > fields. What is better? Not storing it on the stack? -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 12:03:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) by hub.freebsd.org (Postfix) with ESMTP id C2881537; Tue, 23 Jul 2013 12:03:08 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 9B02920FD; Tue, 23 Jul 2013 12:03:07 +0000 (UTC) Message-ID: <51EE7024.5040706@FreeBSD.org> Date: Tue, 23 Jul 2013 15:59:32 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: IPSEC crashes after r253088 References: <20130721054323.915f865769e6042c7dc62d08@tackymt.homeip.net> <51EE309D.2030106@FreeBSD.org> <51EE68D8.9020603@freebsd.org> In-Reply-To: <51EE68D8.9020603@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , Taku YAMAMOTO , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 12:03:08 -0000 On 23.07.2013 15:28, Andre Oppermann wrote: > On 23.07.2013 09:28, Andrey V. Elsukov wrote: >> On 21.07.2013 00:43, Taku YAMAMOTO wrote: >>> After r253088, systems with IPSEC and KSTACK_PAGES < 4 crashes on >>> booting into multi-user mode. >>> >>> The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with >>> kernel stack overflow. >> >>> where type is struct ipsecstat which is 12560 bytes of size (larger than >>> 3 pages) of size when processing net.inet.ipsec.ipsecstats. >> >> Hi, >> >> Only few fields of struct ipsecstat is used, the rest fields are never >> updated. We can split it to several structures, or just remove unused >> fields. What is better? > > Not storing it on the stack? It seems that only about 120 bytes are used from all 12 Kbytes. The old ipsecstat structure was concatenated with newipsecstat some time ago. And in fact, only fields of newipsecstat are used. I see no sense to just waste 12*ncpu Kbytes of memory. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 12:04:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) by hub.freebsd.org (Postfix) with ESMTP id 0F6E866F; Tue, 23 Jul 2013 12:04:15 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 2B30F2255; Tue, 23 Jul 2013 12:04:12 +0000 (UTC) Message-ID: <51EE7066.9030403@FreeBSD.org> Date: Tue, 23 Jul 2013 16:00:38 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: IPSEC crashes after r253088 References: <20130721054323.915f865769e6042c7dc62d08@tackymt.homeip.net> <51EE309D.2030106@FreeBSD.org> <51EE68D8.9020603@freebsd.org> In-Reply-To: <51EE68D8.9020603@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/mixed; boundary="------------060701060904000402090606" Cc: George Neville-Neil , Taku YAMAMOTO , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 12:04:15 -0000 This is a multi-part message in MIME format. --------------060701060904000402090606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 23.07.2013 15:28, Andre Oppermann wrote: > On 23.07.2013 09:28, Andrey V. Elsukov wrote: >> On 21.07.2013 00:43, Taku YAMAMOTO wrote: >>> After r253088, systems with IPSEC and KSTACK_PAGES < 4 crashes on >>> booting into multi-user mode. >>> >>> The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with >>> kernel stack overflow. >> >>> where type is struct ipsecstat which is 12560 bytes of size (larger than >>> 3 pages) of size when processing net.inet.ipsec.ipsecstats. >> >> Hi, >> >> Only few fields of struct ipsecstat is used, the rest fields are never >> updated. We can split it to several structures, or just remove unused >> fields. What is better? > > Not storing it on the stack? Also, I already prepared patch to test. -- WBR, Andrey V. Elsukov --------------060701060904000402090606 Content-Type: text/plain; charset=UTF-8; name="ipsec.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ipsec.diff" Index: sys/netinet/sctp_input.c =================================================================== --- sys/netinet/sctp_input.c (revision 253562) +++ sys/netinet/sctp_input.c (working copy) @@ -5705,7 +5705,7 @@ sctp_common_input_processing(struct mbuf **mm, int #ifdef INET case AF_INET: if (ipsec4_in_reject(m, &inp->ip_inp.inp)) { - IPSECSTAT_INC(in_polvio); + IPSECSTAT_INC(ips_in_polvio); SCTP_STAT_INCR(sctps_hdrops); goto out; } @@ -5714,7 +5714,7 @@ sctp_common_input_processing(struct mbuf **mm, int #ifdef INET6 case AF_INET6: if (ipsec6_in_reject(m, &inp->ip_inp.inp)) { - IPSEC6STAT_INC(in_polvio); + IPSEC6STAT_INC(ips_in_polvio); SCTP_STAT_INCR(sctps_hdrops); goto out; } Index: sys/netinet/tcp_input.c =================================================================== --- sys/netinet/tcp_input.c (revision 253562) +++ sys/netinet/tcp_input.c (working copy) @@ -899,12 +899,12 @@ findpcb: #ifdef IPSEC #ifdef INET6 if (isipv6 && ipsec6_in_reject(m, inp)) { - IPSEC6STAT_INC(in_polvio); + IPSEC6STAT_INC(ips_in_polvio); goto dropunlock; } else #endif /* INET6 */ if (ipsec4_in_reject(m, inp) != 0) { - IPSECSTAT_INC(in_polvio); + IPSECSTAT_INC(ips_in_polvio); goto dropunlock; } #endif /* IPSEC */ Index: sys/netinet/udp_usrreq.c =================================================================== --- sys/netinet/udp_usrreq.c (revision 253562) +++ sys/netinet/udp_usrreq.c (working copy) @@ -282,7 +282,7 @@ udp_append(struct inpcb *inp, struct ip *ip, struc /* Check AH/ESP integrity. */ if (ipsec4_in_reject(n, inp)) { m_freem(n); - IPSECSTAT_INC(in_polvio); + IPSECSTAT_INC(ips_in_polvio); return; } #ifdef IPSEC_NAT_T @@ -1294,7 +1294,7 @@ udp4_espdecap(struct inpcb *inp, struct mbuf *m, i if (minlen > m->m_pkthdr.len) minlen = m->m_pkthdr.len; if ((m = m_pullup(m, minlen)) == NULL) { - IPSECSTAT_INC(in_inval); + IPSECSTAT_INC(ips_in_inval); return (NULL); /* Bypass caller processing. */ } data = mtod(m, caddr_t); /* Points to ip header. */ @@ -1334,7 +1334,7 @@ udp4_espdecap(struct inpcb *inp, struct mbuf *m, i uint32_t spi; if (payload <= sizeof(struct esp)) { - IPSECSTAT_INC(in_inval); + IPSECSTAT_INC(ips_in_inval); m_freem(m); return (NULL); /* Discard. */ } @@ -1355,7 +1355,7 @@ udp4_espdecap(struct inpcb *inp, struct mbuf *m, i tag = m_tag_get(PACKET_TAG_IPSEC_NAT_T_PORTS, 2 * sizeof(uint16_t), M_NOWAIT); if (tag == NULL) { - IPSECSTAT_INC(in_nomem); + IPSECSTAT_INC(ips_in_nomem); m_freem(m); return (NULL); /* Discard. */ } Index: sys/netinet6/ip6_forward.c =================================================================== --- sys/netinet6/ip6_forward.c (revision 253562) +++ sys/netinet6/ip6_forward.c (working copy) @@ -120,7 +120,7 @@ ip6_forward(struct mbuf *m, int srcrt) * before forwarding packet actually. */ if (ipsec6_in_reject(m, NULL)) { - IPSEC6STAT_INC(in_polvio); + IPSEC6STAT_INC(ips_in_polvio); m_freem(m); return; } @@ -182,7 +182,7 @@ ip6_forward(struct mbuf *m, int srcrt) sp = ipsec_getpolicybyaddr(m, IPSEC_DIR_OUTBOUND, IP_FORWARDING, &error); if (sp == NULL) { - IPSEC6STAT_INC(out_inval); + IPSEC6STAT_INC(ips_out_inval); IP6STAT_INC(ip6s_cantforward); if (mcopy) { #if 0 @@ -203,7 +203,7 @@ ip6_forward(struct mbuf *m, int srcrt) /* * This packet is just discarded. */ - IPSEC6STAT_INC(out_polvio); + IPSEC6STAT_INC(ips_out_polvio); IP6STAT_INC(ip6s_cantforward); KEY_FREESP(&sp); if (mcopy) { Index: sys/netinet6/raw_ip6.c =================================================================== --- sys/netinet6/raw_ip6.c (revision 253562) +++ sys/netinet6/raw_ip6.c (working copy) @@ -269,7 +269,7 @@ rip6_input(struct mbuf **mp, int *offp, int proto) */ if (n && ipsec6_in_reject(n, last)) { m_freem(n); - IPSEC6STAT_INC(in_polvio); + IPSEC6STAT_INC(ips_in_polvio); /* Do not inject data into pcb. */ } else #endif /* IPSEC */ @@ -301,7 +301,7 @@ rip6_input(struct mbuf **mp, int *offp, int proto) */ if ((last != NULL) && ipsec6_in_reject(m, last)) { m_freem(m); - IPSEC6STAT_INC(in_polvio); + IPSEC6STAT_INC(ips_in_polvio); IP6STAT_DEC(ip6s_delivered); /* Do not inject data into pcb. */ INP_RUNLOCK(last); Index: sys/netinet6/udp6_usrreq.c =================================================================== --- sys/netinet6/udp6_usrreq.c (revision 253562) +++ sys/netinet6/udp6_usrreq.c (working copy) @@ -141,7 +141,7 @@ udp6_append(struct inpcb *inp, struct mbuf *n, int /* Check AH/ESP integrity. */ if (ipsec6_in_reject(n, inp)) { m_freem(n); - IPSEC6STAT_INC(in_polvio); + IPSEC6STAT_INC(ips_in_polvio); return; } #endif /* IPSEC */ Index: sys/netipsec/ipsec.h =================================================================== --- sys/netipsec/ipsec.h (revision 253562) +++ sys/netipsec/ipsec.h (working copy) @@ -217,43 +217,17 @@ struct secspacq { /* statistics for ipsec processing */ struct ipsecstat { - uint64_t in_success; /* succeeded inbound process */ - uint64_t in_polvio; - /* security policy violation for inbound process */ - uint64_t in_nosa; /* inbound SA is unavailable */ - uint64_t in_inval; /* inbound processing failed due to EINVAL */ - uint64_t in_nomem; /* inbound processing failed due to ENOBUFS */ - uint64_t in_badspi; /* failed getting a SPI */ - uint64_t in_ahreplay; /* AH replay check failed */ - uint64_t in_espreplay; /* ESP replay check failed */ - uint64_t in_ahauthsucc; /* AH authentication success */ - uint64_t in_ahauthfail; /* AH authentication failure */ - uint64_t in_espauthsucc; /* ESP authentication success */ - uint64_t in_espauthfail; /* ESP authentication failure */ - uint64_t in_esphist[256]; - uint64_t in_ahhist[256]; - uint64_t in_comphist[256]; - uint64_t out_success; /* succeeded outbound process */ - uint64_t out_polvio; - /* security policy violation for outbound process */ - uint64_t out_nosa; /* outbound SA is unavailable */ - uint64_t out_inval; /* outbound process failed due to EINVAL */ - uint64_t out_nomem; /* inbound processing failed due to ENOBUFS */ - uint64_t out_noroute; /* there is no route */ - uint64_t out_esphist[256]; - uint64_t out_ahhist[256]; - uint64_t out_comphist[256]; + uint64_t ips_in_polvio; /* input: sec policy violation */ + uint64_t ips_in_nomem; /* input: no memory available */ + uint64_t ips_in_inval; /* input: generic error */ - uint64_t spdcachelookup; - uint64_t spdcachemiss; - - uint64_t ips_in_polvio; /* input: sec policy violation */ uint64_t ips_out_polvio; /* output: sec policy violation */ uint64_t ips_out_nosa; /* output: SA unavailable */ uint64_t ips_out_nomem; /* output: no memory available */ uint64_t ips_out_noroute; /* output: no route available */ uint64_t ips_out_inval; /* output: generic error */ uint64_t ips_out_bundlesa; /* output: bundled SA processed */ + uint64_t ips_mbcoalesced; /* mbufs coalesced during clone */ uint64_t ips_clcoalesced; /* clusters coalesced during clone */ uint64_t ips_clcopied; /* clusters copied during clone */ Index: usr.bin/netstat/ipsec.c =================================================================== --- usr.bin/netstat/ipsec.c (revision 253562) +++ usr.bin/netstat/ipsec.c (working copy) @@ -166,84 +166,18 @@ static struct val2str ipsec_compnames[] = { { -1, NULL }, }; -static void ipsec_hist(const u_quad_t *hist, size_t histmax, - const struct val2str *name, const char *title); static void print_ipsecstats(const struct ipsecstat *ipsecstat); - -/* - * Dump IPSEC statistics structure. - */ static void -ipsec_hist(const u_quad_t *hist, size_t histmax, const struct val2str *name, - const char *title) -{ - int first; - size_t proto; - const struct val2str *p; - - first = 1; - for (proto = 0; proto < histmax; proto++) { - if (hist[proto] <= 0) - continue; - if (first) { - printf("\t%s histogram:\n", title); - first = 0; - } - for (p = name; p && p->str; p++) { - if (p->val == (int)proto) - break; - } - if (p && p->str) { - printf("\t\t%s: %ju\n", p->str, (uintmax_t)hist[proto]); - } else { - printf("\t\t#%ld: %ju\n", (long)proto, - (uintmax_t)hist[proto]); - } - } -} - -static void print_ipsecstats(const struct ipsecstat *ipsecstat) { #define p(f, m) if (ipsecstat->f || sflag <= 1) \ printf(m, (uintmax_t)ipsecstat->f, plural(ipsecstat->f)) -#define pes(f, m) if (ipsecstat->f || sflag <= 1) \ - printf(m, (uintmax_t)ipsecstat->f, plurales(ipsecstat->f)) -#define hist(f, n, t) \ - ipsec_hist((f), sizeof(f)/sizeof(f[0]), (n), (t)); - - p(in_success, "\t%ju inbound packet%s processed successfully\n"); - p(in_polvio, "\t%ju inbound packet%s violated process security " - "policy\n"); - p(in_nosa, "\t%ju inbound packet%s with no SA available\n"); - p(in_inval, "\t%ju invalid inbound packet%s\n"); - p(in_nomem, "\t%ju inbound packet%s failed due to insufficient memory\n"); - p(in_badspi, "\t%ju inbound packet%s failed getting SPI\n"); - p(in_ahreplay, "\t%ju inbound packet%s failed on AH replay check\n"); - p(in_espreplay, "\t%ju inbound packet%s failed on ESP replay check\n"); - p(in_ahauthsucc, "\t%ju inbound packet%s considered authentic\n"); - p(in_ahauthfail, "\t%ju inbound packet%s failed on authentication\n"); - hist(ipsecstat->in_ahhist, ipsec_ahnames, "AH input"); - hist(ipsecstat->in_esphist, ipsec_espnames, "ESP input"); - hist(ipsecstat->in_comphist, ipsec_compnames, "IPComp input"); - - p(out_success, "\t%ju outbound packet%s processed successfully\n"); - p(out_polvio, "\t%ju outbound packet%s violated process security " - "policy\n"); - p(out_nosa, "\t%ju outbound packet%s with no SA available\n"); - p(out_inval, "\t%ju invalid outbound packet%s\n"); - p(out_nomem, "\t%ju outbound packet%s failed due to insufficient memory\n"); - p(out_noroute, "\t%ju outbound packet%s with no route\n"); - hist(ipsecstat->out_ahhist, ipsec_ahnames, "AH output"); - hist(ipsecstat->out_esphist, ipsec_espnames, "ESP output"); - hist(ipsecstat->out_comphist, ipsec_compnames, "IPComp output"); - p(spdcachelookup, "\t%ju SPD cache lookup%s\n"); - pes(spdcachemiss, "\t%ju SPD cache miss%s\n"); -#undef pes -#undef hist p(ips_in_polvio, "\t%ju inbound packet%s violated process " "security policy\n"); + p(ips_in_nomem, "\t%ju inbound packet%s failed due to " + "insufficient memory\n"); + p(ips_in_inval, "\t%ju invalid inbound packet%s\n"); p(ips_out_polvio, "\t%ju outbound packet%s violated process " "security policy\n"); p(ips_out_nosa, "\t%ju outbound packet%s with no SA available\n"); --------------060701060904000402090606-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 13:09:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D21A4C2E; Tue, 23 Jul 2013 13:09:37 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A0212D9E; Tue, 23 Jul 2013 13:09:37 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w60so926615wes.15 for ; Tue, 23 Jul 2013 06:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vq5QtomxAxmhZhIhi7xCfB8vpDpE3G6AOxkdfFoGas8=; b=ae2I0TxxUD1fjuXOSPSEncHbM1HQjovvKG/k/m21oikbFBw8B2/squ2dkE5LQjiz+k zeiBaZCjMBhGo4XJUaqB9CAlpJG+PsFyfLgq+vxrD/sdOpWnkbiCdZWhBnMsHkboeK2i v/9d/rx9sCVXebca3Ad6t4FNQqKFSalbw2KdtBp35NA8FR1MVsEdlyrW0qCkOvAsb4WR rxhYBnZwS8O0xRH6lbGLEAM5rav2YIEcZOp3dsXwNHS/kxlp4A6CY/lVgp61xQYvLCMp ZyQyLrX0e5InmOr5DEnOTGfWUOXKcskmpB6t3ab+XGID58k+ILavqywTEWWIegfFD1kD b2Ww== MIME-Version: 1.0 X-Received: by 10.180.74.146 with SMTP id t18mr22058230wiv.3.1374584975481; Tue, 23 Jul 2013 06:09:35 -0700 (PDT) Received: by 10.194.240.132 with HTTP; Tue, 23 Jul 2013 06:09:35 -0700 (PDT) Date: Tue, 23 Jul 2013 17:09:35 +0400 Message-ID: Subject: Not work ATH (AR9285) after update From: Andrey Fesenko To: "freebsd-wireless@freebsd.org" , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 13:09:37 -0000 Hello, i'm horrible news, after update my notebook not nave wi-fi :( full update system, build and install world and kernel. # uname -a FreeBSD x220.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253562: Tue Jul 23 14:44:07 MSK 2013 root@x220.local:/usr/obj/usr/src/sys/W_BOOK amd64 # grep ATH /usr/src/sys/amd64/conf/W_BOOK options ATH_ENABLE_11N options ATH_DEBUG options ATH_DIAGAPI ath0@pci0:3:0:0: class=0x028000 card=0x1a891a3b chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR9285 Wireless Network Adapter (PCI-Express)' class = network # ifconfig ath0: flags=8843 metric 0 mtu 2290 ether 00:25:d3:7b:94:87 nd6 options=21 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8c43 metric 0 mtu 1500 ether 00:25:d3:7b:94:87 inet6 fe80::225:d3ff:fe7b:9487%wlan0 prefixlen 64 scopeid 0x4 nd6 options=23 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 8 (2447 MHz 11g) regdomain 33411 country RU indoor ecm authmode WPA1+WPA2/802.11i privacy MIXED deftxkey UNDEF txpower 20 bmiss 7 scanvalid 60 protmode CTS wme burst roaming MANUAL # ifconfig wlan0 list scan SSID/MESH ID BSSID CHAN RATE S:N INT CAPS APT-SPB2 b8:a3:86:4a:75:6a 6 54M -92:-96 100 EP HTCAP WPA RSN WME WPS THD1 74:ea:3a:d1:37:46 10 54M -85:-96 100 EP RSN HTCAP WME Balt1 00:90:4c:c1:00:00 1 54M -90:-96 100 EP RSN TP-LINK_904D2A 64:70:02:90:4d:2a 11 54M -94:-96 100 EPS RSN HTCAP WME ATH WPS /var/log/messages ... Jul 23 15:34:24 x220 wpa_supplicant[669]: wlan0: CTRL-EVENT-TERMINATING Jul 23 15:34:24 x220 kernel: wlan0: Ethernet address: 00:25:d3:7b:94:87 Jul 23 15:34:24 x220 devd: Executing '/etc/pccard_ether wlan0 start' Jul 23 15:34:24 x220 wpa_supplicant[2563]: Successfully initialized wpa_supplicant Jul 23 15:34:24 x220 wpa_supplicant[2571]: Successfully initialized wpa_supplicant Jul 23 15:34:24 x220 wpa_supplicant[2571]: ctrl_iface exists and seems to be in use - cannot override it Jul 23 15:34:24 x220 wpa_supplicant[2571]: Delete '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore Jul 23 15:34:24 x220 wpa_supplicant[2571]: Failed to initialize control interface '/var/run/wpa_supplicant'. You may have another wpa_supplicant process already running or the file was left by an unclean termination of wpa_supplicant in which case you will need to manually remove this file before starting wpa_supplicant again. Jul 23 15:34:24 x220 wpa_supplicant[2571]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Operation not supported Jul 23 15:34:24 x220 wpa_supplicant[2571]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Operation not supported Jul 23 15:34:24 x220 root: /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant Jul 23 15:34:24 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:24 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:25 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:25 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:26 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:26 x220 kernel: ath0: ath_reset_grablock: didn't finish after 10 iterations Jul 23 15:34:26 x220 kernel: ath0: ath_reset_grablock: warning, recursive reset path! Jul 23 15:34:26 x220 kernel: ath0: ath_reset: concurrent reset! Danger! Jul 23 15:34:26 x220 kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing Jul 23 15:34:26 x220 kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing Jul 23 15:34:26 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:27 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:27 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan Jul 23 15:34:29 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: didn't finish after 10 iterations Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: warning, recursive reset path! From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 13:13:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BC5C8E33; Tue, 23 Jul 2013 13:13:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B3682DE1; Tue, 23 Jul 2013 13:13:16 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id c10so3821360wiw.4 for ; Tue, 23 Jul 2013 06:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ltv3Yz++pVZBOfax7Qu1kqr9vLYHhd6l8GicDQqM23Q=; b=u35feric7HX0fq4z8kozsoHlvdk/I9hTEHbLSy+bQnEu8sF2/Bd/0cmWaa/cJD1ZUc 9jKnx7nwQ5WrlgacPyMOmTE7OmQaJbgUdcmv+tGZZG8rcVNZoi2fjhOmWakiTNlxWMDr QUG7Hj/KawrfdT5mnaS2AXTTuriLfrfSISZJqFYCoHSQoZN8/duubzvavElirs7HHQAP VqhbCfBW732T2Bgl8lzXMSviqVu8ORjDinIyK1oj1P9AbbPkcE75AD6h9zNA1LB9I22R uotAldqQlKHAopltaSe0nikwuPmphYbd3bycucVsUZGbb6RrY+pmDWmETdC8/CiXFYv+ YzZQ== MIME-Version: 1.0 X-Received: by 10.180.185.148 with SMTP id fc20mr22164349wic.0.1374585195441; Tue, 23 Jul 2013 06:13:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Tue, 23 Jul 2013 06:13:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jul 2013 06:13:15 -0700 X-Google-Sender-Auth: OtE_Hr9648Vm42wHdgNsRaHknd4 Message-ID: Subject: Re: Not work ATH (AR9285) after update From: Adrian Chadd To: Andrey Fesenko Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 13:13:17 -0000 .. are two copies of wpa_supplicant running? -adrian On 23 July 2013 06:09, Andrey Fesenko wrote: > Hello, > i'm horrible news, after update my notebook not nave wi-fi :( > full update system, build and install world and kernel. > > # uname -a > FreeBSD x220.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253562: Tue > Jul 23 14:44:07 MSK 2013 > root@x220.local:/usr/obj/usr/src/sys/W_BOOK amd64 > > # grep ATH /usr/src/sys/amd64/conf/W_BOOK > options ATH_ENABLE_11N > options ATH_DEBUG > options ATH_DIAGAPI > > ath0@pci0:3:0:0: class=0x028000 card=0x1a891a3b chip=0x002b168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR9285 Wireless Network Adapter (PCI-Express)' > class = network > > # ifconfig > ath0: flags=8843 metric 0 mtu 2290 > ether 00:25:d3:7b:94:87 > nd6 options=21 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > wlan0: flags=8c43 > metric 0 mtu 1500 > ether 00:25:d3:7b:94:87 > inet6 fe80::225:d3ff:fe7b:9487%wlan0 prefixlen 64 scopeid 0x4 > nd6 options=23 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid "" channel 8 (2447 MHz 11g) > regdomain 33411 country RU indoor ecm authmode WPA1+WPA2/802.11i > privacy MIXED deftxkey UNDEF txpower 20 bmiss 7 scanvalid 60 > protmode CTS wme burst roaming MANUAL > # ifconfig wlan0 list scan > SSID/MESH ID BSSID CHAN RATE S:N INT CAPS > APT-SPB2 b8:a3:86:4a:75:6a 6 54M -92:-96 100 EP HTCAP > WPA RSN WME WPS > THD1 74:ea:3a:d1:37:46 10 54M -85:-96 100 EP RSN HTCAP WME > Balt1 00:90:4c:c1:00:00 1 54M -90:-96 100 EP RSN > TP-LINK_904D2A 64:70:02:90:4d:2a 11 54M -94:-96 100 EPS RSN > HTCAP WME ATH WPS > > /var/log/messages > ... > Jul 23 15:34:24 x220 wpa_supplicant[669]: wlan0: CTRL-EVENT-TERMINATING > Jul 23 15:34:24 x220 kernel: wlan0: Ethernet address: 00:25:d3:7b:94:87 > Jul 23 15:34:24 x220 devd: Executing '/etc/pccard_ether wlan0 start' > Jul 23 15:34:24 x220 wpa_supplicant[2563]: Successfully initialized > wpa_supplicant > Jul 23 15:34:24 x220 wpa_supplicant[2571]: Successfully initialized > wpa_supplicant > Jul 23 15:34:24 x220 wpa_supplicant[2571]: ctrl_iface exists and seems > to be in use - cannot override it > Jul 23 15:34:24 x220 wpa_supplicant[2571]: Delete > '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore > Jul 23 15:34:24 x220 wpa_supplicant[2571]: Failed to initialize > control interface '/var/run/wpa_supplicant'. You may have another > wpa_supplicant process already running or the file was left by an > unclean termination of wpa_supplicant in which case you will need to > manually remove this file before starting wpa_supplicant again. > Jul 23 15:34:24 x220 wpa_supplicant[2571]: ioctl[SIOCS80211, op=26, > val=0, arg_len=0]: Operation not supported > Jul 23 15:34:24 x220 wpa_supplicant[2571]: ioctl[SIOCS80211, op=26, > val=0, arg_len=0]: Operation not supported > Jul 23 15:34:24 x220 root: /etc/rc.d/wpa_supplicant: WARNING: failed > to start wpa_supplicant > Jul 23 15:34:24 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, > val=0, arg_len=128]: Operation now in progress > Jul 23 15:34:24 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan > Jul 23 15:34:25 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, > val=0, arg_len=128]: Operation now in progress > Jul 23 15:34:25 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan > Jul 23 15:34:26 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, > val=0, arg_len=128]: Operation now in progress > Jul 23 15:34:26 x220 kernel: ath0: ath_reset_grablock: didn't finish > after 10 iterations > Jul 23 15:34:26 x220 kernel: ath0: ath_reset_grablock: warning, > recursive reset path! > Jul 23 15:34:26 x220 kernel: ath0: ath_reset: concurrent reset! Danger! > Jul 23 15:34:26 x220 kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing > Jul 23 15:34:26 x220 kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing > Jul 23 15:34:26 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan > Jul 23 15:34:27 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, > val=0, arg_len=128]: Operation now in progress > Jul 23 15:34:27 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan > Jul 23 15:34:29 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, > val=0, arg_len=128]: Operation now in progress > Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: didn't finish > after 10 iterations > Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: warning, > recursive reset path! > _______________________________________________ > 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 23 13:34:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5BB5B1A6; Tue, 23 Jul 2013 13:34:19 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3884C2EA7; Tue, 23 Jul 2013 13:34:18 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r6NDY51O004312 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 06:34:08 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51EE8647.3080401@freebsd.org> Date: Tue, 23 Jul 2013 21:33:59 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: IPSEC crashes after r253088 References: <20130721054323.915f865769e6042c7dc62d08@tackymt.homeip.net> <51EE309D.2030106@FreeBSD.org> <51EE68D8.9020603@freebsd.org> <51EE7066.9030403@FreeBSD.org> In-Reply-To: <51EE7066.9030403@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: George Neville-Neil , Taku YAMAMOTO , freebsd-current@freebsd.org, Andre Oppermann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 13:34:19 -0000 On 7/23/13 8:00 PM, Andrey V. Elsukov wrote: > On 23.07.2013 15:28, Andre Oppermann wrote: >> On 23.07.2013 09:28, Andrey V. Elsukov wrote: >>> On 21.07.2013 00:43, Taku YAMAMOTO wrote: >>>> After r253088, systems with IPSEC and KSTACK_PAGES < 4 crashes on >>>> booting into multi-user mode. >>>> >>>> The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with >>>> kernel stack overflow. >>>> where type is struct ipsecstat which is 12560 bytes of size (larger than >>>> 3 pages) of size when processing net.inet.ipsec.ipsecstats. >>> Hi, >>> >>> Only few fields of struct ipsecstat is used, the rest fields are never >>> updated. We can split it to several structures, or just remove unused >>> fields. What is better? >> Not storing it on the stack? > Also, I already prepared patch to test. 'both'.. one isn't supposed to have structures of any size on the stack in the kernel. At one stage the max was 64 bytes.. has grown since then obviously. *And* it could do with simplification. > > > _______________________________________________ > 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 23 13:47:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B9C2E66E for ; Tue, 23 Jul 2013 13:47:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1ADE62F3C for ; Tue, 23 Jul 2013 13:47:49 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id z12so1900687wgg.34 for ; Tue, 23 Jul 2013 06:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dyzU/1WbTvS2GUvVvROJDxJ2Ma2NQuzubO88FH77Vg4=; b=T0EEbwTtO2lFANfmV7er+p0LIg0bKIHNO5fDUrx09Eh2RZU0I7qkGO6ntp3kD3Mgg1 lrYAHDlHwk+foUrHfdwv3G8xAiH+iugp+hLrSNeCZ6caAXvigEQ09GC5fb1F/KKLq5X+ pQq5SpFChE6wZTmzm7cg5cv1LTwksXNmmYUJHl6jObZlUWU1fytNlPeCLL7QnR8TB4Xs vp1erjRs3vaILwrgafPyogy3pgm7cgd4+5pJNnnJm8uae7DDrs0554oH2uNpAXs6qBg0 XQXWOnKzWLOHf6SYgFaLM/DWPBJyNRjKD+oka8kzzFeJLKEc9UZqI6q1UB4Rs3pqOFkM a1Og== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr22099822wik.30.1374587268303; Tue, 23 Jul 2013 06:47:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Tue, 23 Jul 2013 06:47:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jul 2013 06:47:48 -0700 X-Google-Sender-Auth: mvtYy71Ua95vxqKlfPQT4dmxNAI Message-ID: Subject: Re: Network card issues ifconfig down ifconfig up required From: Adrian Chadd To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 13:47:50 -0000 The ethernet, or wifi, or both? -adrian On 23 July 2013 00:26, Sam Fourman Jr. wrote: > Hello list, > > I decided to use a Old Asus Motherboard, for a Router / Firewall > I decided to use -HEAD to get the latest WIFI support... > > I seem to have to ifconfig down and ifconfig up the interfaces before they > become active... is there any way to fix this? > > I have a full dmesg, pciconf -lcbv, kenv | grep smbios, as well as a > ifconfig below > > > root@Border:~ # dmesg > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-CURRENT #2 r253560: Tue Jul 23 04:49:04 UTC 2013 > root@Border:/usr/obj/usr/src/sys/BORDER amd64 > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > WARNING: WITNESS option enabled, expect reduced performance. > CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2400.03-MHz K8-class > CPU) > Origin = "GenuineIntel" Id = 0x6f7 Family = 0x6 Model = 0xf Stepping > = 7 > > Features=0xbfebfbff > Features2=0xe3bd > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 8589934592 (8192 MB) > avail memory = 7968894976 (7599 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > ioapic0: Changing APIC ID to 4 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, cfdf0000 (3) failed > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > attimer0: port 0x40-0x43 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > hpet0: iomem 0xfeff0000-0xfeff03ff irq 0,8 on > acpi0 > Timecounter "HPET" frequency 25000000 Hz quality 950 > atrtc0: port 0x70-0x73 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pci0: at device 0.2 (no driver attached) > pci0: at device 0.3 (no driver attached) > pci0: at device 0.4 (no driver attached) > pci0: at device 0.5 (no driver attached) > pci0: at device 0.6 (no driver attached) > pci0: at device 0.7 (no driver attached) > pci0: at device 1.0 (no driver attached) > pci0: at device 1.1 (no driver attached) > pci0: at device 1.2 (no driver attached) > pci0: at device 1.3 (no driver attached) > pci0: at device 1.4 (no driver attached) > pci0: at device 1.5 (no driver attached) > pci0: at device 1.6 (no driver attached) > pci0: at device 2.0 (no driver attached) > pci0: at device 2.1 (no driver attached) > pci0: at device 2.2 (no driver attached) > pci0: at device 9.0 (no driver attached) > isab0: at device 10.0 on pci0 > isa0: on isab0 > pci0: at device 10.1 (no driver attached) > ohci0: mem 0xeffff000-0xefffffff irq > 21 at device 11.0 on pci0 > usbus0 on ohci0 > ehci0: mem 0xefffe000-0xefffe0ff > irq 22 at device 11.1 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 13.0 on pci0 > ata0: at channel 0 on atapci0 > ata1: at channel 1 on atapci0 > atapci1: port > 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem > 0xefffd000-0xefffdfff irq 23 at device 14.0 on pci0 > ata2: at channel 0 on atapci1 > ata3: at channel 1 on atapci1 > atapci2: port > 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf200-0xf20f mem > 0xefffc000-0xefffcfff irq 20 at device 14.1 on pci0 > ata4: at channel 0 on atapci2 > ata5: at channel 1 on atapci2 > atapci3: port > 0xf100-0xf107,0xf000-0xf003,0xef00-0xef07,0xee00-0xee03,0xed00-0xed0f mem > 0xefffb000-0xefffbfff irq 21 at device 14.2 on pci0 > ata6: at channel 0 on atapci3 > ata7: at channel 1 on atapci3 > pcib1: at device 15.0 on pci0 > pci1: on pcib1 > re0: port > 0xdc00-0xdcff mem 0xefdff000-0xefdff0ff irq 16 at device 6.0 on pci1 > re0: Chip rev. 0x10000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re0: Ethernet address: 00:14:d1:25:d8:23 > re1: port > 0xd800-0xd8ff mem 0xefdfe000-0xefdfe0ff irq 17 at device 7.0 on pci1 > re1: Chip rev. 0x10000000 > re1: MAC rev. 0x00000000 > miibus1: on re1 > rgephy1: PHY 1 on miibus1 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re1: Ethernet address: 00:14:d1:25:d8:44 > pci1: at device 11.0 (no driver attached) > nfe0: port 0xec00-0xec07 mem > 0xefffa000-0xefffafff,0xefff9000-0xefff90ff,0xefff8000-0xefff800f irq 22 at > device 17.0 on pci0 > miibus2: on nfe0 > e1000phy0: PHY 19 on miibus2 > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, > auto-flow > nfe0: Ethernet address: 00:1a:92:46:e0:44 > nfe1: port 0xeb00-0xeb07 mem > 0xefff7000-0xefff7fff,0xefff6000-0xefff60ff,0xefff5000-0xefff500f irq 23 at > device 18.0 on pci0 > miibus3: on nfe1 > e1000phy1: PHY 1 on miibus3 > e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, > auto-flow > nfe1: Ethernet address: 00:1a:92:46:ed:f7 > pcib2: at device 19.0 on pci0 > pci2: on pcib2 > vgapci0: mem > 0xec000000-0xecffffff,0xd0000000-0xdfffffff,0xed000000-0xedffffff irq 16 at > device 0.0 on pci2 > pcib3: at device 22.0 on pci0 > pci3: on pcib3 > siis0: port 0xbc00-0xbc7f mem > 0xefcff000-0xefcff07f,0xefcf8000-0xefcfbfff irq 16 at device 0.0 on pci3 > siisch0: at channel 0 on siis0 > siisch1: at channel 1 on siis0 > pcib4: at device 23.0 on pci0 > pci4: on pcib4 > ath0: mem 0xefac0000-0xefadffff irq 16 at device 0.0 on > pci4 > ar9300_set_stub_functions: setting stub functions > ar9300_set_stub_functions: setting stub functions > ar9300_attach: calling ar9300_hw_attach > ar9300_hw_attach: calling ar9300_eeprom_attach > ar9300_flash_map: unimplemented for now > Restoring Cal data from DRAM > Restoring Cal data from EEPROM > ar9300_hw_attach: ar9300_eeprom_attach returned 0 > ath0: RX status length: 48 > ath0: RX buffer size: 4096 > ath0: TX descriptor length: 128 > ath0: TX status length: 36 > ath0: TX buffers per descriptor: 4 > ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 > ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries > ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] 3 RX streams; 3 TX streams > ath0: AR9380 mac 448.3 RF5110 phy 0.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 > acpi_tz0: on acpi0 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > orm0: at iomem 0xd0000-0xd3fff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > ppc0: cannot reserve I/O port range > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 924092406000924 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 924092406000924 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > est2: on cpu2 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 924092406000924 > device_attach: est2 attach returned 6 > p4tcc2: on cpu2 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 924092406000924 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 480Mbps High Speed USB v2.0 > ugen1.1: at usbus1 > uhub0: on usbus1 > ugen0.1: at usbus0 > uhub1: on usbus0 > uhub1: 10 ports with 10 removable, self powered > uhub0: 10 ports with 10 removable, self powered > ada0 at ata2 bus 0 scbus2 target 0 lun 0 > ada0: ATA-7 SATA 1.x device > ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) > ada0: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > ada1 at ata3 bus 0 scbus3 target 0 lun 0 > ada1: ATA-7 SATA 1.x device > ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) > ada1: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad6 > SMP: AP CPU #2 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > Timecounter "TSC-low" frequency 1200012795 Hz quality 1000 > WARNING: WITNESS option enabled, expect reduced performance. > Root mount waiting for: usbus1 > Trying to mount root from zfs:Puffy []... > ugen0.2: at usbus0 > ukbd0: on > usbus0 > kbd2 at ukbd0 > ar9300_Stub_GetCTSTimeout: called > ar9300_Stub_GetCTSTimeout: called > ar9300_Stub_GetAntennaSwitch: called > ar9300_Stub_GetAntennaSwitch: called > wlan0: Ethernet address: 7c:c3:a1:b3:fc:af > uhid0: on > usbus0 > re0: link state changed to DOWN > re0: link state changed to UP > nfe1: link state changed to DOWN > nfe1: link state changed to UP > > > > root@Border:~ # pciconf -lcbv > hostb0@pci0:0:0:0: class=0x060000 card=0x00000000 chip=0x03a110de rev=0xa2 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Host Bridge' > class = bridge > subclass = HOST-PCI > cap 08[40] = HT host > none0@pci0:0:0:1: class=0x050000 card=0x00000000 chip=0x03ac10de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none1@pci0:0:0:2: class=0x050000 card=0x00000000 chip=0x03aa10de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none2@pci0:0:0:3: class=0x050000 card=0x00000000 chip=0x03a910de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none3@pci0:0:0:4: class=0x050000 card=0x00000000 chip=0x03ab10de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none4@pci0:0:0:5: class=0x050000 card=0x00000000 chip=0x03a810de rev=0xa2 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none5@pci0:0:0:6: class=0x050000 card=0x00000000 chip=0x03b510de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none6@pci0:0:0:7: class=0x050000 card=0x00000000 chip=0x03b410de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none7@pci0:0:1:0: class=0x050000 card=0x00000000 chip=0x03ad10de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none8@pci0:0:1:1: class=0x050000 card=0x00000000 chip=0x03ae10de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none9@pci0:0:1:2: class=0x050000 card=0x00000000 chip=0x03af10de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none10@pci0:0:1:3: class=0x050000 card=0x00000000 chip=0x03b010de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none11@pci0:0:1:4: class=0x050000 card=0x00000000 chip=0x03b110de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none12@pci0:0:1:5: class=0x050000 card=0x00000000 chip=0x03b210de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none13@pci0:0:1:6: class=0x050000 card=0x00000000 chip=0x03b310de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none14@pci0:0:2:0: class=0x050000 card=0x00000000 chip=0x03b610de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none15@pci0:0:2:1: class=0x050000 card=0x00000000 chip=0x03bc10de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none16@pci0:0:2:2: class=0x050000 card=0x00000000 chip=0x03ba10de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'C55 Memory Controller' > class = memory > subclass = RAM > none17@pci0:0:9:0: class=0x050000 card=0xcb841043 chip=0x036910de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP55 Memory Controller' > class = memory > subclass = RAM > cap 08[44] = HT slave > cap 00[e0] = unknown > isab0@pci0:0:10:0: class=0x060100 card=0xcb841043 chip=0x036010de rev=0xa2 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP55 LPC Bridge' > class = bridge > subclass = PCI-ISA > none18@pci0:0:10:1: class=0x0c0500 card=0xcb841043 chip=0x036810de rev=0xa2 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP55 SMBus' > class = serial bus > subclass = SMBus > bar [10] = type I/O Port, range 32, base 0xff00, size 64, enabled > bar [20] = type I/O Port, range 32, base 0x1c00, size 64, enabled > bar [24] = type I/O Port, range 32, base 0x1c80, size 64, enabled > cap 01[44] = powerspec 2 supports D0 D3 current D0 > ohci0@pci0:0:11:0: class=0x0c0310 card=0xcb841043 chip=0x036c10de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP55 USB Controller' > class = serial bus > subclass = USB > bar [10] = type Memory, range 32, base 0xeffff000, size 4096, enabled > cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > ehci0@pci0:0:11:1: class=0x0c0320 card=0xcb841043 chip=0x036d10de rev=0xa2 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP55 USB Controller' > class = serial bus > subclass = USB > bar [10] = type Memory, range 32, base 0xefffe000, size 256, enabled > cap 0a[44] = EHCI Debug Port at offset 0x98 in map 0x14 > cap 01[80] = powerspec 2 supports D0 D1 D2 D3 current D0 > atapci0@pci0:0:13:0: class=0x01018a card=0xcb841043 chip=0x036e10de > rev=0xa1 hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP55 IDE' > class = mass storage > subclass = ATA > bar [20] = type I/O Port, range 32, base 0xfc00, size 16, enabled > cap 01[44] = powerspec 2 supports D0 D3 current D0 > atapci1@pci0:0:14:0: class=0x010185 card=0xcb841043 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP55 SATA Controller' > class = mass storage > subclass = ATA > bar [10] = type I/O Port, range 32, base 0x9f0, size 8, enabled > bar [14] = type I/O Port, range 32, base 0xbf0, size 4, enabled > bar [18] = type I/O Port, range 32, base 0x970, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0xb70, size 4, enabled > bar [20] = type I/O Port, range 32, base 0xf700, size 16, enabled > bar [24] = type Memory, range 32, base 0xefffd000, size 4096, enabled > cap 01[44] = powerspec 2 supports D0 D3 current D0 > cap 05[b0] = MSI supports 4 messages, 64 bit > cap 08[cc] = HT MSI fixed address window disabled at 0xfee00000 > atapci2@pci0:0:14:1: class=0x010185 card=0xcb841043 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP55 SATA Controller' > class = mass storage > subclass = ATA > bar [10] = type I/O Port, range 32, base 0x9e0, size 8, enabled > bar [14] = type I/O Port, range 32, base 0xbe0, size 4, enabled > bar [18] = type I/O Port, range 32, base 0x960, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0xb60, size 4, enabled > bar [20] = type I/O Port, range 32, base 0xf200, size 16, enabled > bar [24] = type Memory, range 32, base 0xefffc000, size 4096, enabled > cap 01[44] = powerspec 2 supports D0 D3 current D0 > cap 05[b0] = MSI supports 4 messages, 64 bit > cap 08[cc] = HT MSI fixed address window disabled at 0xfee00000 > atapci3@pci0:0:14:2: class=0x010185 card=0xcb841043 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP55 SATA Controller' > class = mass storage > subclass = ATA > bar [10] = type I/O Port, range 32, base 0xf100, size 8, enabled > bar [14] = type I/O Port, range 32, base 0xf000, size 4, enabled > bar [18] = type I/O Port, range 32, base 0xef00, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0xee00, size 4, enabled > bar [20] = type I/O Port, range 32, base 0xed00, size 16, enabled > bar [24] = type Memory, range 32, base 0xefffb000, size 4096, enabled > cap 01[44] = powerspec 2 supports D0 D3 current D0 > cap 05[b0] = MSI supports 4 messages, 64 bit > cap 08[cc] = HT MSI fixed address window disabled at 0xfee00000 > pcib1@pci0:0:15:0: class=0x060401 card=0xcb8410de chip=0x037010de rev=0xa2 > hdr=0x01 > vendor = 'NVIDIA Corporation' > device = 'MCP55 PCI bridge' > class = bridge > subclass = PCI-PCI > cap 0d[b8] = PCI Bridge card=0xcb8410de > cap 08[8c] = HT MSI address window disabled at 0xfee00000 > nfe0@pci0:0:17:0: class=0x068000 card=0xcb841043 chip=0x037310de rev=0xa2 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP55 Ethernet' > class = bridge > bar [10] = type Memory, range 32, base 0xefffa000, size 4096, enabled > bar [14] = type I/O Port, range 32, base 0xec00, size 8, enabled > bar [18] = type Memory, range 32, base 0xefff9000, size 256, enabled > bar [1c] = type Memory, range 32, base 0xefff8000, size 16, enabled > cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > cap 11[70] = MSI-X supports 8 messages, enabled > Table in map 0x18[0x0], PBA in map 0x1c[0x0] > cap 05[50] = MSI supports 8 messages, 64 bit, vector masks > cap 08[6c] = HT MSI fixed address window enabled at 0xfee00000 > nfe1@pci0:0:18:0: class=0x068000 card=0xcb841043 chip=0x037310de rev=0xa2 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP55 Ethernet' > class = bridge > bar [10] = type Memory, range 32, base 0xefff7000, size 4096, enabled > bar [14] = type I/O Port, range 32, base 0xeb00, size 8, enabled > bar [18] = type Memory, range 32, base 0xefff6000, size 256, enabled > bar [1c] = type Memory, range 32, base 0xefff5000, size 16, enabled > cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > cap 11[70] = MSI-X supports 8 messages, enabled > Table in map 0x18[0x0], PBA in map 0x1c[0x0] > cap 05[50] = MSI supports 8 messages, 64 bit, vector masks > cap 08[6c] = HT MSI fixed address window enabled at 0xfee00000 > pcib2@pci0:0:19:0: class=0x060400 card=0x000010de chip=0x037610de rev=0xa2 > hdr=0x01 > vendor = 'NVIDIA Corporation' > device = 'MCP55 PCI Express bridge' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x000010de > cap 01[48] = powerspec 2 supports D0 D3 current D0 > cap 05[50] = MSI supports 2 messages, 64 bit > cap 08[60] = HT MSI address window disabled at 0xfee00000 > cap 10[80] = PCI-Express 1 root port slot max data 128(256) link x8(x8) > speed 2.5(2.5) ASPM disabled(L0s/L1) > ecap 0002[100] = VC 1 max VC0 > pcib3@pci0:0:22:0: class=0x060400 card=0x000010de chip=0x037810de rev=0xa2 > hdr=0x01 > vendor = 'NVIDIA Corporation' > device = 'MCP55 PCI Express bridge' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x000010de > cap 01[48] = powerspec 2 supports D0 D3 current D0 > cap 05[50] = MSI supports 2 messages, 64 bit > cap 08[60] = HT MSI address window disabled at 0xfee00000 > cap 10[80] = PCI-Express 1 root port slot max data 256(256) link x1(x1) > speed 2.5(2.5) ASPM disabled(L0s/L1) > ecap 0002[100] = VC 1 max VC0 > pcib4@pci0:0:23:0: class=0x060400 card=0x000010de chip=0x037510de rev=0xa2 > hdr=0x01 > vendor = 'NVIDIA Corporation' > device = 'MCP55 PCI Express bridge' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x000010de > cap 01[48] = powerspec 2 supports D0 D3 current D0 > cap 05[50] = MSI supports 2 messages, 64 bit > cap 08[60] = HT MSI address window disabled at 0xfee00000 > cap 10[80] = PCI-Express 1 root port slot max data 128(256) link x1(x1) > speed 2.5(2.5) ASPM disabled(L0s/L1) > ecap 0002[100] = VC 1 max VC0 > re0@pci0:1:6:0: class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 > hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL8169 PCI Gigabit Ethernet Controller' > class = network > subclass = ethernet > bar [10] = type I/O Port, range 32, base 0xdc00, size 256, enabled > bar [14] = type Memory, range 32, base 0xefdff000, size 256, enabled > cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 > re1@pci0:1:7:0: class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 > hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL8169 PCI Gigabit Ethernet Controller' > class = network > subclass = ethernet > bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled > bar [14] = type Memory, range 32, base 0xefdfe000, size 256, enabled > cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 > none19@pci0:1:11:0: class=0x0c0010 card=0x81fe1043 chip=0x30441106 rev=0xc0 > hdr=0x00 > vendor = 'VIA Technologies, Inc.' > device = 'VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller' > class = serial bus > subclass = FireWire > bar [10] = type Memory, range 32, base 0xefdfd000, size 2048, enabled > bar [14] = type I/O Port, range 32, base 0xd400, size 128, enabled > cap 01[50] = powerspec 2 supports D0 D2 D3 current D0 > vgapci0@pci0:2:0:0: class=0x030000 card=0x99101462 chip=0x016110de rev=0xa1 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'NV44 [GeForce 6200 TurboCache(TM)]' > class = display > subclass = VGA > bar [10] = type Memory, range 32, base 0xec000000, size 16777216, > enabled > bar [14] = type Prefetchable Memory, range 64, base 0xd0000000, size > 268435456, enabled > bar [1c] = type Memory, range 64, base 0xed000000, size 16777216, > enabled > cap 01[60] = powerspec 2 supports D0 D3 current D0 > cap 05[68] = MSI supports 1 message, 64 bit > cap 10[78] = PCI-Express 1 endpoint max data 128(128) link x8(x16) > speed 2.5(2.5) ASPM disabled(L0s/L1) > ecap 0002[100] = VC 1 max VC0 > ecap 0004[128] = Power Budgeting 1 > siis0@pci0:3:0:0: class=0x018000 card=0x819f1043 chip=0x31321095 rev=0x01 > hdr=0x00 > vendor = 'Silicon Image, Inc.' > device = 'SiI 3132 Serial ATA Raid II Controller' > class = mass storage > bar [10] = type Memory, range 64, base 0xefcff000, size 128, enabled > bar [18] = type Memory, range 64, base 0xefcf8000, size 16384, enabled > bar [20] = type I/O Port, range 32, base 0xbc00, size 128, enabled > cap 01[54] = powerspec 2 supports D0 D1 D2 D3 current D0 > cap 05[5c] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 1 legacy endpoint max data 256(1024) link > x1(x1) > speed 2.5(2.5) ASPM disabled(L0s) > ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected > ath0@pci0:4:0:0: class=0x028000 card=0x009a106b chip=0x0030168c rev=0x01 > hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR9300 Wireless LAN adaptor' > class = network > bar [10] = type Memory, range 64, base 0xefac0000, size 131072, > enabled > cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 > cap 05[50] = MSI supports 4 messages, 64 bit, vector masks > cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1) > speed 2.5(2.5) ASPM disabled(L0s/L1) > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected > ecap 0002[140] = VC 1 max VC0 > ecap 0003[300] = Serial 1 0000000000000000 > root@Border:~ # > > > > root@Border:~ # kenv | grep smbios > smbios.bios.reldate="04/28/2009" > smbios.bios.vendor="Phoenix Technologies, LTD" > smbios.bios.version="ASUS StrikerExtreme ACPI BIOS Revision 1901" > smbios.chassis.maker="Chassis Manufacture" > smbios.chassis.serial="EVAL " > smbios.chassis.tag="123456789000" > smbios.chassis.version="Chassis Version" > smbios.memory.enabled="8388608" > smbios.planar.maker="ASUSTeK Computer INC." > smbios.planar.product="StrikerExtreme" > smbios.planar.serial="123456789000" > smbios.planar.version="1.XX " > smbios.socket.enabled="1" > smbios.socket.populated="1" > smbios.system.maker="System manufacturer" > smbios.system.product="System Product Name" > smbios.system.serial="System Serial Number" > smbios.system.uuid="becbf4de-e6e7-53eb-eafa-1c0fc0145223" > smbios.system.version="System Version" > smbios.version="2.4" > root@Border:~ # > > > root@Border:~ # ifconfig > re0: flags=8843 metric 0 mtu 1500 > options=8209b > ether 00:14:d1:25:d8:23 > inet 99.55.241.27 netmask 0xfffffc00 broadcast 99.55.243.255 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > re1: flags=8843 metric 0 mtu 1500 > options=8209b > ether 00:14:d1:25:d8:44 > inet 192.168.12.1 netmask 0xffffff00 broadcast 192.168.12.255 > inet6 fe80::214:d1ff:fe25:d844%re1 prefixlen 64 scopeid 0x2 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > nfe0: flags=8802 metric 0 mtu 1500 > options=c219b > ether 00:1a:92:46:e0:44 > nd6 options=29 > media: Ethernet autoselect (none) > status: no carrier > nfe1: flags=8843 metric 0 mtu 1500 > options=c219b > ether 00:1a:92:46:ed:f7 > inet 75.133.75.194 netmask 0xfffffff8 broadcast 75.133.75.199 > inet6 fe80::21a:92ff:fe46:edf7%nfe1 prefixlen 64 scopeid 0x4 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > ath0: flags=8843 metric 0 mtu 2290 > ether 7c:c3:a1:b3:fc:af > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng > status: running > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > wlan0: flags=8843 metric 0 mtu 1500 > ether 7c:c3:a1:b3:fc:af > inet 192.168.13.1 netmask 0xffffff00 broadcast 192.168.13.255 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng > status: running > ssid BlackBox channel 6 (2437 MHz 11g ht/20) bssid 7c:c3:a1:b3:fc:af > regdomain 100 indoor ecm authmode OPEN privacy OFF txpower 20 > scanvalid 60 protmode RTSCTS ampdulimit 64k ampdudensity 8 shortgi wme > burst dtimperiod 15 -dfs bintval 1000 > pflog0: flags=141 metric 0 mtu 33152 > nd6 options=9 > root@Border:~ # > > > -- > > Sam Fourman Jr. > _______________________________________________ > 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 23 14:12:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CFAF51EE; Tue, 23 Jul 2013 14:12:41 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0870020A4; Tue, 23 Jul 2013 14:12:40 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u57so2603020wes.23 for ; Tue, 23 Jul 2013 07:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dduF5cMdYwD8RTvNHFiZAeM3BHV2hQ34ckMP4k7+OPg=; b=0wbqHVN5HC2Tgq3g4J3GEoN5nVkELSZ0PrM9Chak3jhfn9zivEQGnp3rhryeDCNyp9 uAO7vSseePKnCSMYmU6xArrQw0OPSlQbrDJFZJiFbpmTF2C+1mS7HkpWprgtmtJK7mGi VtT/kWsSMWor93jWUK10E1GncJII9M6IVXiztLpLkzOGA8OgC1a1mxLejAx7tds5OXeF J/BFP0hm90aAEMzDTGZgROUEsclQKr+lOzusKvLpadhSrkzozGNUTfOpECU0jDSWVjIf ca1rHZelf8L46xWHwQn+XFsaXmLFG+txt+rQvHK0YatwIhe2fuGdQ2wrQWkuXPGL5Q7O sGPA== MIME-Version: 1.0 X-Received: by 10.194.157.198 with SMTP id wo6mr23363282wjb.60.1374588759297; Tue, 23 Jul 2013 07:12:39 -0700 (PDT) Received: by 10.194.240.132 with HTTP; Tue, 23 Jul 2013 07:12:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jul 2013 18:12:39 +0400 Message-ID: Subject: Re: Not work ATH (AR9285) after update From: Andrey Fesenko To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 14:12:42 -0000 On Tue, Jul 23, 2013 at 5:13 PM, Adrian Chadd wrote: > .. are two copies of wpa_supplicant running? > > > > -adrian > > On 23 July 2013 06:09, Andrey Fesenko wrote: >> Hello, >> i'm horrible news, after update my notebook not nave wi-fi :( >> full update system, build and install world and kernel. >> >> # uname -a >> FreeBSD x220.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253562: Tue >> Jul 23 14:44:07 MSK 2013 >> root@x220.local:/usr/obj/usr/src/sys/W_BOOK amd64 >> >> # grep ATH /usr/src/sys/amd64/conf/W_BOOK >> options ATH_ENABLE_11N >> options ATH_DEBUG >> options ATH_DIAGAPI >> >> ath0@pci0:3:0:0: class=0x028000 card=0x1a891a3b chip=0x002b168c >> rev=0x01 hdr=0x00 >> vendor = 'Atheros Communications Inc.' >> device = 'AR9285 Wireless Network Adapter (PCI-Express)' >> class = network >> >> # ifconfig >> ath0: flags=8843 metric 0 mtu 2290 >> ether 00:25:d3:7b:94:87 >> nd6 options=21 >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >> status: associated >> wlan0: flags=8c43 >> metric 0 mtu 1500 >> ether 00:25:d3:7b:94:87 >> inet6 fe80::225:d3ff:fe7b:9487%wlan0 prefixlen 64 scopeid 0x4 >> nd6 options=23 >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >> status: no carrier >> ssid "" channel 8 (2447 MHz 11g) >> regdomain 33411 country RU indoor ecm authmode WPA1+WPA2/802.11i >> privacy MIXED deftxkey UNDEF txpower 20 bmiss 7 scanvalid 60 >> protmode CTS wme burst roaming MANUAL >> # ifconfig wlan0 list scan >> SSID/MESH ID BSSID CHAN RATE S:N INT CAPS >> APT-SPB2 b8:a3:86:4a:75:6a 6 54M -92:-96 100 EP HTCAP >> WPA RSN WME WPS >> THD1 74:ea:3a:d1:37:46 10 54M -85:-96 100 EP RSN HTCAP WME >> Balt1 00:90:4c:c1:00:00 1 54M -90:-96 100 EP RSN >> TP-LINK_904D2A 64:70:02:90:4d:2a 11 54M -94:-96 100 EPS RSN >> HTCAP WME ATH WPS >> >> /var/log/messages >> ... >> Jul 23 15:34:24 x220 wpa_supplicant[669]: wlan0: CTRL-EVENT-TERMINATING >> Jul 23 15:34:24 x220 kernel: wlan0: Ethernet address: 00:25:d3:7b:94:87 >> Jul 23 15:34:24 x220 devd: Executing '/etc/pccard_ether wlan0 start' >> Jul 23 15:34:24 x220 wpa_supplicant[2563]: Successfully initialized >> wpa_supplicant >> Jul 23 15:34:24 x220 wpa_supplicant[2571]: Successfully initialized >> wpa_supplicant >> Jul 23 15:34:24 x220 wpa_supplicant[2571]: ctrl_iface exists and seems >> to be in use - cannot override it >> Jul 23 15:34:24 x220 wpa_supplicant[2571]: Delete >> '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore >> Jul 23 15:34:24 x220 wpa_supplicant[2571]: Failed to initialize >> control interface '/var/run/wpa_supplicant'. You may have another >> wpa_supplicant process already running or the file was left by an >> unclean termination of wpa_supplicant in which case you will need to >> manually remove this file before starting wpa_supplicant again. >> Jul 23 15:34:24 x220 wpa_supplicant[2571]: ioctl[SIOCS80211, op=26, >> val=0, arg_len=0]: Operation not supported >> Jul 23 15:34:24 x220 wpa_supplicant[2571]: ioctl[SIOCS80211, op=26, >> val=0, arg_len=0]: Operation not supported >> Jul 23 15:34:24 x220 root: /etc/rc.d/wpa_supplicant: WARNING: failed >> to start wpa_supplicant >> Jul 23 15:34:24 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, >> val=0, arg_len=128]: Operation now in progress >> Jul 23 15:34:24 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan >> Jul 23 15:34:25 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, >> val=0, arg_len=128]: Operation now in progress >> Jul 23 15:34:25 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan >> Jul 23 15:34:26 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, >> val=0, arg_len=128]: Operation now in progress >> Jul 23 15:34:26 x220 kernel: ath0: ath_reset_grablock: didn't finish >> after 10 iterations >> Jul 23 15:34:26 x220 kernel: ath0: ath_reset_grablock: warning, >> recursive reset path! >> Jul 23 15:34:26 x220 kernel: ath0: ath_reset: concurrent reset! Danger! >> Jul 23 15:34:26 x220 kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing >> Jul 23 15:34:26 x220 kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing >> Jul 23 15:34:26 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan >> Jul 23 15:34:27 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, >> val=0, arg_len=128]: Operation now in progress >> Jul 23 15:34:27 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan >> Jul 23 15:34:29 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, >> val=0, arg_len=128]: Operation now in progress >> Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: didn't finish >> after 10 iterations >> Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: warning, >> recursive reset path! Not, root@x220:~ # ps -A | grep wpa 671 - Ss 0:00.73 /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_suppl Start, or restart work standart # /etc/rc.d/netif restart this scheme work fine ~year or half year. Although of course the chip AR9285 is not very stable, especially in combination with some AP. Hm... intresting boot messages ... Jul 23 17:47:06 x220 kernel: ath0: mem 0xf2400000-0xf240ffff irq 17 at device 0.0 on pci3 Jul 23 17:47:06 x220 kernel: [ath] AR9285 Main LNA config: LNA1 Jul 23 17:47:06 x220 kernel: [ath] AR9285 Alt LNA config: LNA2 Jul 23 17:47:06 x220 kernel: [ath] LNA diversity disabled, Diversity disabled Jul 23 17:47:06 x220 kernel: ath0: [HT] enabling HT modes Jul 23 17:47:06 x220 kernel: ath0: [HT] 1 stream STBC receive enabled Jul 23 17:47:06 x220 kernel: ath0: [HT] 1 RX streams; 1 TX streams Jul 23 17:47:06 x220 kernel: ath0: AR9285 mac 192.2 RF5133 phy 14.0 Jul 23 17:47:06 x220 kernel: ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 old log Jul 2 13:30:02 x220 kernel: ath0: mem 0xf2400000-0xf240ffff irq 17 at device 0.0 on pci3 Jul 2 13:30:02 x220 kernel: ath0: [HT] enabling HT modes Jul 2 13:30:02 x220 kernel: ath0: [HT] 1 stream STBC receive enabled Jul 2 13:30:02 x220 kernel: ath0: [HT] 1 RX streams; 1 TX streams Jul 2 13:30:02 x220 kernel: ath0: AR9285 mac 192.2 RF5133 phy 14.0 Jul 2 13:30:02 x220 kernel: ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 and old style reconnect Jul 2 14:15:33 x220 wpa_supplicant[516]: CTRL-EVENT-DISCONNECTED bssid=58:6d:8f:fa:d9:50 reason=0 Jul 2 14:15:33 x220 kernel: wlan0: link state changed to DOWN Jul 2 14:15:35 x220 wpa_supplicant[516]: Trying to associate with 58:6d:8f:fa:d9:50 (SSID='hometest' freq=2472 MHz) Jul 2 14:15:35 x220 wpa_supplicant[516]: Associated with 58:6d:8f:fa:d9:50 Jul 2 14:15:35 x220 kernel: wlan0: link state changed to UP Jul 2 14:15:35 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0 Jul 2 14:15:35 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 Jul 2 14:15:35 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0 Jul 2 14:15:35 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 Jul 2 14:15:35 x220 wpa_supplicant[516]: WPA: Key negotiation completed with 58:6d:8f:fa:d9:50 [PTK=CCMP GTK=CCMP] Jul 2 14:15:35 x220 wpa_supplicant[516]: CTRL-EVENT-CONNECTED - Connection to 58:6d:8f:fa:d9:50 completed (reauth) [id=0 id_str=] Jul 2 14:15:35 x220 dhclient: New IP Address (wlan0): 192.168.1.22 Jul 2 14:15:35 x220 dhclient: New Subnet Mask (wlan0): 255.255.255.0 Jul 2 14:15:35 x220 dhclient: New Broadcast Address (wlan0): 192.168.1.255 Jul 2 14:15:35 x220 dhclient: New Routers (wlan0): 192.168.1.1 Jul 2 14:19:57 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0 Jul 2 14:19:57 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 Jul 2 14:20:00 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0 Jul 2 14:20:00 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 Jul 2 14:22:21 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0 Jul 2 14:22:21 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 Jul 2 15:10:13 x220 wpa_supplicant[516]: WPA: Group rekeying completed with 58:6d:8f:fa:d9:50 [GTK=CCMP] Jul 2 15:10:13 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0 Jul 2 15:10:13 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 Jul 2 15:12:00 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0 Jul 2 15:12:00 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 Jul 2 15:12:13 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0 Jul 2 15:12:13 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 14:21:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA2ED58D; Tue, 23 Jul 2013 14:21:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2991B2118; Tue, 23 Jul 2013 14:21:43 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id m46so453730wev.22 for ; Tue, 23 Jul 2013 07:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IrqzR4Hn1j0cXZUrZjUH2RLmxZbebBJ31ZLUI3DHa4w=; b=I3fHHmfL62wO1hiang6TVPdda10a/PWl9bJaLWnKsjp4VKJ2I89ydsAaljQVeAaFqq MWRxLiESH5MlMwEWk3g/6ZOiofyPRtEb9oHNmhvFPHtcthDcayITpUzf4DMeo96FZW6q jmBIApZlpkWDqvwVTnL4qlukQs3L5M97PwSVcwMHvEVEUyAfqsbTmFJnEBcaB7GgIiiV 8XKVWta/aDQsk3s3aQyCGhKl8pCIglCVqn6rfquG1EbC9X4zglqNE76iwpcE68MsXTus FIelwgmPQsBNkm/bVcFUl4kaARTWj9d89VqN+Q12GhC/8rTGvdjHdFnyuSm3U+nDlcNw J/YQ== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr22208598wik.30.1374589300553; Tue, 23 Jul 2013 07:21:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Tue, 23 Jul 2013 07:21:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jul 2013 07:21:40 -0700 X-Google-Sender-Auth: ICtTKvSsYywZFD68tqFLdVCOaeg Message-ID: Subject: Re: Not work ATH (AR9285) after update From: Adrian Chadd To: Andrey Fesenko Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 14:21:44 -0000 Ok, so. On 23 July 2013 07:12, Andrey Fesenko wrote: >>> i'm horrible news, after update my notebook not nave wi-fi :( >>> full update system, build and install world and kernel. What did it used to run? >>> Jul 23 15:34:27 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan >>> Jul 23 15:34:29 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, >>> val=0, arg_len=128]: Operation now in progress >>> Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: didn't finish >>> after 10 iterations >>> Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: warning, >>> recursive reset path! Your previous log indicated multiple copies of wpa_supplicant. That should be investigated. > Not, > root@x220:~ # ps -A | grep wpa > 671 - Ss 0:00.73 /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_suppl > > Start, or restart work standart > # /etc/rc.d/netif restart > this scheme work fine ~year or half year. > Although of course the chip AR9285 is not very stable, especially in > combination with some AP. That's why I updated the support. It's much more stable now. Except if you somehow get >1 wpa_supplicant instances running. > > Hm... intresting boot messages > ... > Jul 23 17:47:06 x220 kernel: ath0: mem > 0xf2400000-0xf240ffff irq 17 at device 0.0 on pci3 > Jul 23 17:47:06 x220 kernel: [ath] AR9285 Main LNA config: LNA1 > Jul 23 17:47:06 x220 kernel: [ath] AR9285 Alt LNA config: LNA2 > Jul 23 17:47:06 x220 kernel: [ath] LNA diversity disabled, Diversity disabled > Jul 23 17:47:06 x220 kernel: ath0: [HT] enabling HT modes > Jul 23 17:47:06 x220 kernel: ath0: [HT] 1 stream STBC receive enabled > Jul 23 17:47:06 x220 kernel: ath0: [HT] 1 RX streams; 1 TX streams > Jul 23 17:47:06 x220 kernel: ath0: AR9285 mac 192.2 RF5133 phy 14.0 > Jul 23 17:47:06 x220 kernel: ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 x220 - is this a thinkpad? Or what kind of laptop is it? Have you added this card in yourself? Are both antennas connected? The EEPROM settings disable diversity. Thus, the transmit path is always LNA1, the receive path is always LNA1. So, it should at least have that antenna connected. > old log > Jul 2 13:30:02 x220 kernel: ath0: mem > 0xf2400000-0xf240ffff irq 17 at device 0.0 on pci3 > Jul 2 13:30:02 x220 kernel: ath0: [HT] enabling HT modes > Jul 2 13:30:02 x220 kernel: ath0: [HT] 1 stream STBC receive enabled > Jul 2 13:30:02 x220 kernel: ath0: [HT] 1 RX streams; 1 TX streams > Jul 2 13:30:02 x220 kernel: ath0: AR9285 mac 192.2 RF5133 phy 14.0 > Jul 2 13:30:02 x220 kernel: ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 What's the svn revision on that? > and old style reconnect > Jul 2 14:15:33 x220 wpa_supplicant[516]: CTRL-EVENT-DISCONNECTED > bssid=58:6d:8f:fa:d9:50 reason=0 > Jul 2 14:15:33 x220 kernel: wlan0: link state changed to DOWN > Jul 2 14:15:35 x220 wpa_supplicant[516]: Trying to associate with > 58:6d:8f:fa:d9:50 (SSID='hometest' freq=2472 MHz) > Jul 2 14:15:35 x220 wpa_supplicant[516]: Associated with 58:6d:8f:fa:d9:50 > Jul 2 14:15:35 x220 kernel: wlan0: link state changed to UP > Jul 2 14:15:35 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 > ts_finaltsi=0 > Jul 2 14:15:35 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 > ts_status 0x0 > Jul 2 14:15:35 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 > ts_finaltsi=0 > Jul 2 14:15:35 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 > ts_status 0x0 > Jul 2 14:15:35 x220 wpa_supplicant[516]: WPA: Key negotiation > completed with 58:6d:8f:fa:d9:50 [PTK=CCMP GTK=CCMP] > Jul 2 14:15:35 x220 wpa_supplicant[516]: CTRL-EVENT-CONNECTED - > Connection to 58:6d:8f:fa:d9:50 completed (reauth) [id=0 id_str=] > Jul 2 14:15:35 x220 dhclient: New IP Address (wlan0): 192.168.1.22 > Jul 2 14:15:35 x220 dhclient: New Subnet Mask (wlan0): 255.255.255.0 > Jul 2 14:15:35 x220 dhclient: New Broadcast Address (wlan0): 192.168.1.255 > Jul 2 14:15:35 x220 dhclient: New Routers (wlan0): 192.168.1.1 > Jul 2 14:19:57 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 > ts_finaltsi=0 > Jul 2 14:19:57 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 > ts_status 0x0 > Jul 2 14:20:00 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 > ts_finaltsi=0 > Jul 2 14:20:00 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 > ts_status 0x0 > Jul 2 14:22:21 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 > ts_finaltsi=0 > Jul 2 14:22:21 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 > ts_status 0x0 > Jul 2 15:10:13 x220 wpa_supplicant[516]: WPA: Group rekeying > completed with 58:6d:8f:fa:d9:50 [GTK=CCMP] > Jul 2 15:10:13 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 > ts_finaltsi=0 > Jul 2 15:10:13 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 > ts_status 0x0 > Jul 2 15:12:00 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 > ts_finaltsi=0 > Jul 2 15:12:00 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 > ts_status 0x0 > Jul 2 15:12:13 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 > ts_finaltsi=0 > Jul 2 15:12:13 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 > ts_status 0x0 These are likely because your AP disables the low CCK rates, but the rate control code currently tries to transmit on them. It succeeds in transmitting, but then it gets angry because that rate isn't in said rate table negotiated with the AP. Please try it manually: # ifconfig wlan0 destroy # pkill -9 wpa_supplicant # ifconfig wlan0 create wlandev ath0 # wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf & .. and see what happens. Thanks, -adrian From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 15:12:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D03B352C for ; Tue, 23 Jul 2013 15:12:35 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A2B06236F for ; Tue, 23 Jul 2013 15:12:35 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id n10so11681769oag.28 for ; Tue, 23 Jul 2013 08:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Yc7/x+k2aItg387OUjJPcHeCLLOGXUcCzeqELwZVn5U=; b=JGzDoidI3HepMNC6W7V40DxX7U714jlLq6sv34a6kIDsvYUNCu6mPzQ8mDpG5vemcV RHFn+LZtn5MYZXWil+siqPAGAEJXW9jpiOhrytpmEbsfOAkkyK1ClomnyNdAPMN+V1YT 3/Y0L7yewVqtxdEVhvRiBHGy0UCwoBegDNdBlazU6AS240fpF6dB5aJpjvdnuHJPKVVb T4lL/OhCle1a0WJ3pQCiHuS1kl7NawVw6P+lL+FN5sqK6NIpsWp3+XzfpxhlSnzWbmQV vK8HlcxgUNMJRLQN6ZMV2SFVg2cMQADJ4cTK1bDlkN7HPbMiekKu8iEvoxuqgMrYYVDF HXTw== X-Received: by 10.60.95.198 with SMTP id dm6mr31275774oeb.44.1374592354914; Tue, 23 Jul 2013 08:12:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.130.204 with HTTP; Tue, 23 Jul 2013 08:12:04 -0700 (PDT) From: Jia-Shiun Li Date: Tue, 23 Jul 2013 23:12:04 +0800 Message-ID: Subject: Panic at USB drive plugging in To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 15:12:35 -0000 Hi all, as personal preference I compiled kernel with drivers as module as possible. Recently I found that plugging in USB drives causes kernel to panic. But it does not happen when booting with GENERIC kernel which has USB drivers compiled in. panic screenshot: http://goo.gl/pIIDaF back trace: http://goo.gl/ww4yy6 the kernel is compiled: FreeBSD 4cbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r253395: Fri Jul 19 15:20:08 CST 2013 jsli@4cbsd:/usr/obj/usr/src/sys/Minimal amd64 the back trace looks like devd and something had timing issues. Any ideas? Regards, Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 16:05:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8C245C3D; Tue, 23 Jul 2013 16:05:45 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9A82702; Tue, 23 Jul 2013 16:05:44 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 4DD897A074; Tue, 23 Jul 2013 18:05:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 297A18EFB23; Tue, 23 Jul 2013 18:05:48 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siGHw9cZO8M2; Tue, 23 Jul 2013 18:05:47 +0200 (CEST) Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 6D7FB8EFB22; Tue, 23 Jul 2013 18:05:47 +0200 (CEST) Message-ID: <51EEAA36.6030206@bitfrost.no> Date: Tue, 23 Jul 2013 18:07:18 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jia-Shiun Li Subject: Re: Panic at USB drive plugging in References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 16:05:45 -0000 On 07/23/13 17:12, Jia-Shiun Li wrote: > Hi all, > > as personal preference I compiled kernel with drivers as module as > possible. Recently I found that plugging in USB drives causes kernel > to panic. But it does not happen when booting with GENERIC kernel > which has USB drivers compiled in. > > panic screenshot: > http://goo.gl/pIIDaF > > back trace: > http://goo.gl/ww4yy6 > > the kernel is compiled: > FreeBSD 4cbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r253395: Fri Jul 19 > 15:20:08 CST 2013 jsli@4cbsd:/usr/obj/usr/src/sys/Minimal amd64 > > the back trace looks like devd and something had timing issues. Any ideas? > Hi, This looks like a CAM/SCSI problem and not directly USB stack problem. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 16:13:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1FB712C7 for ; Tue, 23 Jul 2013 16:13:29 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A65D4279C for ; Tue, 23 Jul 2013 16:13:28 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id jf3so45991bkc.35 for ; Tue, 23 Jul 2013 09:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=z0BZBqWs790ijYSx08VofdFr185HssMUoNKZQFd18kg=; b=amSHMAWUNqHE2iU+P2dNdrlaTpNVrxVeGf2ys7rj6qQaU8Tf6eHd8KLDam2RP9J+l3 UhCytHrbEmnUMkfBcTNSSHfPuSH4KMCG4WgEWZBmTyQ17xqtxzCQAuz6AlcKVtOBj8OY ZsNGn1JWUzkgLiHutBSPzHvubea1a355FRhde2JgPI16Fk14EmFSogJCBgzqAyaMnZt3 87qhwJ8rLZ324wiEcgZHc5IOA1ysKDcisJb1NZn6QdZj1ZDtatmvVID5WUSDa9l5Fa27 aIWQGiuTRFWjebNDrrKH/ukQZFY9kO+xqYJwDrXET2CJCw+Kr3pjB9nDjeQFDLXALZZq xAdA== X-Received: by 10.205.19.135 with SMTP id qk7mr4697577bkb.139.1374596006797; Tue, 23 Jul 2013 09:13:26 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPSA id ps10sm8543353bkb.14.2013.07.23.09.13.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 09:13:25 -0700 (PDT) Sender: Alexander Motin Message-ID: <51EEABA3.7060909@FreeBSD.org> Date: Tue, 23 Jul 2013 19:13:23 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: Panic at USB drive plugging in References: <51EEAA36.6030206@bitfrost.no> In-Reply-To: <51EEAA36.6030206@bitfrost.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jia-Shiun Li X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 16:13:29 -0000 On 23.07.2013 19:07, Hans Petter Selasky wrote: > On 07/23/13 17:12, Jia-Shiun Li wrote: >> Hi all, >> >> as personal preference I compiled kernel with drivers as module as >> possible. Recently I found that plugging in USB drives causes kernel >> to panic. But it does not happen when booting with GENERIC kernel >> which has USB drivers compiled in. >> >> panic screenshot: >> http://goo.gl/pIIDaF >> >> back trace: >> http://goo.gl/ww4yy6 >> >> the kernel is compiled: >> FreeBSD 4cbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r253395: Fri Jul 19 >> 15:20:08 CST 2013 jsli@4cbsd:/usr/obj/usr/src/sys/Minimal amd64 >> >> the back trace looks like devd and something had timing issues. Any >> ideas? >> > This looks like a CAM/SCSI problem and not directly USB stack problem. It seems crashed inside the CAM sg driver, that is not part of GENERIC kernel. Are you using it is some way? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 17:54:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DA7742A5 for ; Tue, 23 Jul 2013 17:54:40 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A0D42C05 for ; Tue, 23 Jul 2013 17:54:40 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id r6NHsVrC028151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Jul 2013 19:54:31 +0200 Received: from [192.168.1.110] (174.Red-79-153-75.dynamicIP.rima-tde.net [79.153.75.174]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id r6NHsTgu005295 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 19:54:30 +0200 Message-ID: <51EEC355.3010300@entel.upc.edu> Date: Tue, 23 Jul 2013 19:54:29 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 MIME-Version: 1.0 To: Neel Natu Subject: Re: Panic when starting X with Intel KMS References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> <20130721071842.GZ5991@kib.kiev.ua> <51EBAA76.8020100@entel.upc.edu> <20130721185145.GE5991@kib.kiev.ua> <51EC43BA.1000800@entel.upc.edu> <51ED0CEC.80307@entel.upc.edu> <20130722111940.GK5991@kib.kiev.ua> <51ED8A4F.8050506@entel.upc.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Tue, 23 Jul 2013 19:54:31 +0200 (CEST) Cc: Konstantin Belousov , FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 17:54:40 -0000 Al 22/07/2013 23:27, En/na Neel Natu ha escrit: > > Could you apply the following patch to amd64/amd64/pmap.c and see if > it fixes the problem: > > http://people.freebsd.org/~neel/patches/pmap_remove_pages.patch > Neel came with another patch: http://people.freebsd.org/~neel/patches/pmap_remove_pages.patch I've playing with it an the system seemed stable. Neel will commit that patch soon. Gus -- Salut i força, Gustau --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 18:29:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 23EA9C2A; Tue, 23 Jul 2013 18:29:10 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB8542D9F; Tue, 23 Jul 2013 18:29:09 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id ef5so11056323obb.29 for ; Tue, 23 Jul 2013 11:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nSD3N5IsPhHFSf9f5ZqMgQVCOUxKetmEQLpOxLkpclw=; b=IvcHTLZfQ5jud2R4E6mLyki7s6zOgh1Sq8bf74LhzStBo61HVPCIaBpk20D5SMk0/P 3Cx8EgBAaqwunOawuJvVhlE6m2ZvVM5Ud7LNKUVayNNb7quJJcDNxwhvenLFrC5Hn8Fj 9l9QULjnpNtTVePyG/yGDyzSXFW8I8cTIL+rcZQv2pw3ea7raOtWlmlq8dhxx0s8uke1 pHT3iODFjqSe7/bDAl39KrREt3My59GHc9ukKYK6H4vXckQNpym6hDrJ3zRcPSYqVFI4 xl2fjBmX/7R+gXvnyPHoBKv/aM+RhBkeRKFXvqCBWXcIplJyr8suVNlMzNdsVgddSRUp udqA== X-Received: by 10.182.39.168 with SMTP id q8mr26378052obk.72.1374604149075; Tue, 23 Jul 2013 11:29:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.130.204 with HTTP; Tue, 23 Jul 2013 11:28:39 -0700 (PDT) In-Reply-To: <51EEABA3.7060909@FreeBSD.org> References: <51EEAA36.6030206@bitfrost.no> <51EEABA3.7060909@FreeBSD.org> From: Jia-Shiun Li Date: Wed, 24 Jul 2013 02:28:39 +0800 Message-ID: Subject: Re: Panic at USB drive plugging in To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 18:29:10 -0000 On Wed, Jul 24, 2013 at 12:13 AM, Alexander Motin wrote: > On 23.07.2013 19:07, Hans Petter Selasky wrote: >> This looks like a CAM/SCSI problem and not directly USB stack problem. > > It seems crashed inside the CAM sg driver, that is not part of GENERIC > kernel. Are you using it is some way? > No. I do not use it at all. kernel conf & loader.conf: ---8<---------------------------------------------- # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: head/sys/amd64/conf/GENERIC 252867 2013-07-06 07:49:41Z delphij $ cpu HAMMER ident Minimal options MSGBUF_SIZE=327680 makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options TCP_OFFLOAD # TCP offload options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options QUOTA # Enable disk quotas for UFS options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD # New Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_RAID # Soft RAID functionality. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options CAPABILITY_MODE # Capsicum capability mode options CAPABILITIES # Capsicum capabilities options MAC # TrustedBSD MAC Framework options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF # Kernel ELF linker loads CTF data options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging support. Always need this: options KDB # Enable kernel debugger support. # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a panic. # For full debugger support use this instead: options DDB # Support DDB. options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver options VESA # Add support for VESA BIOS Extensions (VBE) device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # add support for the raster text mode options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors options AH_AR5416_INTERRUPT_MITIGATION # AR5416 interrupt mitigation options ATH_ENABLE_11N # Enable 802.11n support for AR5416 and later # Pseudo devices. device loop # Network loopback device random # Entropy device options PADLOCK_RNG # VIA Padlock RNG options RDRAND_RNG # Intel Bull Mountain RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter ---8<---------------------------------------------- boot_verbose="YES" vfs.root.mountfrom="ufs:/dev/ufsid/512bf4dea8214917" kernel="Minimal" atapci_load="YES" ataahci_load="YES" if_em_load="YES" snd_es137x_load="YES" uhci_load="YES" ehci_load="YES" mpt_load="YES" vesa_load="YES" ichsmb_load="YES" snd_hda_load="YES" xhci_load="YES" if_re_load="YES" # Power management hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 hint.ahcich.0.pm_level=3 hint.ahcich.1.pm_level=3 hint.ahcich.2.pm_level=3 hint.ahcich.3.pm_level=3 hint.ahcich.4.pm_level=3 hint.ahcich.5.pm_level=3 drm.i915.enable_rc6=7 hw.pci.do_power_nodriver=3 hw.snd.latency=7 Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 19:17:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4BC6E78; Tue, 23 Jul 2013 19:17:00 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A9FE201C; Tue, 23 Jul 2013 19:16:59 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y10so3825263wgg.2 for ; Tue, 23 Jul 2013 12:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=MjZVE4qE8jFbTwlcidm5BEaN2Pjc680Uiolwq0JKgKo=; b=bZ5ydVft8/RAMdKlxF6neAVVjtLHBIdJn7wPrzICZygC8JE3sdGaSm/Fm5L+uhJIUJ CtYgbOeRPYPaxZqLmnOC0jZQ2t0UDeNIkkjLKL1PeWvXIu0dIlIWHaMSJAQH8GuALEvD hkLv/N0fGoNqge7NLg9L2xkkmL3IKyJjj5ll56cH/2+O48pIpMp5l9ZCglPA7csL4tJB 3hgxgdQHyqliiyERawl712d25chUcJsC2la09D7F1benVRy5506ep/+TDoQ4Qopd3TYw GeLBS6LnN7AWPv58Hq0rRPTSMwr0Pav50XSw/5fLTesDzmQ+yUY/eb9pMPCG39rbXOLN q/Ew== MIME-Version: 1.0 X-Received: by 10.194.234.100 with SMTP id ud4mr24132682wjc.44.1374607017834; Tue, 23 Jul 2013 12:16:57 -0700 (PDT) Received: by 10.194.240.132 with HTTP; Tue, 23 Jul 2013 12:16:57 -0700 (PDT) Date: Tue, 23 Jul 2013 23:16:57 +0400 Message-ID: Subject: Re: Not work ATH (AR9285) after update [SOLVED] From: Andrey Fesenko To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 19:17:00 -0000 On Tue, Jul 23, 2013 at 6:21 PM, Adrian Chadd wrote: > Ok, so. > > On 23 July 2013 07:12, Andrey Fesenko wrote: > >>>> i'm horrible news, after update my notebook not nave wi-fi :( >>>> full update system, build and install world and kernel. > > What did it used to run? > > # grep wlan0 /etc/rc.conf wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" ifconfig_wlan0_ipv6="inet6 accept_rtadv" >>>> Jul 23 15:34:27 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan >>>> Jul 23 15:34:29 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103, >>>> val=0, arg_len=128]: Operation now in progress >>>> Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: didn't finish >>>> after 10 iterations >>>> Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: warning, >>>> recursive reset path! > > Your previous log indicated multiple copies of wpa_supplicant. That > should be investigated. > >> Not, >> root@x220:~ # ps -A | grep wpa >> 671 - Ss 0:00.73 /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_suppl >> >> Start, or restart work standart >> # /etc/rc.d/netif restart >> this scheme work fine ~year or half year. >> Although of course the chip AR9285 is not very stable, especially in >> combination with some AP. > > That's why I updated the support. It's much more stable now. Except if > you somehow get >1 wpa_supplicant instances running. > >> >> Hm... intresting boot messages >> ... >> Jul 23 17:47:06 x220 kernel: ath0: mem >> 0xf2400000-0xf240ffff irq 17 at device 0.0 on pci3 >> Jul 23 17:47:06 x220 kernel: [ath] AR9285 Main LNA config: LNA1 >> Jul 23 17:47:06 x220 kernel: [ath] AR9285 Alt LNA config: LNA2 >> Jul 23 17:47:06 x220 kernel: [ath] LNA diversity disabled, Diversity disabled >> Jul 23 17:47:06 x220 kernel: ath0: [HT] enabling HT modes >> Jul 23 17:47:06 x220 kernel: ath0: [HT] 1 stream STBC receive enabled >> Jul 23 17:47:06 x220 kernel: ath0: [HT] 1 RX streams; 1 TX streams >> Jul 23 17:47:06 x220 kernel: ath0: AR9285 mac 192.2 RF5133 phy 14.0 >> Jul 23 17:47:06 x220 kernel: ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > > x220 - is this a thinkpad? Or what kind of laptop is it? > > Have you added this card in yourself? Are both antennas connected? > > The EEPROM settings disable diversity. Thus, the transmit path is > always LNA1, the receive path is always LNA1. So, it should at least > have that antenna connected. > Yes it's thinkpad X220 :) :( hacked BIOS for remove wite list, yes antenna connected card installed near yea ago and all this time working for startup on the rc.conf >> old log >> Jul 2 13:30:02 x220 kernel: ath0: mem >> 0xf2400000-0xf240ffff irq 17 at device 0.0 on pci3 >> Jul 2 13:30:02 x220 kernel: ath0: [HT] enabling HT modes >> Jul 2 13:30:02 x220 kernel: ath0: [HT] 1 stream STBC receive enabled >> Jul 2 13:30:02 x220 kernel: ath0: [HT] 1 RX streams; 1 TX streams >> Jul 2 13:30:02 x220 kernel: ath0: AR9285 mac 192.2 RF5133 phy 14.0 >> Jul 2 13:30:02 x220 kernel: ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > > What's the svn revision on that? > FreeBSD 10.0-CURRENT #0 r249991 >> and old style reconnect >> Jul 2 14:15:33 x220 wpa_supplicant[516]: CTRL-EVENT-DISCONNECTED >> bssid=58:6d:8f:fa:d9:50 reason=0 >> Jul 2 14:15:33 x220 kernel: wlan0: link state changed to DOWN >> Jul 2 14:15:35 x220 wpa_supplicant[516]: Trying to associate with >> 58:6d:8f:fa:d9:50 (SSID='hometest' freq=2472 MHz) >> Jul 2 14:15:35 x220 wpa_supplicant[516]: Associated with 58:6d:8f:fa:d9:50 >> Jul 2 14:15:35 x220 kernel: wlan0: link state changed to UP >> Jul 2 14:15:35 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 >> ts_finaltsi=0 >> Jul 2 14:15:35 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 >> ts_status 0x0 >> Jul 2 14:15:35 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 >> ts_finaltsi=0 >> Jul 2 14:15:35 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 >> ts_status 0x0 >> Jul 2 14:15:35 x220 wpa_supplicant[516]: WPA: Key negotiation >> completed with 58:6d:8f:fa:d9:50 [PTK=CCMP GTK=CCMP] >> Jul 2 14:15:35 x220 wpa_supplicant[516]: CTRL-EVENT-CONNECTED - >> Connection to 58:6d:8f:fa:d9:50 completed (reauth) [id=0 id_str=] >> Jul 2 14:15:35 x220 dhclient: New IP Address (wlan0): 192.168.1.22 >> Jul 2 14:15:35 x220 dhclient: New Subnet Mask (wlan0): 255.255.255.0 >> Jul 2 14:15:35 x220 dhclient: New Broadcast Address (wlan0): 192.168.1.255 >> Jul 2 14:15:35 x220 dhclient: New Routers (wlan0): 192.168.1.1 >> Jul 2 14:19:57 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 >> ts_finaltsi=0 >> Jul 2 14:19:57 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 >> ts_status 0x0 >> Jul 2 14:20:00 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 >> ts_finaltsi=0 >> Jul 2 14:20:00 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 >> ts_status 0x0 >> Jul 2 14:22:21 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 >> ts_finaltsi=0 >> Jul 2 14:22:21 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 >> ts_status 0x0 >> Jul 2 15:10:13 x220 wpa_supplicant[516]: WPA: Group rekeying >> completed with 58:6d:8f:fa:d9:50 [GTK=CCMP] >> Jul 2 15:10:13 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 >> ts_finaltsi=0 >> Jul 2 15:10:13 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 >> ts_status 0x0 >> Jul 2 15:12:00 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 >> ts_finaltsi=0 >> Jul 2 15:12:00 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 >> ts_status 0x0 >> Jul 2 15:12:13 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 >> ts_finaltsi=0 >> Jul 2 15:12:13 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 >> ts_status 0x0 > > These are likely because your AP disables the low CCK rates, but the > rate control code currently tries to transmit on them. It succeeds in > transmitting, but then it gets angry because that rate isn't in said > rate table negotiated with the AP. > > Please try it manually: > > # ifconfig wlan0 destroy > # pkill -9 wpa_supplicant > # ifconfig wlan0 create wlandev ath0 > # wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf & > > .. and see what happens. > Hm... manual start OK # ifconfig wlan0 destroy ifconfig: interface wlan0 does not exist # pkill -9 wpa_supplicant # ifconfig wlan0 create wlandev ath0 # wpa_supplicant -d -i wlan0 -c /etc/wpa_supplicant.conf wpa_supplicant v2.0 Successfully initialized wpa_supplicant Initializing interface 'wlan0' conf '/etc/wpa_supplicant.conf' driver 'default' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' full debug log http://pastebin.com/ie599AvH EUREKA changes in the IPv6 with out IPv6 starts /etc/rc.d/netif restar log Jul 23 23:09:34 x220 root: /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant Jul 23 23:09:36 x220 wpa_supplicant[8465]: wlan0: Trying to associate with 58:6d:8f:fa:d9:50 (SSID='hometest' freq=2472 MHz) Jul 23 23:09:36 x220 kernel: wlan0: link state changed to UP Jul 23 23:09:36 x220 wpa_supplicant[8465]: wlan0: Associated with 58:6d:8f:fa:d9:50 Jul 23 23:09:36 x220 devd: Executing '/etc/rc.d/dhclient quietstart wlan0' Jul 23 23:09:36 x220 wpa_supplicant[8465]: wlan0: WPA: Key negotiation completed with 58:6d:8f:fa:d9:50 [PTK=CCMP GTK=CCMP] Jul 23 23:09:36 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0 Jul 23 23:09:36 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 Jul 23 23:09:36 x220 wpa_supplicant[8465]: wlan0: CTRL-EVENT-CONNECTED - Connection to 58:6d:8f:fa:d9:50 completed [id=0 id_str=] Jul 23 23:09:36 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0 Jul 23 23:09:36 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 Jul 23 23:09:36 x220 dhclient: New IP Address (wlan0): 192.168.1.23 Jul 23 23:09:36 x220 dhclient: New Subnet Mask (wlan0): 255.255.255.0 Jul 23 23:09:36 x220 dhclient: New Broadcast Address (wlan0): 192.168.1.255 Jul 23 23:09:36 x220 dhclient: New Routers (wlan0): 192.168.1.1 Jul 23 23:10:20 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27 ts_finaltsi=0 Jul 23 23:10:20 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1 ts_status 0x0 Thank, Adrian!!! :) From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 19:49:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 04943A35; Tue, 23 Jul 2013 19:49:55 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BD06221B1; Tue, 23 Jul 2013 19:49:54 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n12so7521275oag.22 for ; Tue, 23 Jul 2013 12:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=g8zjAyPN6O1GpCU/tADv0BnyV4Pzrawo3KVIX/kvx4o=; b=KqWy3SQcZ+W7yJdSOhPLMjbBgu0R62ccQsEeCBr5PWUHQ0/WjdlZcEK7KOLKFjURze 5IqjaZ3YgEUMXqdR7r/yQ+5zGK1TMBVluZcMjdHMq9sLwl/0EqAWkymjsyi14/iqeSMP IRVlpAlhqwugsaLBwNh2VcYB1HbVJqkoVXS9Cs/dWSqaww/Z1ICI0y6JWFbfUIQqXtmf OBJmQVh3o2cNdHTzMUq7qTj9uIh7GRdhVx1jUijSx5zLlXwHgAhzJ8J+UppXSgF0c4n2 pmyP3mmGNkL6cyiZZVmGWKVBZz7wxM5Gb7VqY3aaTCmNUrNH0jZ8aevcav05lbyy697k 20kA== MIME-Version: 1.0 X-Received: by 10.182.79.201 with SMTP id l9mr4051974obx.61.1374608993910; Tue, 23 Jul 2013 12:49:53 -0700 (PDT) Received: by 10.182.115.194 with HTTP; Tue, 23 Jul 2013 12:49:53 -0700 (PDT) Date: Tue, 23 Jul 2013 15:49:53 -0400 Message-ID: Subject: Increasing the kernel hertz rate in 10.0, RELEASE, and CURRENT From: Super Bisquit To: FreeBSD Hackers , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 19:49:55 -0000 At 2500 Hz, the tick rate increases by 1 Hz per cycle. There was mention of a patch that would allow the rate to be as high as 40k without this effect. --I'll post the link as soon as I find the mailing list thread-- Will this patch work with the current available releases? From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 20:02:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81EABE7F for ; Tue, 23 Jul 2013 20:02:42 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 079A2224A for ; Tue, 23 Jul 2013 20:02:41 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id jf3so131931bkc.21 for ; Tue, 23 Jul 2013 13:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DU02DlOGPzLm2MWUJUTDqFopE3GVRorHkUm/WjXQITs=; b=AXVi549aUhZE1NMvCTIDEky+ugNKUl+F58jmIbwrxkYCQpuNchQKAT3pmIGYlk5whF HhHII2/bBwIBrpFm4vJyUMGy1AAbjidXFNhsbecR2Gg/yLpno0xMgAp88GpHZ5acXMNm eM9AWBctrNG+WDyPErJD5BDTnhJxA5bq7FaXYdvKWBUWD8FV+S7MfXrKXTsECMi1dMi2 fQv+vzHXJZZNHRP9CEs1jyhkCdtZ70BpQDLwpCSLWv5dMocN50qFC6J2x5yqM0R2c15u DdCOD7IWD6j+37prfPquNMQT0IGtw6+ItEIRkuErgqQmgKgypHmw9SK5Y4lRZkSeGzkb zq7A== X-Received: by 10.204.234.5 with SMTP id ka5mr4830007bkb.5.1374609760287; Tue, 23 Jul 2013 13:02:40 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPSA id l11sm8755508bkk.13.2013.07.23.13.02.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 13:02:39 -0700 (PDT) Sender: Alexander Motin Message-ID: <51EEE15C.6020900@FreeBSD.org> Date: Tue, 23 Jul 2013 23:02:36 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jia-Shiun Li Subject: Re: Panic at USB drive plugging in References: <51EEAA36.6030206@bitfrost.no> <51EEABA3.7060909@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 20:02:42 -0000 On 23.07.2013 21:28, Jia-Shiun Li wrote: > On Wed, Jul 24, 2013 at 12:13 AM, Alexander Motin wrote: >> On 23.07.2013 19:07, Hans Petter Selasky wrote: >>> This looks like a CAM/SCSI problem and not directly USB stack problem. >> >> It seems crashed inside the CAM sg driver, that is not part of GENERIC >> kernel. Are you using it is some way? >> > > No. I do not use it at all. cam.k kernel module includes all existing periph drivers in one bundle. Loading cam.ko you are probably getting sg driver also, that triggers reported issue. You may try to rip out sg with single line hack to module's Makefile. The real fix require looking closer on sg, which I never used. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jul 23 22:24:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 989376C1; Tue, 23 Jul 2013 22:24:05 +0000 (UTC) (envelope-from milu@dat.pl) Received: from jab.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 574C22920; Tue, 23 Jul 2013 22:24:05 +0000 (UTC) Received: from jab.dat.pl (jsrv.dat.pl [127.0.0.1]) by jab.dat.pl (Postfix) with ESMTP id 6A928CB; Wed, 24 Jul 2013 00:23:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at dat.pl Received: from jab.dat.pl ([127.0.0.1]) by jab.dat.pl (jab.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CVcXW8j3ksGZ; Wed, 24 Jul 2013 00:23:57 +0200 (CEST) Received: from [192.168.0.5] (178-36-181-20.adsl.inetia.pl [178.36.181.20]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by jab.dat.pl (Postfix) with ESMTPSA id 214384C; Wed, 24 Jul 2013 00:23:57 +0200 (CEST) Message-ID: <51EF0291.8020103@dat.pl> Date: Wed, 24 Jul 2013 00:24:17 +0200 From: Maciej Milewski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: IPSEC crashes after r253088 References: <20130721054323.915f865769e6042c7dc62d08@tackymt.homeip.net> <51EE309D.2030106@FreeBSD.org> <51EE68D8.9020603@freebsd.org> <51EE7066.9030403@FreeBSD.org> In-Reply-To: <51EE7066.9030403@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , Taku YAMAMOTO , freebsd-current@freebsd.org, Andre Oppermann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 23 Jul 2013 22:24:05 -0000 On 23.07.2013 14:00, Andrey V. Elsukov wrote: > Also, I already prepared patch to test. I've tested it on mips platform and it makes it working fine as before that change. I can succesfully boot system. Thank you for patching it. -- Pozdrawiam, Maciej Milewski From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 06:22:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DBB747AC for ; Wed, 24 Jul 2013 06:22:28 +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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E2F92BB1 for ; Wed, 24 Jul 2013 06:22:28 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1V1sSp-000l4V-Sh>; Wed, 24 Jul 2013 08:22:19 +0200 Received: from e179070139.adsl.alicedsl.de ([85.179.70.139] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1V1sSp-001xUp-Nw>; Wed, 24 Jul 2013 08:22:19 +0200 Date: Wed, 24 Jul 2013 08:22:14 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: ZPOOL import failure due to multiple pool IDs? Message-ID: <20130724082214.3168b664@thor.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/z9kSIl0Em4M+oyfKrrubaOh"; protocol="application/pgp-signature" X-Originating-IP: 85.179.70.139 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 06:22:29 -0000 --Sig_/z9kSIl0Em4M+oyfKrrubaOh Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I have trouble with a ZFS pool after interrupted scrubbing on FreeBSD 10-CURREN (10.0-CURRENT #1 r253579: Tue Jul 23 20:31:59 CEST 2013 amd64). After I shut down the box while the ZFS pool in question was still in scrubbing, after a reboot the system marked that pool as defect. I tried to clean the reported data corruption by adding the -F flag to the import, but surprisingly, the pool has ambigious IDs confusing the system (and me): pool: BACKUP00 id: 257822624560506537 state: FAULTED status: The pool metadata is corrupted. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: http://illumos.org/msg/ZFS-8000-72 config: BACKUP00 FAULTED corrupted data ada3p1 ONLINE pool: BACKUP00 id: 9337833315545958689 state: FAULTED status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: http://illumos.org/msg/ZFS-8000-5E config: BACKUP00 FAULTED corrupted data 8544670861382329237 UNAVAIL corrupted data I do not know what happens here. The pool has been upgraded twice as far as I remember, since the disk/device is used as a compressed backup device and only used for that purpose. But for a couple of time now with FreeBSD 10, it starts to fail when the scrubbing is interrupted by a shutdown. I remember that scrubbing of pools sesumed after the next reboot - but I realised that this seems to be a problem now for some reason on FreeBSD 10. I had a situation like this earlier this year with the same device - amongst another pool after scrubbing didn't resumed as expected. The import of the pool above in question works by using the very first id: id: 257822624560506537. But what is with the other IDs? What are those IDs and labels doing here? Is it possible that ZFS has some bugs revealing older labels/GUIDs of the device from a earlier configuration than the last one configured and prepared for?=20 How can I get rid of those fake/phantom id? Rgards, Oliver --Sig_/z9kSIl0Em4M+oyfKrrubaOh Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJR73KbAAoJEOgBcD7A/5N8LXgH/RplRyulEAtQxoKDXNvjRABY I1T1pmFCmZ2EzPIzTJfnHdOltcq+laAWSa442IMtmUPrww1I2aK8DxpXQPCQRQ/3 b0wUFkyeFYV2vpbhWUO/vkfnlpi9a1atSGBkrGvJVvxYykJodWCmHXzwYTqmhgZM arxjTiBAby9Xv0Hkik3LJShNyo0N9AblOKa9J3aq1bRHsnqO34BKxKJxV9nYKp+G p/QA1W0kbP8OciZx7luyqQAr1lPeU9jHJpB5vlK8Axhb8gr9HC8zCsmUyqnveJQc uD6eHqCKCsuPAIipe84IXc2PIpLOIFwuxxgfgyOUQWm5mNujcYp+y4IFKYeE640= =PWOa -----END PGP SIGNATURE----- --Sig_/z9kSIl0Em4M+oyfKrrubaOh-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 10:10:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EAF7A651 for ; Wed, 24 Jul 2013 10:10:05 +0000 (UTC) (envelope-from prvs=1917699425=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8F02C2760 for ; Wed, 24 Jul 2013 10:10:05 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005125203.msg for ; Wed, 24 Jul 2013 11:10:03 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 24 Jul 2013 11:10:03 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1917699425=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org Message-ID: From: "Steven Hartland" To: "O. Hartmann" , "FreeBSD CURRENT" References: <20130724082214.3168b664@thor.walstatt.dyndns.org> Subject: Re: ZPOOL import failure due to multiple pool IDs? Date: Wed, 24 Jul 2013 11:10:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 10:10:06 -0000 What does zdb on each device report? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 11:48:13 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 85CE3836; Wed, 24 Jul 2013 11:48:13 +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 27D6C2B7F; Wed, 24 Jul 2013 11:48:11 +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 OAA20322; Wed, 24 Jul 2013 14:48:10 +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 1V1xY9-0008Dk-Tl; Wed, 24 Jul 2013 14:48:10 +0300 Message-ID: <51EFBEBF.601@FreeBSD.org> Date: Wed, 24 Jul 2013 14:47:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: r253070 and "disappearing" zpool References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> <20130722203853.GB1400@garage.freebsd.pl> In-Reply-To: <20130722203853.GB1400@garage.freebsd.pl> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Glen Barber , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 11:48:13 -0000 on 22/07/2013 23:38 Pawel Jakub Dawidek said the following: > On Mon, Jul 22, 2013 at 10:29:40AM +0300, Andriy Gapon wrote: >> I think that this setup (on ZFS level) is quite untypical, although not >> impossible on FreeBSD (and perhaps only FreeBSD). >> It's untypical because you have separate boot pool (where loader, loader.conf >> and kernel are taken from) and root pool (where "/" is mounted from). > > As I said elsewhere, it is pretty typical when full disk encryption is > used. I am judging by the number of reports / amount of feedback so far. > The /boot/ has to be unencrypted and can be stored on eg. USB > pendrive which is never left unattended, unlike laptop which can be left > in eg. a hotel room, but with entire disk encrypted. As we discussed elsewhere, there are many options of configuring full disk encryption. Including decisions whether root filesystem should be separate from boot filesystem, choice of filesystem type for boot fs, ways of tying various pieces together, and many more. I do not believe that my change is incompatible with full disk encryption in general. >> So, I see three ways of resolving the problem that my changes caused for your >> configuration. >> >> 1. [the easiest] Put zpool.cache loading instructions that used to be in >> defaults/loader.conf into your loader.conf. This way everything should work as >> before -- zpool.cache would be loaded from your boot pool. >> >> 2. Somehow (I don't want to go into any technical details here) arrange that >> your root pool has /boot/zfs/zpool.cache that describes your boot pool. This is >> probably hard given that your /boot is a symlink at the moment. This probably >> would be easier to achieve if zpool.cache lived in /etc/zfs. >> >> 3. [my favorite] Remove an artificial difference between your boot and root >> pools, so that they are a single root+boot pool (as zfs gods intended). As far >> as I understand your setup, you use GELI to protect some sensitive data. >> Apparently your kernel is not sensitive data, so I wonder if your /bin/sh or >> /sbin/init are really sensitive either. >> So perhaps you can arrange your unencrypted pool to hold all of the base system >> (boot + root) and put all your truly sensitive filesystems (like e.g. /home or >> /var/data or /opt/xyz) onto your encrypted pool. > > If all you care about is laptop being stolen, then that would work. > > If you however want to be protected from someone replacing your /sbin/init > with something evil then you use encryption or even better integrity > verification also supported by GELI. There are different ways to ensure that. Including storing cryptographic checksums in a safe place or keeping init in the same place where kernel is kept. And probably many more. > Remember, tools not policies. I am not trying to enforce any policy on end-users here. > There is also option number 4 - backing out your commit. That's definitely an option. I'll discuss it a few lines below. > When I saw your commit removing those entries from defaults/loader.conf, > I thought it is fine, as we now don't require zpool.cache to import the > root pool, which was, BTW, very nice and handy improvement. Now that we > know it breaks existing installations I'd prefer the commit to be backed > out. "breaks" sounds dramatic, but let's take a step back and see what exactly is broken. The system in question still can boot without a problem, it is fully usable and it is possible to change its configuration without any hassle. The only thing that changed is that its boot pool is not imported automatically. Let's also recall that the system was not created / configured by any of the existing official or semi-official tools and thus it does not represent any recommended way of setting up such systems. Glen configured it this way, but it doesn't mean that that is the way. I think that there are many of ways of changing configuration of that system to make behave as before again. Three I mentioned already. Another is to add rc script to import the boot pool, given that it is a special, designated pool. Yet another is to place zpool.cache onto the root pool and use nullfs (instead of a symlink) to make /boot be from the boot pool but /boot/zfs be from the root pool. > This is because apart from breaking some existing installations it >> doesn't gain us anything. I think I addressed the "breaking" part, as to the gains - a few lines below. >> So I understand that my change causes a problem for a setup like yours, but I >> believe that the change is correct. > > The change is clearly incorrect or incomplete as it breaks existing > installations and doesn't allow for full disk encryption configuration > on ZFS-only systems. I think I addressed the breaking part and also addressed your overly general statement about full disk encryption. So I don't think that my change is "clearly incorrect", otherwise that would be clear even to me. > BTW. If moving zpool.cache to /etc/zfs/ will work for both cases that's > fine by me, although the migration might be tricky. Yes, that's migration that's scary to me too. Now, about the postponed points. I will reproduce a section from my email that you've snipped. >> P.S. >> ZFS/FreeBSD boot process is extremely flexible. For example zfsboot can take >> zfsloader from pool1/fsA, zfsloader can boot kernel from pool2/fsB and kernel >> can mount / from pool3/fsC. Of these 3 filesystems from where should >> zpool.cache be taken? >> My firm opinion is that it should be taken from / (pool3/fsC in the example >> above). Because it is the root filesystem that defines what a system is going >> to do ultimately: what daemons are started, with what configurations, etc. >> And thus it should also determine what pools to auto-import. >> We can say that zpool.cache is analogous to /etc/fstab in this respect. So do you or do you not agree with my reasoning about from where zpool.cache should be taken? If you do not, then please explain why. If you do, then please explain how this would be compatible with the old way of loading zpool.cache. I think that ensuring that zpool.cache is always loaded from a root filesystem is the gain from my change. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 14:26:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8559F860; Wed, 24 Jul 2013 14:26:39 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 495AE2288; Wed, 24 Jul 2013 14:26:39 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id k14so1135003oag.12 for ; Wed, 24 Jul 2013 07:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wz/c48R5WduxmKaquuEmGVpes8u6Ud5Wf1iAePZOuns=; b=h19fqKgiJ6ze4naWlXKIpttAYTo+IVIu3hP/83SHXmZshUqWG1arzVWc7/FyIENf6l A7SZOH/nFOaNAbTsvBo8uepmmq6NOmp+9XFKB/G9QLlH6808EeEN5rMc+AJZihaQdtXk kEavWQvstmxt/OWEljygRY94FTsZ4zqT+ycKfKEU4YbtvSFvFwjCOXQYatdihuPj/Ppr RsJEmMsu0ZliHLhZP1uCtZKpBehI0fKbCqabEFTAKIHn1N7cOzyQKxDtQWeZXyxGzZXP qCr3+U6vjxTfPPxT1G0M0H7xT9wCCwwBpdIEjaArblbiz2VQbYOUcXCTH1s0QZpj41Nu xqNg== X-Received: by 10.60.95.198 with SMTP id dm6mr36650318oeb.44.1374675998238; Wed, 24 Jul 2013 07:26:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.131.111 with HTTP; Wed, 24 Jul 2013 07:26:08 -0700 (PDT) In-Reply-To: <51EEE15C.6020900@FreeBSD.org> References: <51EEAA36.6030206@bitfrost.no> <51EEABA3.7060909@FreeBSD.org> <51EEE15C.6020900@FreeBSD.org> From: Jia-Shiun Li Date: Wed, 24 Jul 2013 22:26:08 +0800 Message-ID: Subject: Re: Panic at USB drive plugging in To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 14:26:39 -0000 On Wed, Jul 24, 2013 at 4:02 AM, Alexander Motin wrote: > cam.k kernel module includes all existing periph drivers in one bundle. > Loading cam.ko you are probably getting sg driver also, that triggers > reported issue. You may try to rip out sg with single line hack to module's > Makefile. The real fix require looking closer on sg, which I never used. > Indeed. Test result did confirm that if sg is not included in cam.ko USB drives will not cause kernel to panic. Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 14:37:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 57475BDD for ; Wed, 24 Jul 2013 14:37:22 +0000 (UTC) (envelope-from vsityz@gmail.com) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E276F232E for ; Wed, 24 Jul 2013 14:37:21 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id c13so291773eek.3 for ; Wed, 24 Jul 2013 07:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8FGiSHpy9PMjqyWsnoRKTD97T6ik6DLBtTtz7dR+tPs=; b=vKO7kC6x6KnP9HrDMsbFRn8pXSXKO2gAOVCbZ0DC4BJcStwYgxQqMEXaA+1oJh8brv 68OcypMrRjZglidjQA/blCk+fwe5qodWoR1g0+8dUVXw4cXM9jO1dO89gIsg+nryprZt 1ybhwU319I5O5ZlOJaJy8A0QaLfqLM08OXEmBfZUhUkxOap/NXECUYfpMx18TRvAQHvn OyqiFtPNOLjX04w74aX62FXV3AI9vNQa2yzOZZPJrP+m8JAZyjgz3Oy2utGuhnI1zSsA HZ+Dn2gqogk2osk/Vt2z9N9fcAm5bZ7XQf/LcRuC7MyZCJCnKbwtStZ5NZVrv2bH4C28 fFQw== X-Received: by 10.15.108.8 with SMTP id cc8mr37635270eeb.65.1374676640143; Wed, 24 Jul 2013 07:37:20 -0700 (PDT) Received: from scorpion.kiev.ua ([46.247.165.131]) by mx.google.com with ESMTPSA id e44sm66572605eeh.11.2013.07.24.07.37.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 07:37:18 -0700 (PDT) Message-ID: <51EFE69A.9050100@gmail.com> Date: Wed, 24 Jul 2013 17:37:14 +0300 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130721 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current Subject: Re: FUSE not work. References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> <51EAA6A3.0@FreeBSD.org> In-Reply-To: <51EAA6A3.0@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 14:37:22 -0000 20.07.2013 18:02, Pedro Giffuni пишет: > On 19.07.2013 23:42, Kevin Oberman wrote: >> ... >> >> >> fuse is at least partly broken in -current. I discovered that if you >> mount two devices that use fuse, when you umount any of them, ll are >> marked as not mounted and disappear from df(1) or mount(8) output, >> but only one is actually cleanly unmounted and, if it has been >> written to, will likely be corrupt. This applies to at least ntfs. >> >> ATM no one is supporting fuse in current, so this may become a >> serious issue before long. > > I reverted my incompatible changes and will try to see if upstream wants > to adopt something compatible for birthtime support. > > I do agree that fuse needs a lot of work. I wonder if NetBSD's > puffs/libperfuse > is any better. > > Pedro. Can we expect in the near future a working version of FUSE to FreeBSD 10? From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 15:22:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 55CA6EE0; Wed, 24 Jul 2013 15:22:21 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B3F482519; Wed, 24 Jul 2013 15:22:20 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id p58so389758wes.40 for ; Wed, 24 Jul 2013 08:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=V8nZsDlfVYgGSLv1ToN8jZQmxkhjSQPHpLaM6JWYuKA=; b=XVWZlwqL1tEaF+gecRAL5VOT4MIGlnptZegi4mPuUKgu2FrQR5M0+uV2tiOO+FdvxL aWi2/ZcvO/OdZevLS04MA3/T+TgWziHX75YV62kyRY7/Z4ElBs0sxsfFMh1HDDpPl2+U FdLmkVybufXiysjI3Uq4KJsXrdgNe2oso9NNj6ouudJFpRbIUQkC2sV4RMRak4J1lfXX RWEz+p4k+xHPqyly/wU8uDfJKkNHMYcs6sTnlQTvbQD0HuLNWRY8/pfsVpilbeLvH/Fc bU78ASuohKGX8nHkcSj2WNXCtvr9PnxBUtvfIVNzXMPP1suKJ54WXTYdxsMxo3ZSD4I+ 2Vaw== X-Received: by 10.180.208.105 with SMTP id md9mr3013145wic.57.1374679339093; Wed, 24 Jul 2013 08:22:19 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id i1sm6011241wiz.6.2013.07.24.08.22.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Jul 2013 08:22:18 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 24 Jul 2013 17:22:16 +0200 From: Baptiste Daroussin To: Kevin Oberman Subject: Re: FUSE not work. Message-ID: <20130724152216.GE63694@ithaqua.etoilebsd.net> References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q8BnQc91gJZX4vDc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Panyushkin , Pedro Giffuni , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 15:22:21 -0000 --Q8BnQc91gJZX4vDc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 19, 2013 at 09:42:41PM -0700, Kevin Oberman wrote: > On Fri, Jul 19, 2013 at 6:22 PM, Pedro Giffuni wrote: >=20 > > On 19.07.2013 12:07, Alexander Panyushkin wrote: > > > >> 19.07.2013 19:42, Pedro Giffuni =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> > >>> (re-posting since the original response didn't make it through) > >>> > >>> On 19.07.2013 10:29, Alexander Panyushkin wrote: > >>> > >>>> 19.07.2013 17:36, Pedro Giffuni =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>>> > >>>>> Hello; > >>>>> > >>>>> The internal data structures in the FUSE kernel module have been > >>>>> updated to be more compatible with MacFUSE and the linux FUSE. > >>>>> > >>>>> This basically means you have to rebuild your fuse modules > >>>>> (including NTFS). > >>>>> > >>>>> We should not really update the FUSE_KERNEL_MINOR_VERSION yet. > >>>>> I will add a note to UPDATING. > >>>>> > >>>>> Pedro. > >>>>> > >>>> > >>>> > >>>> > >>>> Unfortunately the port is not build in FreeBSD 10 > >>>> > >>>> > >>>> =3D=3D=3D>>> Starting build for sysutils/fusefs-kmod <<<=3D=3D=3D > >>>> > >>>> > >>> fusefs-kmod is not needed on -current. I meant you have to rebuild > >>> and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. > >>> > >>> Since this is a ports issue I will not update the UPDATING file. > >>> > >>> Developers that need to know should use __FreeBSD_version > >>> 1000038 as a reference. > >>> > >>> > >> I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no eff= ect. > >> > >> sysctl kern.osreldate > >> kern.osreldate: 1000037 > >> > >> ntfs-3g /dev/ad10s1 /mnt/ntfs_0 > >> mount > >> ... > >> /dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous) > >> > >> ls -la /mnt/ntfs_0 > >> unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053 > >> getattr / > >> unique: 18, success, outsize: 112 > >> fuse: writing device: Invalid argument > >> ls: /mnt/ntfs_0: Input/output error > >> > >> fuse is at least partly broken in -current. I discovered that if you > mount two devices that use fuse, when you umount any of them, ll are mark= ed > as not mounted and disappear from df(1) or mount(8) output, but only one = is > actually cleanly unmounted and, if it has been written to, will likely be > corrupt. This applies to at least ntfs. >=20 > ATM no one is supporting fuse in current, so this may become a serious > issue before long. This is fixed now. btw this problem is/was not related to fuse on current but rather to fusefs-libs. Bapt --Q8BnQc91gJZX4vDc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHv8SgACgkQ8kTtMUmk6Ex4/gCgovd8Gwy+wIGlt80H8pnk23zk FHMAn1jmPxqM3EDKiTCTEOkXNYOfTS10 =zCmx -----END PGP SIGNATURE----- --Q8BnQc91gJZX4vDc-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 18:16:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EE789D27; Wed, 24 Jul 2013 18:16:52 +0000 (UTC) (envelope-from vsityz@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2F8602368; Wed, 24 Jul 2013 18:16:52 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g10so419647eak.4 for ; Wed, 24 Jul 2013 11:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9/aMqd1FXoBSOMUKjsXsibxVsPWlZOQEBClZh0xtQx8=; b=idnI268ekdQYUpZIIiixABoWnOg7esMgZJX8KVR2QMZnaUPu1/iLyHr15bPpE4j5wL yqq4t5UZN6ChQ5vy4vnkgDOhvgRnQfs8GciA8MYlsj7E+ZFgLnDVDyRpYX+DIJBbW2Ii h/9qK0Pg2ErNFXiV/eHUKcxSQJUgiZ8yuUzEfThHIzqXpPsob44FW1kCF3iMMcOcg8rp 2raSGHumIWJDeuhzmYP6tTYZZ7JYgwWJBccS4uHUFaRoJE1C1FfXpNQVo7fB5VlXciPr Hh4uV9wJEYk18CT8osRdPynGqSnjMuz/9gHLmMqAc+0g+cPwwYq8cfBeAT9QYJSP7FCh hHOA== X-Received: by 10.15.54.198 with SMTP id t46mr39121772eew.74.1374689810460; Wed, 24 Jul 2013 11:16:50 -0700 (PDT) Received: from scorpion.kiev.ua ([46.247.165.131]) by mx.google.com with ESMTPSA id r54sm67864089eev.8.2013.07.24.11.16.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 11:16:49 -0700 (PDT) Message-ID: <51F01A0C.2070808@gmail.com> Date: Wed, 24 Jul 2013 21:16:44 +0300 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130721 Thunderbird/17.0.7 MIME-Version: 1.0 To: Baptiste Daroussin , FreeBSD Current Subject: Re: FUSE not work. References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> <20130724152216.GE63694@ithaqua.etoilebsd.net> In-Reply-To: <20130724152216.GE63694@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Kevin Oberman , Pedro Giffuni X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 18:16:53 -0000 24.07.2013 18:22, Baptiste Daroussin пишет: > On Fri, Jul 19, 2013 at 09:42:41PM -0700, Kevin Oberman wrote: >> On Fri, Jul 19, 2013 at 6:22 PM, Pedro Giffuni wrote: >> >>> On 19.07.2013 12:07, Alexander Panyushkin wrote: >>> >>>> 19.07.2013 19:42, Pedro Giffuni пишет: >>>> >>>>> (re-posting since the original response didn't make it through) >>>>> >>>>> On 19.07.2013 10:29, Alexander Panyushkin wrote: >>>>> >>>>>> 19.07.2013 17:36, Pedro Giffuni пишет: >>>>>> >>>>>>> Hello; >>>>>>> >>>>>>> The internal data structures in the FUSE kernel module have been >>>>>>> updated to be more compatible with MacFUSE and the linux FUSE. >>>>>>> >>>>>>> This basically means you have to rebuild your fuse modules >>>>>>> (including NTFS). >>>>>>> >>>>>>> We should not really update the FUSE_KERNEL_MINOR_VERSION yet. >>>>>>> I will add a note to UPDATING. >>>>>>> >>>>>>> Pedro. >>>>>>> >>>>>> >>>>>> >>>>>> Unfortunately the port is not build in FreeBSD 10 >>>>>> >>>>>> >>>>>> ===>>> Starting build for sysutils/fusefs-kmod <<<=== >>>>>> >>>>>> >>>>> fusefs-kmod is not needed on -current. I meant you have to rebuild >>>>> and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. >>>>> >>>>> Since this is a ports issue I will not update the UPDATING file. >>>>> >>>>> Developers that need to know should use __FreeBSD_version >>>>> 1000038 as a reference. >>>>> >>>>> >>>> I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no effect. >>>> >>>> sysctl kern.osreldate >>>> kern.osreldate: 1000037 >>>> >>>> ntfs-3g /dev/ad10s1 /mnt/ntfs_0 >>>> mount >>>> ... >>>> /dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous) >>>> >>>> ls -la /mnt/ntfs_0 >>>> unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053 >>>> getattr / >>>> unique: 18, success, outsize: 112 >>>> fuse: writing device: Invalid argument >>>> ls: /mnt/ntfs_0: Input/output error >>>> >>>> fuse is at least partly broken in -current. I discovered that if you >> mount two devices that use fuse, when you umount any of them, ll are marked >> as not mounted and disappear from df(1) or mount(8) output, but only one is >> actually cleanly unmounted and, if it has been written to, will likely be >> corrupt. This applies to at least ntfs. >> >> ATM no one is supporting fuse in current, so this may become a serious >> issue before long. > This is fixed now. > > btw this problem is/was not related to fuse on current but rather to > fusefs-libs. > > Bapt I am rebuilding now world uname -a FreeBSD scorpion.kiev.ua 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Wed Jul 24 20:34:19 EEST 2013 root@scorpion.kiev.ua:/usr/obj/usr/src/sys/Kernel amd64 and ports fusefs-libs-2.9.3 and fusefs-ntfs-2012.1.15 Problem not fixed. From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 18:22:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8C958118; Wed, 24 Jul 2013 18:22:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD4A523BC; Wed, 24 Jul 2013 18:22:58 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ey16so810219wid.4 for ; Wed, 24 Jul 2013 11:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mIDOr3FHCa+l31PcnKhL1wx0TggsQZnT1pEt1o2Xrj0=; b=z1N2MfU3n4YRlrxfhaww0yuE14JAruXnhvCxSBMz7uPaPIPPEErWAY5GAC3ou8GuH3 EI5OF6zeiHfpnjhYctnkjwScOsETjSuDFVWtOkjh8yJXu83SPArXCStyEQJdQuF2KfX+ gibOpjNJyfIqnm31Zl7/BEtqLbUFPMZNhyGKQDV/cnRxCWYPyb12QwIa603r95fmHUNb dlQStIaFz5P8pF2HXwzaXPfBI88GyazIooYUC2/4g+VWHoU3Bfjvp1mg6ZxdBSrZXQZW sFBNlfHo4SuxWeeE9qUtop2MZ2mW0J0VyQcCJbSxBASQSvr9BMGJRxv2vfX8dCjoKA7s TYqQ== MIME-Version: 1.0 X-Received: by 10.194.11.72 with SMTP id o8mr28417727wjb.0.1374690177097; Wed, 24 Jul 2013 11:22:57 -0700 (PDT) Received: by 10.217.94.132 with HTTP; Wed, 24 Jul 2013 11:22:57 -0700 (PDT) Date: Wed, 24 Jul 2013 11:22:57 -0700 Message-ID: Subject: poudriere problems with fuse? From: Adrian Chadd To: Pedro Giffuni , Baptiste Daroussin , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 18:22:59 -0000 Hi Pedro, Bapt tells me that there are FUSE issues in the most recent -HEAD and it's stopping poudriere from running. What's the story here? -adrian From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 18:34:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9D07C6F4; Wed, 24 Jul 2013 18:34:40 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE51B245F; Wed, 24 Jul 2013 18:34:39 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id z12so739359wgg.34 for ; Wed, 24 Jul 2013 11:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4+GcyMPLKME7ABHTEpiDKj+yQiEzSJ1AH3sKu8yfuvg=; b=uV2Rk73ZRZlmmidlLV7nhWKUEr6va9L7K58HCNXpUcczCGl128OAouTW95u1cM/lL6 1snnvsdIZYeJvPw60c6D/OcoOv/0yr3b/fGx2KqE1t8FCyJYsX2nQ005JZy+uGLIr2cO xbLM8WrCjJH1tLsXW5UMpX2bgBdBE7yTv6x0SprJtByAX8nt1Jh8IjMabb9iuz9hhwzI QsVKwV4k2EvX6hsJL3yL5RdCiBfFhoSAJ5swSvoGzs8EO27CCFTEwktLrda0Po2pwQLs 02gwzp6topT+Nq/sOzu8H947m05KdTvH6Q5EbGnlR08KUT9t3GuHHUjitK7cDgtEdPR9 Om3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4+GcyMPLKME7ABHTEpiDKj+yQiEzSJ1AH3sKu8yfuvg=; b=dbsvu/nks34c5A1ghxSrIyqD6EebKFwXrGR0+vOfUQdktbb2xY+K/+BJf6pG5LBWUH hp1tKDr7LPEaQ4sD83HQOIYAGDYX/vZAcJN5WU8/dJkvKC9mMEDeZP91FWS6EX8TIOGa gB7SR2SWh0V+bq7GAWBUA0sL7kgnPjPHcmoKqBit6f7fLQW+pPBksjdwGtfPgZqg9MVf Hcl1mVoOtdkBmHWPHZ4nCknWG75xDtA7r0PAd7eun+TaDw2RffsBfTzE9htu5tgpaWWW OzLYUsQYCZIwXA2VPh5qUbgXcIrjp4lgxXGwmwu7VR/Rb3TUhdi1XDB2mUGY7N8twrPY ji1g== X-Received: by 10.180.160.165 with SMTP id xl5mr3603917wib.46.1374690878140; Wed, 24 Jul 2013 11:34:38 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id ev19sm7214384wid.2.2013.07.24.11.34.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Jul 2013 11:34:37 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 24 Jul 2013 20:34:35 +0200 From: Baptiste Daroussin To: Adrian Chadd Subject: Re: poudriere problems with fuse? Message-ID: <20130724183435.GH63694@ithaqua.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbfcI4OLZ4XW0yH2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Pedro Giffuni , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 18:34:40 -0000 --VbfcI4OLZ4XW0yH2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 11:22:57AM -0700, Adrian Chadd wrote: > Hi Pedro, >=20 > Bapt tells me that there are FUSE issues in the most recent -HEAD and > it's stopping poudriere from running. Nah poudriere does not use yet fuse :) >=20 > What's the story here? >=20 I was about to mail you :) It is broken since r248084 apparently the update on the fuse_kernel.h you d= id is not in sync with fusefs-libs, resulting in no filesystem to properly work. Do you have any insight on the reason of the changes? and I should look at? regards, Bapt --VbfcI4OLZ4XW0yH2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHwHjsACgkQ8kTtMUmk6Ey2SgCbBzAz/iilnOiGYS4lVfnfjmIc 3lkAoJLCSGAWMwg0B8p02iel1tIfVU8m =Z3hH -----END PGP SIGNATURE----- --VbfcI4OLZ4XW0yH2-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 18:35:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2FF7081F for ; Wed, 24 Jul 2013 18:35:11 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm48-vm9.bullet.mail.gq1.yahoo.com (nm48-vm9.bullet.mail.gq1.yahoo.com [67.195.87.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01E1F2475 for ; Wed, 24 Jul 2013 18:35:10 +0000 (UTC) Received: from [98.137.12.57] by nm48.bullet.mail.gq1.yahoo.com with NNFMP; 24 Jul 2013 18:29:44 -0000 Received: from [208.71.42.195] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 24 Jul 2013 18:29:44 -0000 Received: from [127.0.0.1] by smtp206.mail.gq1.yahoo.com with NNFMP; 24 Jul 2013 18:29:44 -0000 X-Yahoo-Newman-Id: 832067.1765.bm@smtp206.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: FSIsR54VM1m8_OG1gKRiRDhDwPErpqZVjG0Rsv8EXoNLK18 _1xUuvZQDCbOFL_uoTkghkXm.V.clkqkSCSvyGtGHiZKYmAuT563O5hZ8q9c 6j6PDvzP6HUpfx5WE4o0nbtUP7F7fGdlM16NDRn1aT0el_q472YzKTSVlIj. Q0k_KEYKSAF45apSak7TNdcHj2l7a5uj1DYxFBtURBkAWrXgzBtdpT6BWArb EGDWjHz9AJp60317sBfkz9lcsTgiB.cuMsCco9.wSI3p6OOkzN4DgG57NkS6 unFDbRSDYzHM1IsfeHL_Fbr1lU3aI9J3JYQLKL0MV8V4QEwUzb._SGNJSUyI N8CCmhVhPsCWgayNAC5p0ow5asnKgS76pZ8taiQ2t.3C060vglFeynczxpjA 8Qusj7w0QelnWJPt6XfS86Q14jtGV8bTW3y8jxfVklop2I.zN0fhNi9rzDvx sOVSqNo_nFtfzr4OfmYwxJwwHb6F9MAn0SNxLZWJ_q_rvkM.GTQPzcDHESdr hlXebvkUJR5YuzYBZnQxdofcHeQ-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp206.mail.gq1.yahoo.com with SMTP; 24 Jul 2013 11:29:43 -0700 PDT Message-ID: <51F01D14.5080304@FreeBSD.org> Date: Wed, 24 Jul 2013 13:29:40 -0500 From: Pedro Giffuni Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: poudriere problems with fuse? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Baptiste Daroussin , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 18:35:11 -0000 Hi; El 24/07/2013 1:22 p. m., Adrian Chadd escribió: > Hi Pedro, > > Bapt tells me that there are FUSE issues in the most recent -HEAD and > it's stopping poudriere from running. > > What's the story here? > I reverted all my birthtime changes, the remaining change is only a header update from upstream that helps things get in line with the header included in the port. I have no idea what may be broken but it predates my short involvement with fuse. Sorry that I have no responsible answer :(. Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 18:36:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6E7EC9DF; Wed, 24 Jul 2013 18:36:15 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA028249C; Wed, 24 Jul 2013 18:36:14 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hq4so821480wib.14 for ; Wed, 24 Jul 2013 11:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=HYxCk9daYSmGWi0oQErNWY76eJFXbS7rf8ViRoGrVfA=; b=qy3qfHAkP9kqb5PFYQJwEPU93o3HJMrXzEd1yxWwqC1FrgUb7/dcgT7yokCIsQwUOS P2mharT54qRDzNmum/nn2q7oSxh947/lDIqkm1SZxGjOW4n+u1wJSgdqyoOgx+mOyxki uQciTAJaiWUGBjTwNLceMN5uihaiX5xSQhb4JNQk6WXcZMh8cejuiPEzbqPTRuKVx1Gf PLce+GZWM5tRw6M2y3gk9MV2ChI+I1W4YLV/IC3MTuCWahoxc+PwxFVXYF7IJ2iiV0Sy Nf0+6W1LELSDjDRWyBitSLFVdpFvM4WwcgY04ShC60zk46JugtRCgkrtWD6uX5kvj6C8 I+kw== X-Received: by 10.194.8.163 with SMTP id s3mr28157375wja.41.1374690973076; Wed, 24 Jul 2013 11:36:13 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id fb2sm7226338wic.4.2013.07.24.11.36.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Jul 2013 11:36:12 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 24 Jul 2013 20:36:10 +0200 From: Baptiste Daroussin To: Alexander Panyushkin Subject: Re: FUSE not work. Message-ID: <20130724183610.GI63694@ithaqua.etoilebsd.net> References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> <20130724152216.GE63694@ithaqua.etoilebsd.net> <51F01A0C.2070808@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Az4VpBrmI9+OyhK/" Content-Disposition: inline In-Reply-To: <51F01A0C.2070808@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kevin Oberman , FreeBSD Current , Pedro Giffuni X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 18:36:15 -0000 --Az4VpBrmI9+OyhK/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 09:16:44PM +0300, Alexander Panyushkin wrote: > 24.07.2013 18:22, Baptiste Daroussin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Fri, Jul 19, 2013 at 09:42:41PM -0700, Kevin Oberman wrote: > >> On Fri, Jul 19, 2013 at 6:22 PM, Pedro Giffuni wrote: > >> > >>> On 19.07.2013 12:07, Alexander Panyushkin wrote: > >>> > >>>> 19.07.2013 19:42, Pedro Giffuni =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>>> > >>>>> (re-posting since the original response didn't make it through) > >>>>> > >>>>> On 19.07.2013 10:29, Alexander Panyushkin wrote: > >>>>> > >>>>>> 19.07.2013 17:36, Pedro Giffuni =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>>>>> > >>>>>>> Hello; > >>>>>>> > >>>>>>> The internal data structures in the FUSE kernel module have been > >>>>>>> updated to be more compatible with MacFUSE and the linux FUSE. > >>>>>>> > >>>>>>> This basically means you have to rebuild your fuse modules > >>>>>>> (including NTFS). > >>>>>>> > >>>>>>> We should not really update the FUSE_KERNEL_MINOR_VERSION yet. > >>>>>>> I will add a note to UPDATING. > >>>>>>> > >>>>>>> Pedro. > >>>>>>> > >>>>>> > >>>>>> > >>>>>> Unfortunately the port is not build in FreeBSD 10 > >>>>>> > >>>>>> > >>>>>> =3D=3D=3D>>> Starting build for sysutils/fusefs-kmod <<<=3D=3D=3D > >>>>>> > >>>>>> > >>>>> fusefs-kmod is not needed on -current. I meant you have to rebuild > >>>>> and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. > >>>>> > >>>>> Since this is a ports issue I will not update the UPDATING file. > >>>>> > >>>>> Developers that need to know should use __FreeBSD_version > >>>>> 1000038 as a reference. > >>>>> > >>>>> > >>>> I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no e= ffect. > >>>> > >>>> sysctl kern.osreldate > >>>> kern.osreldate: 1000037 > >>>> > >>>> ntfs-3g /dev/ad10s1 /mnt/ntfs_0 > >>>> mount > >>>> ... > >>>> /dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous) > >>>> > >>>> ls -la /mnt/ntfs_0 > >>>> unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053 > >>>> getattr / > >>>> unique: 18, success, outsize: 112 > >>>> fuse: writing device: Invalid argument > >>>> ls: /mnt/ntfs_0: Input/output error > >>>> > >>>> fuse is at least partly broken in -current. I discovered that if you > >> mount two devices that use fuse, when you umount any of them, ll are m= arked > >> as not mounted and disappear from df(1) or mount(8) output, but only o= ne is > >> actually cleanly unmounted and, if it has been written to, will likely= be > >> corrupt. This applies to at least ntfs. > >> > >> ATM no one is supporting fuse in current, so this may become a serious > >> issue before long. > > This is fixed now. > > > > btw this problem is/was not related to fuse on current but rather to > > fusefs-libs. > > > > Bapt > I am rebuilding now world > uname -a > FreeBSD scorpion.kiev.ua 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Wed Jul=20 > 24 20:34:19 EEST 2013 root@scorpion.kiev.ua:/usr/obj/usr/src/sys/Kernel = =20 > amd64 >=20 > and ports fusefs-libs-2.9.3 and fusefs-ntfs-2012.1.15 > Problem not fixed. >=20 Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to that vers= ion and it will work, I'm investigating. What I fix is the umount umounting all the FS. regards, Bapt --Az4VpBrmI9+OyhK/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHwHpoACgkQ8kTtMUmk6Exg9wCfTOz3hxM6DzQ/yswvv50Qk8V2 rCIAn1bqBTJVNVvHiR/aVa9eRih5mlRh =YeI1 -----END PGP SIGNATURE----- --Az4VpBrmI9+OyhK/-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 18:49:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 787AEEE7; Wed, 24 Jul 2013 18:49:34 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D510A2570; Wed, 24 Jul 2013 18:49:33 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id c11so766107wgh.8 for ; Wed, 24 Jul 2013 11:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=pgQN/frVRAP6dwjEju42TdMkyNx8ghP9iEch2iGvoN0=; b=jU+wVzgeYAu1hBJkaNxRLB9pNCpFoCcT5etOfk+XbwaIHvIzST7hh/Sxx5MoPiH57y s6yhur15LjvnL8Sq4GBC/u3H/LT0nOu2hxZkQVBOqVHJld71F/4PfOma2ip3H3KHPBGT gkSGXfDYnBtngVNF03p2JPBCgjLaBf4MeEHOaGEgQtQH/Na/U10koBmzfIP9uLziQIFW XfaGRB6dY0Noz5T9tZ0rPtMzh9kC0WuOv4E74DoKhulgjwH/cT4Gg9pT70Uj9seY6vK4 qjZXnGvO9xOWd+85x5ErxqjryzvK2OBqveliNbFwk2jxJoUxAHKG8LjiOfO8J6Z4FPs1 w8yg== X-Received: by 10.194.120.7 with SMTP id ky7mr27611115wjb.89.1374691772284; Wed, 24 Jul 2013 11:49:32 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id li9sm7312901wic.2.2013.07.24.11.49.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Jul 2013 11:49:31 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 24 Jul 2013 20:49:30 +0200 From: Baptiste Daroussin To: Alexander Panyushkin Subject: Re: FUSE not work. Message-ID: <20130724184929.GA41432@ithaqua.etoilebsd.net> References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> <20130724152216.GE63694@ithaqua.etoilebsd.net> <51F01A0C.2070808@gmail.com> <20130724183610.GI63694@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <20130724183610.GI63694@ithaqua.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kevin Oberman , FreeBSD Current , Pedro Giffuni X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 18:49:34 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 08:36:10PM +0200, Baptiste Daroussin wrote: > On Wed, Jul 24, 2013 at 09:16:44PM +0300, Alexander Panyushkin wrote: > > 24.07.2013 18:22, Baptiste Daroussin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > On Fri, Jul 19, 2013 at 09:42:41PM -0700, Kevin Oberman wrote: > > >> On Fri, Jul 19, 2013 at 6:22 PM, Pedro Giffuni wro= te: > > >> > > >>> On 19.07.2013 12:07, Alexander Panyushkin wrote: > > >>> > > >>>> 19.07.2013 19:42, Pedro Giffuni =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > >>>> > > >>>>> (re-posting since the original response didn't make it through) > > >>>>> > > >>>>> On 19.07.2013 10:29, Alexander Panyushkin wrote: > > >>>>> > > >>>>>> 19.07.2013 17:36, Pedro Giffuni =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > >>>>>> > > >>>>>>> Hello; > > >>>>>>> > > >>>>>>> The internal data structures in the FUSE kernel module have been > > >>>>>>> updated to be more compatible with MacFUSE and the linux FUSE. > > >>>>>>> > > >>>>>>> This basically means you have to rebuild your fuse modules > > >>>>>>> (including NTFS). > > >>>>>>> > > >>>>>>> We should not really update the FUSE_KERNEL_MINOR_VERSION yet. > > >>>>>>> I will add a note to UPDATING. > > >>>>>>> > > >>>>>>> Pedro. > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Unfortunately the port is not build in FreeBSD 10 > > >>>>>> > > >>>>>> > > >>>>>> =3D=3D=3D>>> Starting build for sysutils/fusefs-kmod <<<=3D=3D=3D > > >>>>>> > > >>>>>> > > >>>>> fusefs-kmod is not needed on -current. I meant you have to rebuild > > >>>>> and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. > > >>>>> > > >>>>> Since this is a ports issue I will not update the UPDATING file. > > >>>>> > > >>>>> Developers that need to know should use __FreeBSD_version > > >>>>> 1000038 as a reference. > > >>>>> > > >>>>> > > >>>> I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no= effect. > > >>>> > > >>>> sysctl kern.osreldate > > >>>> kern.osreldate: 1000037 > > >>>> > > >>>> ntfs-3g /dev/ad10s1 /mnt/ntfs_0 > > >>>> mount > > >>>> ... > > >>>> /dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous) > > >>>> > > >>>> ls -la /mnt/ntfs_0 > > >>>> unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053 > > >>>> getattr / > > >>>> unique: 18, success, outsize: 112 > > >>>> fuse: writing device: Invalid argument > > >>>> ls: /mnt/ntfs_0: Input/output error > > >>>> > > >>>> fuse is at least partly broken in -current. I discovered that if y= ou > > >> mount two devices that use fuse, when you umount any of them, ll are= marked > > >> as not mounted and disappear from df(1) or mount(8) output, but only= one is > > >> actually cleanly unmounted and, if it has been written to, will like= ly be > > >> corrupt. This applies to at least ntfs. > > >> > > >> ATM no one is supporting fuse in current, so this may become a serio= us > > >> issue before long. > > > This is fixed now. > > > > > > btw this problem is/was not related to fuse on current but rather to > > > fusefs-libs. > > > > > > Bapt > > I am rebuilding now world > > uname -a > > FreeBSD scorpion.kiev.ua 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Wed Jul= =20 > > 24 20:34:19 EEST 2013 root@scorpion.kiev.ua:/usr/obj/usr/src/sys/Kernel= =20 > > amd64 > >=20 > > and ports fusefs-libs-2.9.3 and fusefs-ntfs-2012.1.15 > > Problem not fixed. > >=20 >=20 > Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to that ve= rsion > and it will work, I'm investigating. >=20 > What I fix is the umount umounting all the FS. >=20 > regards, > Bapt Forgot to say r248084 is the last working revision. regards, Bapt --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHwIbkACgkQ8kTtMUmk6EwpGwCfY4SDhJp0KxsosamQQhDQszLk QF8AoLEdkIyUrWIOOTq/UZb1JI5MGJAh =kbmp -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 19:01:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7FC555AE for ; Wed, 24 Jul 2013 19:01:08 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2FD752691 for ; Wed, 24 Jul 2013 19:01:08 +0000 (UTC) Received: from [66.196.81.174] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 18:55:23 -0000 Received: from [98.139.211.194] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 18:55:23 -0000 Received: from [127.0.0.1] by smtp203.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 18:55:23 -0000 X-Yahoo-Newman-Id: 997482.77700.bm@smtp203.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WHkKVysVM1kmPlK5royTTG5KWpmbZlRloiifFes.MMVIlwf SSFGbLaXD8oXSAZ8Pgq6sHgv4lGkRrEkXZt2Fz892PAXXFnF1bK29CHq.NTC wbodjaiaDY8ii0X1Qf_LM.XF..HJyY4xEAfJaI8hipkFzShbmWt.BKA6j.ou v.BOE5Q0WwMWKSXFqckS1CZVp5x8uet3iFCE_xG3SO4Y76rlS6MZCSQGjdDP AQsRrRS5ij4YBRkoYIfRZgSSpidCQ.eoa90bO4a0YG2rBOSDF4u3TQhfNiaP Y11VJuNyXArBNNzhOXA7ogrsM.LgLSVQ5eW9i0vaf9DvK65FVrU0WCYg39.v 4uivuPnxjvAdOKEob5.TLV.4WAPILQwaD690Fx_kdyw8NctF2.b0dhRbhxvv P8JSehJJVR8q3vno80X87lwblLAQ3b0C.6zg432qFo6rzgd8kYGUO22qaOSt rdSw_OiHfYTbs2dLurjqGA6K9v.RkIdFhJ6sG4.YIJxaSoQjwI7i6DxRASCf 6gBC1jHRGSe21yGdlxI3zrtFgkw-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp203.mail.bf1.yahoo.com with SMTP; 24 Jul 2013 11:55:22 -0700 PDT Message-ID: <51F02319.40202@FreeBSD.org> Date: Wed, 24 Jul 2013 13:55:21 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: poudriere problems with fuse? References: <20130724183435.GH63694@ithaqua.etoilebsd.net> In-Reply-To: <20130724183435.GH63694@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 19:01:08 -0000 On 24.07.2013 13:34, Baptiste Daroussin wrote: > On Wed, Jul 24, 2013 at 11:22:57AM -0700, Adrian Chadd wrote: >> Hi Pedro, >> >> Bapt tells me that there are FUSE issues in the most recent -HEAD and >> it's stopping poudriere from running. > Nah poudriere does not use yet fuse :) >> What's the story here? >> > I was about to mail you :) > > It is broken since r248084 apparently the update on the fuse_kernel.h you did is > not in sync with fusefs-libs, resulting in no filesystem to properly work. > > Do you have any insight on the reason of the changes? and I should look at? The change came from upstream. Does it help to revert it all? Another option could be to teach the port to use the kernel header but it doesn't look like that would work either :(. Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 19:07:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 63BC37F4; Wed, 24 Jul 2013 19:07:27 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C38632707; Wed, 24 Jul 2013 19:07:26 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id n11so807307wgh.2 for ; Wed, 24 Jul 2013 12:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=rOol6iXb2x2ZUcxTaZK2JjkKdqvpQC314K+sjOwvz88=; b=AC3duED94Z0Aq+VXzBs/efZgc5I1+jslCs/w/IpVHqkrGRTdFRTsfmrs6K0qsfq5r5 cjOkgb6BCliI42s5AyUijnOuMNQvK5Zrh9hq8tPyT3QBsvmcXwyDK7GABEiZV4WpyERq HN10rekVRB7LQ54UZ8+QHiEpgWK8rA3GRi/8ThLet2wSaQzHEk42RkGxyhFV7qf05wcK 8G/FulBLcmzVaS6iPxw1i42QoygBGWSxTzYv9NuJ5hQS3+Gu9GZmZ13dVokeJiSIB1Q6 GUbkK0l7YwcY6m4srKUsQzFrGH733ptHEWF0gHnIrjXBVIxd+TzMyokC20OrWbpCdueP LZMA== X-Received: by 10.180.126.10 with SMTP id mu10mr3656421wib.64.1374692844041; Wed, 24 Jul 2013 12:07:24 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id r8sm7399654wiz.5.2013.07.24.12.07.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Jul 2013 12:07:23 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 24 Jul 2013 21:07:21 +0200 From: Baptiste Daroussin To: Pedro Giffuni Subject: Re: poudriere problems with fuse? Message-ID: <20130724190721.GB41432@ithaqua.etoilebsd.net> References: <20130724183435.GH63694@ithaqua.etoilebsd.net> <51F02319.40202@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Yylu36WmvOXNoKYn" Content-Disposition: inline In-Reply-To: <51F02319.40202@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 19:07:27 -0000 --Yylu36WmvOXNoKYn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 01:55:21PM -0500, Pedro Giffuni wrote: > On 24.07.2013 13:34, Baptiste Daroussin wrote: > > On Wed, Jul 24, 2013 at 11:22:57AM -0700, Adrian Chadd wrote: > >> Hi Pedro, > >> > >> Bapt tells me that there are FUSE issues in the most recent -HEAD and > >> it's stopping poudriere from running. > > Nah poudriere does not use yet fuse :) > >> What's the story here? > >> > > I was about to mail you :) > > > > It is broken since r248084 apparently the update on the fuse_kernel.h y= ou did is > > not in sync with fusefs-libs, resulting in no filesystem to properly wo= rk. > > > > Do you have any insight on the reason of the changes? and I should look= at? >=20 > The change came from upstream. Does it help to revert it all? >=20 > Another option could be to teach the port to use the kernel header > but it doesn't look like that would work either :(. Yes reverting will help r248084 is the last known working revision. Updating the header should be done with modification on the code itself to implement the missing bits. has some things has changed, I have seen some interesting things https://github.com/bfleischer/fuse-macosx I might probab= ly have a look at it later. Thank you for fast reply, regards, Bapt --Yylu36WmvOXNoKYn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHwJekACgkQ8kTtMUmk6ExXgwCfVEdnxTUFIwBNawyauzJzk6LF u7gAoJqOsEW4/g3ykUkBz2/sdDV2t9dk =yKje -----END PGP SIGNATURE----- --Yylu36WmvOXNoKYn-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 20:14:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DBC75894 for ; Wed, 24 Jul 2013 20:14:03 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6204B298E for ; Wed, 24 Jul 2013 20:14:03 +0000 (UTC) Received: from [98.139.212.147] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 20:13:55 -0000 Received: from [98.139.211.204] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 20:13:55 -0000 Received: from [127.0.0.1] by smtp213.mail.bf1.yahoo.com with NNFMP; 24 Jul 2013 20:13:55 -0000 X-Yahoo-Newman-Id: 622184.3416.bm@smtp213.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vdsApOYVM1nZupUtrrSPmMdKqVy7.mn6_4G_LNQxt01cQrF RiC2h.9j6QNflD9uQ5_N7BhzXuqUBcmH6X02SUy7KvCcdWu3OFFK.upSaBXw DH7YJq8sOuN8O5t.zPFWo956fYYhJvw7ZfS5JFKRp0pTsFQ9EvytpF5aBq9. iIA7aXCh07LjCOYqM9P3OwCazekDk5JBagrTQgm1SH2kqQC5x.6Xvw2rUU8s 0R7uen.n6fK_Ic6AE4l.EDOaSJTKoIacnS3xYfxZPDbYWruoDdheOK3CQs8c 4Sl67QDlLUWJ9DJoaJWfTHA5Nfm0pbmjLLQH4i9ObFwfE3ibp.cmrmjWLOh0 Vk334R8szIWSHkqCcbmtud.eYVeOLbdoEwClnEV0Bo8EaM7K91ylhB_0EwEr SvCvHtTsgyCDwbfmHJZ7t7TbiTebh0qDBJqJRGdO6_ocTRSPiG65RF3KBQh2 QalnyE29qDvgvwB96UFpjVRCc2DBySfJyLbl2alBparZuhbrYlE7Jej_bMIb T_I4aNAzjtXistW0vIAmLdhPH_j2xtdkYCnYBcfI2wCyOpgOqKvQ7Nyz3AR_ z0E0ez76reE7RKg5Vd0WmDmPAWuME8UZIavcWiwvugU59d8DC X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp213.mail.bf1.yahoo.com with SMTP; 24 Jul 2013 13:13:55 -0700 PDT Message-ID: <51F03581.6060605@FreeBSD.org> Date: Wed, 24 Jul 2013 15:13:53 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: poudriere problems with fuse? References: <20130724183435.GH63694@ithaqua.etoilebsd.net> <51F02319.40202@FreeBSD.org> <20130724190721.GB41432@ithaqua.etoilebsd.net> In-Reply-To: <20130724190721.GB41432@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 20:14:03 -0000 On 24.07.2013 14:07, Baptiste Daroussin wrote: > On Wed, Jul 24, 2013 at 01:55:21PM -0500, Pedro Giffuni wrote: >> On 24.07.2013 13:34, Baptiste Daroussin wrote: >>> On Wed, Jul 24, 2013 at 11:22:57AM -0700, Adrian Chadd wrote: >>>> Hi Pedro, >>>> >>>> Bapt tells me that there are FUSE issues in the most recent -HEAD and >>>> it's stopping poudriere from running. >>> Nah poudriere does not use yet fuse :) >>>> What's the story here? >>>> >>> I was about to mail you :) >>> >>> It is broken since r248084 apparently the update on the fuse_kernel.h you did is >>> not in sync with fusefs-libs, resulting in no filesystem to properly work. >>> >>> Do you have any insight on the reason of the changes? and I should look at? >> The change came from upstream. Does it help to revert it all? >> >> Another option could be to teach the port to use the kernel header >> but it doesn't look like that would work either :(. > Yes reverting will help r248084 is the last known working revision. I am perfectly OK with reverting, of course. > Updating the header should be done with modification on the code itself to > implement the missing bits. has some things has changed, I have seen some > interesting things https://github.com/bfleischer/fuse-macosx I might probably > have a look at it later. I see, there are least two macosx fuse forks but it appears they were merged into osxfuse. Things become rather confusing since we are using the linux fuse-libs with yet another header and NetBSD has a completely different implementation using puffs with librefuse/libperfuse. For now let's just fix things :). Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 20:27:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3BC89C5C for ; Wed, 24 Jul 2013 20:27:17 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm20-vm5.bullet.mail.gq1.yahoo.com (nm20-vm5.bullet.mail.gq1.yahoo.com [98.136.217.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A7D02A12 for ; Wed, 24 Jul 2013 20:27:16 +0000 (UTC) Received: from [98.137.12.55] by nm20.bullet.mail.gq1.yahoo.com with NNFMP; 24 Jul 2013 20:27:10 -0000 Received: from [208.71.42.192] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 24 Jul 2013 20:27:10 -0000 Received: from [127.0.0.1] by smtp203.mail.gq1.yahoo.com with NNFMP; 24 Jul 2013 20:27:10 -0000 X-Yahoo-Newman-Id: 679.64222.bm@smtp203.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DzatKcwVM1lupUzKRakpJ5aKzaH22CcG791n2gVJRWTKhOJ a23zVRumOIZpqXSOWsyWcpyBCbilzte8Y15DM2f6qjmaQqkB5pK9jF946v.v eRTkvvsUjers.u1JODn.WoWZOxrAjgm8xj9QrRDAwiYdcS5H4e60r85OpCM1 QJ0fqzh4HuSqbu8R1NcsWMrIyxoaA8B9.xqXPZz.vZRjF1UNBjWBam0fQqid zvhDPahULm8Fjh3ctOkJ00OmfRt3wgOVu6rtyIpz6ewewKNuQObIUnhfhmkr 7FY0D3sy.5p1q4e4jdUf7AT01QDbAzhA4W1xQROdJZ1hgcBowtE0Qa5sjOTJ fIMApmBY7KAWC87uq0YX4_kTDPDBk8gc0ZzbK5oSsTmB6zfyZDEYqmkoDr2g cLq8kB0O_F8DMRtYcQs5hSf3758s5jifbHkUQ2YFUAHcFLtdnVKd71TJB7xE P26EHHA8SRrxE_hJh8N7NpCT4KhMCCPYZ4keuN15LMAQlAVjdrfZujV8qiWH ePy8xbZWCOTRCWIzstSUcjsE9ldWyGn0- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp203.mail.gq1.yahoo.com with SMTP; 24 Jul 2013 13:27:09 -0700 PDT Message-ID: <51F0389B.3020800@FreeBSD.org> Date: Wed, 24 Jul 2013 15:27:07 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: FUSE not work. References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> <20130724152216.GE63694@ithaqua.etoilebsd.net> <51F01A0C.2070808@gmail.com> <20130724183610.GI63694@ithaqua.etoilebsd.net> <20130724184929.GA41432@ithaqua.etoilebsd.net> In-Reply-To: <20130724184929.GA41432@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Panyushkin , Kevin Oberman , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 20:27:17 -0000 On 24.07.2013 13:49, Baptiste Daroussin wrote: > ... >> Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to that version >> and it will work, I'm investigating. >> >> What I fix is the umount umounting all the FS. >> >> regards, >> Bapt > Forgot to say r248084 is the last working revision. Sorry for the delay, OK, I reverted the kernel header update in revision 253619 hopefully this will save everyone affected some pain ... Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 22:31:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0A7A186; Wed, 24 Jul 2013 22:31:30 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 120882F88; Wed, 24 Jul 2013 22:31:29 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id c10so5728100wiw.2 for ; Wed, 24 Jul 2013 15:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=bSSlvz0hqaRgjbM5a2Z7ua5o2AMqzAP2ybVdlNRBYK0=; b=sx7VURbX1otXGLWcftN+pzP35CVocXizwfixdkbPoW8UcKHNszcU69NM/SfWzMwkH+ mnpUhtyDeXbBV0PtdJjEWSHnehZLBd0F5jqfD+b7AauLyINP0Nd0yq32qiTcAIHXlLUs dULFc0WZKwqWayJs34Av4STegPTAWD5FZliskZvxmIDGBvtb4Brb+kXq8alSGK2H8Hj1 K1M7MwTpo+aBVbn47YBTxQSa4cxECn/bRPJCzB4mLQxp5Vieg+12sTge5N8Woqhlite8 Q6Y1aSesiZK38uj+a1dwONWbaVQSLxK8tXOABdBNocgqovNrDqtUahAH2gAf9PiknbCs Pv7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=bSSlvz0hqaRgjbM5a2Z7ua5o2AMqzAP2ybVdlNRBYK0=; b=MRnynSh5uoa2J4SYAN5MeXnwWxrz04fQ5/PGrCGaUN06Ka7ByLDIJZ85eS9BviJIz6 nwdfqwvSU3zsKCkQmPIodXTHfVVojZAEJcxK9BiBm1hgFoi8pa+B0mY6OsoRiy15hVxG aCNZFnG0fzxafWlwDzutLN5/DsnkkKxtGfvxIc+1BLWt8fJeEsiCJkMSruYykRlLZlfg PROgtQB996ouM15IQqLhVa5oPccOv5kYFppQ3LA5/b/GwV7+ekfr4MbgB9mjdQH2qAkI R67VviuNvrbxGGylOcXHeOjlVOI/tSM2lfKOVxp89XMVWmjDpNROoogfgo0CcX07BwYC 0thw== X-Received: by 10.180.198.10 with SMTP id iy10mr4276193wic.29.1374705088465; Wed, 24 Jul 2013 15:31:28 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id i1sm8385253wiz.6.2013.07.24.15.31.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Jul 2013 15:31:27 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 25 Jul 2013 00:31:26 +0200 From: Baptiste Daroussin To: Pedro Giffuni Subject: Re: FUSE not work. Message-ID: <20130724223125.GD41432@ithaqua.etoilebsd.net> References: <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> <20130724152216.GE63694@ithaqua.etoilebsd.net> <51F01A0C.2070808@gmail.com> <20130724183610.GI63694@ithaqua.etoilebsd.net> <20130724184929.GA41432@ithaqua.etoilebsd.net> <51F0389B.3020800@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wULyF7TL5taEdwHz" Content-Disposition: inline In-Reply-To: <51F0389B.3020800@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Panyushkin , Kevin Oberman , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 22:31:30 -0000 --wULyF7TL5taEdwHz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 03:27:07PM -0500, Pedro Giffuni wrote: > On 24.07.2013 13:49, Baptiste Daroussin wrote: > > ... > >> Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to that= version > >> and it will work, I'm investigating. > >> > >> What I fix is the umount umounting all the FS. > >> > >> regards, > >> Bapt > > Forgot to say r248084 is the last working revision. >=20 > Sorry for the delay, >=20 > OK, I reverted the kernel header update in revision 253619 > hopefully this will save everyone affected some pain ... >=20 Thank you very much ! regards, Bapt --wULyF7TL5taEdwHz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHwVb0ACgkQ8kTtMUmk6ExBqACeP+aY6fZWo1Ih9Wo902VS5AMI NG8An06vRyzjqVVHsjWNigQTTvKtOOFx =dUzf -----END PGP SIGNATURE----- --wULyF7TL5taEdwHz-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 24 22:35:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A25313FC; Wed, 24 Jul 2013 22:35:20 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54D802FB1; Wed, 24 Jul 2013 22:35:20 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id fb19so14624837obc.9 for ; Wed, 24 Jul 2013 15:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pOCzLiuKd1ibPU7fSZEMbQaqzFFolWANlKsPVycHvXU=; b=CpepZoWPcyNBrI2iHLW6/py5yBCbd0NzoPG9TG2ViHGGMvB2+XvAjM4lZxELw74Evr JYTDVgOHf/OBE2g+1ge6vgjR6uidp9yAgzqc6A1AnNi4fjidGAvODj8u81up7V7pDDYF Leg8HHlsSmwBrYqvTp78jqWTZw85ByL3s7act65QURVnI8yHvN9/y3CW/h04b5COhj0+ NNPxmwHq4vRqKSU1c0h00FbyfM0ASKo4MxjBL4R8zSuIHAvyARULH8O8r2eb0/fuQO1p en4nCe6huo9z9KAnAo7TSdFfsPO6+NmYPrtJPwSryxd/JOmTV9fIUmJhLL5Ppa1OYM3a riug== MIME-Version: 1.0 X-Received: by 10.60.125.100 with SMTP id mp4mr39048715oeb.60.1374705319592; Wed, 24 Jul 2013 15:35:19 -0700 (PDT) Received: by 10.182.115.194 with HTTP; Wed, 24 Jul 2013 15:35:19 -0700 (PDT) Date: Wed, 24 Jul 2013 18:35:19 -0400 Message-ID: Subject: Kern.hz= +1 hertz at anything 2500 and above. From: Super Bisquit To: FreeBSD PowerPC ML , FreeBSD Hackers , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 24 Jul 2013 22:35:20 -0000 http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html This is the thread that I was referring to earlier. Since the patch is for 2009, what are the chances it would work with 10.x or 9.x? On PowerPC machines with a low MHz rate- or any machine with a CPU rate of 800 MHz or less- increasing the kern.hz improves performance and cuts down on latency. I am building audio applications and suites that are used in different projects. A G3 based machine should be able to run a kernel with kern.hz=5000 with no problem. Unfortunately, this cannot be done. @PowerPC: some of you may find that performance does increase at a higher kern.hz rate. @Hackers & Current: What's the chance that the default rate limit can be raised to 5k? From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 00:16:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22149A6C; Thu, 25 Jul 2013 00:16:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5CAD722C2; Thu, 25 Jul 2013 00:16:23 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b13so1046363wgh.7 for ; Wed, 24 Jul 2013 17:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TzexVlQiR9mG3cTHzwSuiuEJNw3quhMjW8dJ5xYCjPg=; b=CTqBdsTRgSFLZzEX/jdbvhIPpZUZskhTB7fVQVBozWf+b+xZR+1Fic3CRMENsDzW2u sljRdO6r6EtdzjcYCJVZ5ZKzbnviRuXbCJ3kYXWLTqIF816i1LaiiCxlaq9GvYJrUFML HQBNWs8j3FOELLqT4zijxDH84YEIVkVkQmHKhXI7iiM8/jCS21gJwRnjd/DUfEL6YsYX Ec9P8tRR9LWXXXs4pop/uzzF/M6bgL2+X6GL/T2mu4GfGwYDK9Q2kTaybhbZKU0C5JNO pYfXjy316JelmhhUwovwgOb+30DOhHFpSIQiuTgIFiKIr/fFm3mHJBdf4Im+69tnY4ww X3bw== MIME-Version: 1.0 X-Received: by 10.194.92.6 with SMTP id ci6mr4577182wjb.79.1374711381631; Wed, 24 Jul 2013 17:16:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Wed, 24 Jul 2013 17:16:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Jul 2013 17:16:21 -0700 X-Google-Sender-Auth: fsisARJh9DVWyxUH3IDFNYPF6pA Message-ID: Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. From: Adrian Chadd To: Super Bisquit Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 00:16:24 -0000 Well, why is it reducing latency? That's the thing you should investigate. Is it because processes aren't getting enough time? or too much time? Or the audio device isn't getting enough time to run? etc. -adrian On 24 July 2013 15:35, Super Bisquit wrote: > http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html > > This is the thread that I was referring to earlier. Since the patch is for > 2009, what are the chances it would work with 10.x or 9.x? > > On PowerPC machines with a low MHz rate- or any machine with a CPU rate of > 800 MHz or less- increasing the kern.hz improves performance and cuts down > on latency. I am building audio applications and suites that are used in > different projects. A G3 based machine should be able to run a kernel with > kern.hz=5000 with no problem. Unfortunately, this cannot be done. > > @PowerPC: some of you may find that performance does increase at a higher > kern.hz rate. > > @Hackers & Current: What's the chance that the default rate limit can be > raised to 5k? > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 01:04:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 43ED8606; Thu, 25 Jul 2013 01:04:18 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB0102462; Thu, 25 Jul 2013 01:04:17 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id j6so2863393oag.29 for ; Wed, 24 Jul 2013 18:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=2uN7lFesbOCR5N86YX2eUGdhDur1ZJFzmHKl1OtS+Oo=; b=BPk7dwXCJZldRhJOlkubjjSAhcQomMCVDzJ3E2JqL+wIb48bx51wgRi1yh5oOKlnLI iOAvL0FTUDmwe7HXcBYklrkDLynC7thZgBnZX81bquWYH2vJjffDZ6dFgFyDeSGzBMuF Vgwwhxgyq0ozktgr8IDhZm9hjC53oIqQc+Qehyg1hoPTGwn6Az5ytV1185evjm6bRUQa sjveWACp2JuuAQyJSN123IHXc0fiWGBMqSXqWDMGEODM6UiMSGSFVBaj0dlao8yVhIvn MKpqJufDAsEnYhLGhFg3koXTiK5yxrOm0GxDslMYFd5qECVwC8+hY4IsFAEjjAuSdamx uleA== MIME-Version: 1.0 X-Received: by 10.60.125.100 with SMTP id mp4mr39510828oeb.60.1374714257003; Wed, 24 Jul 2013 18:04:17 -0700 (PDT) Received: by 10.182.115.194 with HTTP; Wed, 24 Jul 2013 18:04:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Jul 2013 21:04:16 -0400 Message-ID: Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. From: Super Bisquit To: Adrian Chadd , FreeBSD PowerPC ML , freebsd-current , FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 01:04:18 -0000 When I started with FreeBSD on a G3 B&W, I noticed that the performance improved with a higher kern.hz rating. Unless the future holds an emu20k2, there will be RAM used from the motherboard. 1. I will need a real-time or a faster kernel- hence the high rate wanted- because the devices to be built will be used in an active environment: art, music, audio control. 2. Any system with limited memory and a low CPU hertz rate benefits from the higher kern.hz setting. 3. Why not? If it works for PowerPC, SPARC64, AMD64, and i386 then it may work for other architectures. 4. Some applications may be ran from within a jail. On Wed, Jul 24, 2013 at 8:16 PM, Adrian Chadd wrote: > Well, why is it reducing latency? That's the thing you should investigate. > > Is it because processes aren't getting enough time? or too much time? > Or the audio device isn't getting enough time to run? etc. > > > > -adrian > > On 24 July 2013 15:35, Super Bisquit wrote: > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html > > > > This is the thread that I was referring to earlier. Since the patch is > for > > 2009, what are the chances it would work with 10.x or 9.x? > > > > On PowerPC machines with a low MHz rate- or any machine with a CPU rate > of > > 800 MHz or less- increasing the kern.hz improves performance and cuts > down > > on latency. I am building audio applications and suites that are used in > > different projects. A G3 based machine should be able to run a kernel > with > > kern.hz=5000 with no problem. Unfortunately, this cannot be done. > > > > @PowerPC: some of you may find that performance does increase at a higher > > kern.hz rate. > > > > @Hackers & Current: What's the chance that the default rate limit can be > > raised to 5k? > > _______________________________________________ > > freebsd-ppc@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 08:39:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 47F4BC45; Thu, 25 Jul 2013 08:39:22 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 81B5E267A; Thu, 25 Jul 2013 08:39:21 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hq4so1478044wib.2 for ; Thu, 25 Jul 2013 01:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=6dzsvEzLrDbVodSoYyJS2s69gMOvPfs0TZV3NquW8rs=; b=ZePUgi9Nmj5h1NP76jUsPx1nVFpQ2EqWPUoTLyZD1RyzSVOufHJ5UaYD5MHj3gRylc 8tGBQKAHGYYn1iXFtMoq/kIFxCF1FXMaXQeK61IrLKfjeb5U2s/J48Ki4egWJJLh4D6q KnMiOy/e9rrlS172xdqkgZ0b5Xpxn3/HWPWZKi3Em7DXty/6O/4Hgsvt6GpvtoN5q0xT arWgQ7cK3GK35bHdt+1FjPXutyy06PrXzbYaNZW3WZOhSU9Ke/u1uksAudv2nsD+ZDLt nOrWonkbNLwOhfkFOQzKiXvRzRGnYkk/Hau2e6RwZ9hX4yDBJBjj1cg8rbCxPVBE4950 tycQ== X-Received: by 10.194.58.11 with SMTP id m11mr30173618wjq.45.1374741559845; Thu, 25 Jul 2013 01:39:19 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id nb12sm136978wic.3.2013.07.25.01.39.19 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jul 2013 01:39:19 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 25 Jul 2013 10:39:17 +0200 From: Baptiste Daroussin To: java@FreeBSD.org, current@FreeBSD.org, ports@FreeBSD.org Subject: [Call For Help] Clang + OpenJDK + head + amd64 == cocktail of death (for clusters) Message-ID: <20130725083917.GH41432@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+G3HLlWI7eRTl+h" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 08:39:22 -0000 --k+G3HLlWI7eRTl+h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, It's been a while since we are experiencing major problem on the package buidling cluster: it dies when building package for head amd64. (the buidling jail being the snapshort from July 7th iirc.) After some investigation we discover that blacklisting openjdk6 allows the building process to go to completion again. But not providing java packages is not a good solution. We have managed to "fix" the build by limiting the allowed memory usage on each building jail to 8G, the result is a huge load of java packages just fail to build because it eats all the memory and then segfault, but at least they do not kill the box again. Have a look at the pkg-fallout mailing list you should be able to see lots of java port failed because of that. It seems to happen only on head amd64, so far we think it is only happening when jdk is built with clang. I have no time, neither skill to investigate that, so please if you are interested in having java packages available have a look at it, fix the problem if any may that be clang, openjdk, the ports tree framework for java building, or anything related. Otherwise I'll have to mark all failing packages as broken on head amd64 in the portstree :( regards, Bapt --k+G3HLlWI7eRTl+h Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHw5DUACgkQ8kTtMUmk6EzcLgCfQKPgpE9L8dwIjUzy5CRNwuEj Fz4AnAx6Y4qqT2VvKoe9a0tDEO0VRJGB =awG9 -----END PGP SIGNATURE----- --k+G3HLlWI7eRTl+h-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 09:32:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C8E0546D; Thu, 25 Jul 2013 09:32:01 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DF1D2B0E; Thu, 25 Jul 2013 09:32:00 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r6P9VqDX044203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Jul 2013 19:31:52 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.7/8.14.7) with ESMTP id r6P9VkiB063723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Jul 2013 19:31:46 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.7/8.14.7/Submit) id r6P9VkmD063722; Thu, 25 Jul 2013 19:31:46 +1000 (EST) (envelope-from peter) Date: Thu, 25 Jul 2013 19:31:46 +1000 From: Peter Jeremy To: Baptiste Daroussin Subject: Re: [Call For Help] Clang + OpenJDK + head + amd64 == cocktail of death (for clusters) Message-ID: <20130725093146.GF86483@server.rulingia.com> References: <20130725083917.GH41432@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <20130725083917.GH41432@ithaqua.etoilebsd.net> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@freebsd.org, java@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 09:32:01 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Jul-25 10:39:17 +0200, Baptiste Daroussin wrote: >After some investigation we discover that blacklisting openjdk6 allows the >building process to go to completion again. =2E.. >It seems to happen only on head amd64, so far we think it is only >happening when jdk is built with clang. This mail arrives at an opportune time. I've just discovered that if I build openjdk6 with clang (on head/amd64), the resultant jdk SEGV's if I again try to build openjdk6. If I build it with "USE_GCC=3Dany" then the problem goes away. >I have no time, neither skill to investigate that, I don't have the time to investigate further but forcing the use of gcc instead of clang is at least a workaround. --=20 Peter Jeremy --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHw8IIACgkQ/opHv/APuIcs2wCfVxkMDIeEpQfv/tKLS84sQ2FB gTEAn2ZhwQiPR37EJqrVt8hdMLCUaiYL =qpCB -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 09:42:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BEB53A1F; Thu, 25 Jul 2013 09:42:04 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 03D632BBC; Thu, 25 Jul 2013 09:42:03 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q56so424401wes.21 for ; Thu, 25 Jul 2013 02:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=MCk/fSKAhqwZnfw/R/JPQgY7i9/4zIAdDD2QgqV0It4=; b=E8CMxKQMIkSRyfbu3Ww5AZhxWKD3bHva9ofWRtnxcMbavp9YBdoLscphDVZAGwgBN7 njI1mg2b9QLV6QjWubBcOsO/RYAw3143cvSa0ZQXaYwB9ZXYDEYG3G7uXo1pXSsL/OR9 SZzwgfXT7xp3GvH8DOQdzmxYfhskSctmRoJZ0sx9MBPofsQwiQrcCPBiTGIyUlBMWVqm CHZqmJQxrV2bNhijeS/qG4Q8TBJTlA2WRvbyqUvnMHPE3yFJFWV72we4NG/NBkXH1kFZ s2dG/vAA7uR4B3+VeP3D6qNqPCSqkSddsAkwhRNevFIglIpS6buLeYZA82j00QrYvJGe LbXA== X-Received: by 10.180.184.12 with SMTP id eq12mr1398682wic.8.1374745322389; Thu, 25 Jul 2013 02:42:02 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id s19sm2389779wik.11.2013.07.25.02.42.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jul 2013 02:42:01 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 25 Jul 2013 11:41:59 +0200 From: Baptiste Daroussin To: Dmitry Samersoff Subject: Re: [Call For Help] Clang + OpenJDK + head + amd64 == cocktail of death (for clusters) Message-ID: <20130725094159.GA61207@ithaqua.etoilebsd.net> References: <20130725083917.GH41432@ithaqua.etoilebsd.net> <51F0EC1E.90100@samersoff.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <51F0EC1E.90100@samersoff.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@FreeBSD.org, java@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 09:42:04 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2013 at 01:13:02PM +0400, Dmitry Samersoff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Baptiste, >=20 > If I understand you correct, hotspot crashes because of out of memory > or some other resource constraint? >=20 > Could you send me whole hs_err_.log file (or better couple of it)? >=20 > - -Dmitry I would love to but this is done on the cluster where the jail is wiped out= once it finished (failure or not) Best would be probably to ulimit -m 4194304 before building let say textpro= c/fop =66rom the ports tree. you should hit it pretty quickly. regards, Bapt --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHw8ucACgkQ8kTtMUmk6EyodQCeNbU1+zLvGo1Wlnc0UZ79Fl3f WUgAnRb8tCkghfef1fa95+U6xqNusrXh =zopE -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 11:07:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 95798550; Thu, 25 Jul 2013 11:07:46 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 682892137; Thu, 25 Jul 2013 11:07:45 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id a16so1413015lbj.3 for ; Thu, 25 Jul 2013 04:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/3G89/atJ5BvsbzxU5UwR81LtW8W0DMIaKe7HHF4v5o=; b=jeRuesPdpn1g7Zm8+DDxMsMOHLmitroCCcNIG6dKvE4K3YeBIuBua4rpjAnbvt6NVe sZ83Hhmi0HanE/SWCkXFBwhYj7CpBWtNV6i8jEsp1fP1EyLnxa9Pr7AAnot7k/jI4rHU yXIXX5qi3MiE2tkJYyg4VQ/0WhOX0LBBt0I/80yigWB7JGVOZOWcQgRguxMd+ZObxcja KTinkod106Y8kQNHS0iZcN3dCAwgx1mz1PoH7VlMcHGiuOAAKZtDJXQWv+uoVvb9RbzG vDB/TrVzteTs8LTRsLkVyZk1hlB0t4efVNPbxRJT0yOj+TkSfr5lqqaPIComwJSx4B49 rzuA== X-Received: by 10.152.19.138 with SMTP id f10mr499401lae.21.1374750463183; Thu, 25 Jul 2013 04:07:43 -0700 (PDT) Received: from Sevans-MacBook-Air-11.local ([46.250.130.143]) by mx.google.com with ESMTPSA id 6sm16209811lbu.13.2013.07.25.04.07.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 04:07:42 -0700 (PDT) Message-ID: <51F106F6.7050700@gmail.com> Date: Thu, 25 Jul 2013 15:07:34 +0400 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ports@FreeBSD.org Subject: Re: [Call For Help] Clang + OpenJDK + head + amd64 == cocktail of death (for clusters) References: <20130725083917.GH41432@ithaqua.etoilebsd.net> <51F0EC1E.90100@samersoff.net> <20130725094159.GA61207@ithaqua.etoilebsd.net> In-Reply-To: <20130725094159.GA61207@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: java@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 11:07:46 -0000 Trying to build openjdk6 dies on r253620 Tried setting MAKE_JOBS_UNSAFE=yes with not much success, happy to do further testing if anyone has any diffs or suggestions. Sevan / Venture37 ---> Reinstalling 'openjdk6-b27_5' (java/openjdk6) ---> Building '/usr/ports/java/openjdk6' ===> Cleaning for openjdk6-b27_5 ===> License GPLv2 accepted by the user ===> Found saved configuration for openjdk6-b27_5 ===> openjdk6-b27_5 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by openjdk6-b27_5 for building ===> Extracting for openjdk6-b27_5 => SHA256 Checksum OK for openjdk-6-src-b27-26_oct_2012.tar.gz. => SHA256 Checksum OK for jaxp144_05.zip. => SHA256 Checksum OK for jdk6-jaxws2_1_6-2011_06_13.zip. => SHA256 Checksum OK for jdk6-jaf-b20.zip. => SHA256 Checksum OK for apache-ant-1.8.4-bin.tar.bz2. ===> Patching for openjdk6-b27_5 ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/jaxp.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/jaxws.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20120830/7182135-impossible_to_use_some_editors_directly.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7201068.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/6563318.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/6664509.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/6776941.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7141694.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7173145.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7186945.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7186948.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7186952.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7186954.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7192392.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7192393.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7192977.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7197546.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7200491.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7200500.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7201064.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7201066.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7201070.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/7201071.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/8000210.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/8000537.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/8000540.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/8000631.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/8001242.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/8001307.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/8001972.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130201/8002325.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130219/8006446.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130219/8006777.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130219/8007688.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130304/8007014.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130304/8007675.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/7036559-concurrenthashmap_improvements.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8009063.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/8004302-soap_test_failure.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/6657673.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/6657673-fixup.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/7133220-factory_finder_parser_transform_useBSClassLoader.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/6657673-factory_finder.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6669869-queries_per_appcontext.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/5102804-memory_leak.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6963811-deadlock_fix.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/7064279-resource_release.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/7064279-fixup.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/7200507.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8000724.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8004986.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6501644-icu_sync.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6886358-layout_update.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8001031.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/7017324-kerning_crash.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8001040.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8001322.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8001329.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8003335.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8003445.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8003543.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8004261.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8004336.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8005432.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8005943.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8006309.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8006435.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8006790.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8006795.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8007406.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8007617.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8007667.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8007918.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8009305.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8009699.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8009814.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130416/8009857.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/7195301-no_instanceof_node.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6469266-xmlsec_1.4.2.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/6741606-apache_santuario.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/7170730-windows_network_stack.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8000638-improve_deserialization.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8001032-restrict_object_access-corba.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8001033-refactor_address_handling.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8001034-memory_management.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8001038-resourcefully_handle_resources.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8001043-clarify_definition_restrictions.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8001309-better_handling_of_annotation_interfaces.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8001318-socket_getlocaladdress_consistency.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8001318-6_fixup.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8001330-improve_checking_order.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8003703-update_rmi_connection_dialog.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/8005615-failure_to_load_logger_implementation.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/8007393.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/8007611.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8004584-augment_applet_contextualization.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8005007-better_glyph_processing.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8006328-sound_class_robustness.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8006328-6_fixup.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8006611-improve_scripting.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8007467-improve_jmx_internal_api_robustness.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8007471-improve_mbean_notifications.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8007471-6_fixup.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8007812-getenclosingmethod.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008120-improve_jmx_class_checking.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008124-better_compliance_testing.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008128-better_jmx_api_coherence.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008132-better_serialization.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008585-jmx_data_handling.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008593-better_urlclassloader.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008603-jmx_provider_provision.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008611-jmx_annotations.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008611-6_fixup.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008615-jmx_internal_api_robustness.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008623-mbeanserver_handling.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008744-6741606_rework.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8008982-jmx_interface_changes.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8009004-rmi_connection_improvement.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8009013-t2k_glyphs.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8009034-jmx_notification_improvement.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8009038-jmx_notification_support_improvement.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8009067-improve_key_storing.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8009235-improve_tsa_data_handling.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6888167-medialib_memory_leaks.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8011243-improve_imaginglib.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8011248-better_component_rasters.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8011253-better_short_component_rasters.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8011257-better_byte_component_rasters.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8011557-improve_reflection.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8012421-better_positioning.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8012438-better_image_validation.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8012597-better_image_channel_validation.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8012601-better_layout_validation.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8014281-better_xml_signature_checking.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/diamond_fix.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/handle_npe.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/javac_issue.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/7158805-nested_subroutine_rewriting.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8001330-checking_order_improvement.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8000642-better_transportation_handling.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6786028-wcag_bold_tags.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6786682-wcag_lang.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6802694-no_deprecated.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6786690-wcag_dl.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6786688-wcag_table.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6961178-doclet_xml.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6851834-restructure.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/6851834-handle_renames.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/7006270-regressions.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8012375-javadoc_framing.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8015997-more_javadoc_framing.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/langtools_merge-01.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/langtools_merge-02.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/langtools_generics.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/langtools_merge-03.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/security/20130618/8009071-improve_shape_handling.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/applet_hole.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/7032388-work_without_cmov_instruction.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/8004341-jck_dialog_failure.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/8004341-jck_dialog_failure-02.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/openjdk/7197906-handle_32_bit_shifts.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/icedtea/jpegclasses.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/alsa-disable.patch ===> Applying extra patch /usr/ports/java/openjdk6/files/test_gamma-disable.patch ===> Applying FreeBSD patches for openjdk6-b27_5 ===> openjdk6-b27_5 depends on file: /usr/local/bin/zip - found ===> openjdk6-b27_5 depends on file: /usr/local/bin/unzip - found ===> openjdk6-b27_5 depends on file: /usr/local/include/cups/cups.h - found ===> openjdk6-b27_5 depends on executable: gmake - found ===> openjdk6-b27_5 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found ===> openjdk6-b27_5 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found ===> openjdk6-b27_5 depends on file: /usr/local/libdata/pkgconfig/xi.pc - found ===> openjdk6-b27_5 depends on file: /usr/local/libdata/pkgconfig/xt.pc - found ===> openjdk6-b27_5 depends on file: /usr/local/libdata/pkgconfig/xtst.pc - found ===> openjdk6-b27_5 depends on file: /usr/local/libdata/pkgconfig/xpm.pc - found ====> openjdk6-b27_5 depends on shared library: libXm.so.4: - found ===> openjdk6-b27_5 depends on shared library: freetype - found ===> Configuring for openjdk6-b27_5 ===> Building for openjdk6-b27_5 Control bsd amd64 1.6.0_32 all build started: 13-07-25 15:02 gmake[1]: Entering directory `/usr/ports/java/openjdk6/work/jdk/make' gmake[2]: Entering directory `/usr/ports/java/openjdk6/work/jdk/make/tools/freetypecheck' freetypecheck.c:35:14: warning: unused parameter 'argc' [-Wunused-parameter] int main(int argc, char** argv) { ^ freetypecheck.c:35:27: warning: unused parameter 'argv' [-Wunused-parameter] int main(int argc, char** argv) { ^ 2 warnings generated. gmake[2]: Leaving directory `/usr/ports/java/openjdk6/work/jdk/make/tools/freetypecheck' gmake[1]: Leaving directory `/usr/ports/java/openjdk6/work/jdk/make' Build Machine Information: build machine = z29.zvq.me Build Directory Structure: CWD = /usr/ports/java/openjdk6/work TOPDIR = . LANGTOOLS_TOPDIR = ./langtools JAXP_TOPDIR = ./jaxp JAXWS_TOPDIR = ./jaxws CORBA_TOPDIR = ./corba HOTSPOT_TOPDIR = ./hotspot JDK_TOPDIR = ./jdk Build Directives: BUILD_LANGTOOLS = true BUILD_JAXP = true BUILD_JAXWS = true BUILD_CORBA = true BUILD_HOTSPOT = true BUILD_JDK = true DEBUG_CLASSFILES = DEBUG_BINARIES = Hotspot Settings: \n HOTSPOT_BUILD_JOBS = 8 \n HOTSPOT_OUTPUTDIR = /usr/ports/java/openjdk6/work/build/bsd-amd64/hotspot/outputdir \n HOTSPOT_EXPORT_PATH = /usr/ports/java/openjdk6/work/build/bsd-amd64/hotspot/import \n \n \nBootstrap Settings:\n BOOTDIR = /usr/local/openjdk6\n ALT_BOOTDIR = /usr/local/openjdk6\n BOOT_VER = 1.6 [requires at least 1.6]\n OUTPUTDIR = /usr/ports/java/openjdk6/work/build/bsd-amd64\n ALT_OUTPUTDIR = /usr/ports/java/openjdk6/work/build/bsd-amd64\n ABS_OUTPUTDIR = /usr/ports/java/openjdk6/work/build/bsd-amd64\n \nBuild Tool Settings:\n SLASH_JAVA = /NOT-SET\n ALT_SLASH_JAVA = \n VARIANT = OPT\n JDK_DEVTOOLS_DIR = /NOT-SET/devtools\n ALT_JDK_DEVTOOLS_DIR = \n ANT_HOME = /usr/ports/java/openjdk6/work/apache-ant-1.8.4\n UNIXCOMMAND_PATH = /bin/\n ALT_UNIXCOMMAND_PATH = \n COMPILER_PATH = /usr/bin/\n ALT_COMPILER_PATH = \n DEVTOOLS_PATH = /usr/local/bin/\n ALT_DEVTOOLS_PATH = \n MOTIF_DIR = /usr\n ALT_MOTIF_DIR = \n MOTIF_REQUIRED = false\n COMPILER_NAME = GCC\n COMPILER_VERSION = \n CC_VER = 4.2 [requires at least 3.2]\n ZIP_VER = 3.0 [requires at least 2.2]\n UNZIP_VER = 6.00 [requires at least 5.12]\n ANT_VER = 1.8 [requires at least 1.6.3]\n TEMPDIR = /usr/ports/java/openjdk6/work/build/bsd-amd64/tmp\n \nBuild Directives:\n OPENJDK = true\n USE_HOTSPOT_INTERPRETER_MODE = \n PEDANTIC = \n DEV_ONLY = \n NO_DOCS = true\n NO_IMAGES = \n TOOLS_ONLY = \n INSANE = \n COMPILE_APPROACH = parallel\n PARALLEL_COMPILE_JOBS = 8\n ALT_PARALLEL_COMPILE_JOBS = 8\n FASTDEBUG = \n COMPILER_WARNINGS_FATAL = false\n COMPILER_WARNING_LEVEL = \n INCREMENTAL_BUILD = false\n CC_HIGHEST_OPT = -O3 \n CC_HIGHER_OPT = -O3 \n CC_LOWER_OPT = -O2 \n CXXFLAGS = -O2 -fPIC -DCC_NOEX -W -Wall -Wno-unused -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN \n CFLAGS = -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -fno-omit-frame-pointer -D_LITTLE_ENDIAN \n BOOT_JAVA_CMD = /usr/local/openjdk6/bin/java -Xmx896m -Xms128m\n BOOT_JAVAC_CMD = /usr/local/openjdk6/bin/javac -J-XX:ThreadStackSize=1536 -J-Xmx896m -J-Xms128m -encoding ascii -source 5 -target 5 -XDignore.symbol.file=true\n BOOT_JAR_CMD = /usr/local/openjdk6/bin/jar\n BOOT_JARSIGNER_CMD = /usr/local/openjdk6/bin/jarsigner\n JAVAC_CMD = /usr/local/openjdk6/bin/javac -J-XX:ThreadStackSize=1536 -J-Xmx896m -J-Xms128m -source 1.5 -target 5 -encoding ascii -Xbootclasspath:/usr/ports/java/openjdk6/work/build/bsd-amd64/classes \n JAVAH_CMD = /usr/local/openjdk6/bin/javah -bootclasspath /usr/ports/java/openjdk6/work/build/bsd-amd64/classes\n JAVADOC_CMD = /usr/local/openjdk6/bin/javadoc -J-Xmx896m -J-Xms128m\n \nBuild Platform Settings:\n USER = root\n PLATFORM = bsd\n ARCH = amd64\n LIBARCH = amd64\n ARCH_FAMILY = amd64\n ARCH_DATA_MODEL = 64\n ARCHPROP = amd64\n OS_VERSION = 10.0-CURRENT [requires at least 6.0]\n OS_NAME = freebsd\n MB_OF_MEMORY = 24544\n \nGNU Make Settings:\n MAKE = gmake\n MAKE_VER = 3.82 [requires at least 3.78]\n MAKECMDGOALS = sanity\n MAKEFLAGS = w\n SHELL = /bin/sh\n \nTarget Build Versions:\n JDK_VERSION = 1.6.0_32\n MILESTONE = fcs\n RELEASE = 1.6.0_32\n FULL_VERSION = 1.6.0_32-b27\n BUILD_NUMBER = b27\n \nExternal File/Binary Locations:\n USRJDKINSTANCES_PATH = /usr/local\n BUILD_JDK_IMPORT_PATH = /NOT-SET/re/openjdk/6/promoted/latest/binaries\n ALT_BUILD_JDK_IMPORT_PATH = \n JDK_IMPORT_PATH = /usr/local/openjdk6\n ALT_JDK_IMPORT_PATH = /usr/local/openjdk6\n LANGTOOLS_DIST = \n ALT_LANGTOOLS_DIST = /usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/dist\n CORBA_DIST = \n ALT_CORBA_DIST = /usr/ports/java/openjdk6/work/build/bsd-amd64/corba/dist\n JAXP_DIST = \n ALT_JAXP_DIST = /usr/ports/java/openjdk6/work/build/bsd-amd64/jaxp/dist\n JAXWS_DIST = \n ALT_JAXWS_DIST = /usr/ports/java/openjdk6/work/build/bsd-amd64/jaxws/dist\n HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR\n ALT_HOTSPOT_DOCS_IMPORT_PATH = \n HOTSPOT_IMPORT_PATH = /usr/ports/java/openjdk6/work/build/bsd-amd64/hotspot/import\n ALT_HOTSPOT_IMPORT_PATH = /usr/ports/java/openjdk6/work/build/bsd-amd64/hotspot/import\n HOTSPOT_SERVER_PATH = /usr/ports/java/openjdk6/work/build/bsd-amd64/hotspot/import/jre/lib/amd64/server\n ALT_HOTSPOT_SERVER_PATH = \n CACERTS_FILE = /usr/ports/java/openjdk6/files/cacerts\n ALT_CACERTS_FILE = /usr/ports/java/openjdk6/files/cacerts\n CUPS_HEADERS_PATH = /usr/local/include\n ALT_CUPS_HEADERS_PATH = /usr/local/include\n \nOpenJDK-specific settings:\n FREETYPE_HEADERS_PATH = /usr/local/include\n ALT_FREETYPE_HEADERS_PATH = /usr/local/include\n FREETYPE_LIB_PATH = /usr/local/lib\n ALT_FREETYPE_LIB_PATH = /usr/local/lib\n X11_PATH = /usr/local\n ALT_X11_PATH = /usr/local\n PLUG_LIBRARY_NAMES = \n \nPrevious JDK Settings:\n PREVIOUS_RELEASE_PATH = /NOT-SET/re/jdk/1.6.0/archive/fcs/bundles/bsd-amd64\n ALT_PREVIOUS_RELEASE_PATH = \n PREVIOUS_JDK_VERSION = 1.6.0\n ALT_PREVIOUS_JDK_VERSION = \n PREVIOUS_JDK_FILE = jdk-6-bsd-amd64.tar.gz\n ALT_PREVIOUS_JDK_FILE = \n PREVIOUS_JRE_FILE = jre-6-bsd-amd64.tar.gz\n ALT_PREVIOUS_JRE_FILE = \n PREVIOUS_RELEASE_IMAGE = \n ALT_PREVIOUS_RELEASE_IMAGE = \n WARNING: Your build environment has the variable NO_DOCS\n defined. This will result in a development-only\n build of the JDK, lacking the documentation\n build.\n Sanity check passed. Control bsd amd64 1.6.0_32 all_product_build build started: 13-07-25 15:02 Control bsd amd64 1.6.0_32 build_product_image build started: 13-07-25 15:02 gmake \ SKIP_FASTDEBUG_BUILD=true \ SKIP_DEBUG_BUILD=true \ \ generic_build_repo_series gmake[1]: Entering directory `/usr/ports/java/openjdk6/work' /bin/mkdir -p ./build/bsd-amd64 /bin/mkdir -p ./build/bsd-amd64/j2sdk-image /bin/mkdir -p /usr/ports/java/openjdk6/work/build/bsd-amd64/langtools (cd ./langtools/make && \ gmake JDK_TOPDIR=/usr/ports/java/openjdk6/work/jdk JDK_MAKE_SHARED_DIR=/usr/ports/java/openjdk6/work/jdk/make/common/shared EXTERNALSANITYCONTROL=true TARGET_CLASS_VERSION=5 MILESTONE=fcs BUILD_NUMBER=b27 JDK_BUILD_NUMBER=b27 FULL_VERSION=1.6.0_32-b27 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.6.0_32 JDK_MKTG_VERSION=6u32 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=6 JDK_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_JDK_UPDATE_VERSION=320 COOKED_BUILD_NUMBER=27 ANT_HOME="/usr/ports/java/openjdk6/work/apache-ant-1.8.4" ALT_OUTPUTDIR=/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools ALT_BOOTDIR=/usr/local/openjdk6 all) gmake[2]: Entering directory `/usr/ports/java/openjdk6/work/langtools/make' JAVA_HOME=/usr/local/openjdk6 ANT_OPTS=-Djava.io.tmpdir='/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/ant-tmp' /usr/ports/java/openjdk6/work/apache-ant-1.8.4/bin/ant -diagnostics > /usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/ant-diagnostics.log ; \ JAVA_HOME=/usr/local/openjdk6 ANT_OPTS=-Djava.io.tmpdir='/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/ant-tmp' /usr/ports/java/openjdk6/work/apache-ant-1.8.4/bin/ant -version >> /usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/ant-diagnostics.log JAVA_HOME=/usr/local/openjdk6 ANT_OPTS=-Djava.io.tmpdir='/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build/ant-tmp' /usr/ports/java/openjdk6/work/apache-ant-1.8.4/bin/ant -Djdk.version=1.6.0_32 -Dfull.version='1.6.0_32-b27' -Drelease=1.6.0_32 -Dbuild.number=b27 -Djavac.target=5 -Dboot.java.home=/usr/local/openjdk6 -Dbuild.dir=/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/build -Ddist.dir=/usr/ports/java/openjdk6/work/build/bsd-amd64/langtools/dist build Buildfile: /usr/ports/java/openjdk6/work/langtools/make/build.xml gmake[2]: *** [build] Segmentation fault (core dumped) gmake[2]: Leaving directory `/usr/ports/java/openjdk6/work/langtools/make' gmake[1]: *** [langtools-build] Error 2 gmake[1]: Leaving directory `/usr/ports/java/openjdk6/work' gmake: *** [build_product_image] Error 2 ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/java/openjdk6 *** Error code 1 Stop. make: stopped in /usr/ports/java/openjdk6 From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 09:37:19 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 23ED07D6; Thu, 25 Jul 2013 09:37:19 +0000 (UTC) (envelope-from dms@mircat.net) Received: from mircat.net (mircat.net [81.9.105.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 711E72B61; Thu, 25 Jul 2013 09:37:18 +0000 (UTC) Received: from [192.168.0.145] (port=55236 helo=dooku.mircat.net) by mircat.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) (envelope-from ) id 1V2Hbg-000K87-MI; Thu, 25 Jul 2013 13:13:08 +0400 Message-ID: <51F0EC1E.90100@samersoff.net> Date: Thu, 25 Jul 2013 13:13:02 +0400 From: Dmitry Samersoff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: [Call For Help] Clang + OpenJDK + head + amd64 == cocktail of death (for clusters) References: <20130725083917.GH41432@ithaqua.etoilebsd.net> In-Reply-To: <20130725083917.GH41432@ithaqua.etoilebsd.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: dms@samersoff.net X-Mailman-Approved-At: Thu, 25 Jul 2013 11:51:54 +0000 Cc: ports@FreeBSD.org, java@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 09:37:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Baptiste, If I understand you correct, hotspot crashes because of out of memory or some other resource constraint? Could you send me whole hs_err_.log file (or better couple of it)? - -Dmitry On 2013-07-25 12:39, Baptiste Daroussin wrote: > Hi all, > > It's been a while since we are experiencing major problem on the > package buidling cluster: it dies when building package for head > amd64. (the buidling jail being the snapshort from July 7th iirc.) > > After some investigation we discover that blacklisting openjdk6 > allows the building process to go to completion again. > > But not providing java packages is not a good solution. > > We have managed to "fix" the build by limiting the allowed memory > usage on each building jail to 8G, the result is a huge load of > java packages just fail to build because it eats all the memory and > then segfault, but at least they do not kill the box again. Have a > look at the pkg-fallout mailing list you should be able to see lots > of java port failed because of that. > > It seems to happen only on head amd64, so far we think it is only > happening when jdk is built with clang. > > I have no time, neither skill to investigate that, so please if you > are interested in having java packages available have a look at it, > fix the problem if any may that be clang, openjdk, the ports tree > framework for java building, or anything related. Otherwise I'll > have to mark all failing packages as broken on head amd64 in the > portstree :( > > regards, Bapt > - -- Dmitry Samersoff Saint Petersburg, Russia, http://devnull.samersoff.net * There will come soft rains ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR8OweAAoJEHEy08c4gIABwsAH/jdIMktpssHgyhaE8GH2uEme /8S5n8tXd2mCRszKsPde0FPwBsz1XfyeM/6sD1o6vBeLMCEwCKxyUHyRxL3cwZ0E XYosan6id1v8vTGzHid3qGxJ68MHsGNbTO4uJ2mSh0sO39frofiL11kVyzMel31/ NhUElw/aZcWWVSCM3rVXx+QuzzF9tHn2WhYG9AQLYJcMuqerjvgniIYKB2C/TKo8 eM0qxhsR2JfI08TIruDmo/2AnDQICMI9oObdO1ewvuqOOP1ydndVMUj0ZR8NQgEx eUYIcoWhpo6o2F9j1QXdjNIOfRod02MbCrtAimAXXpXlwgFMrVujowBB5P01ErY= =svP7 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 10:13:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4E223AA2; Thu, 25 Jul 2013 10:13:20 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ABA9A2DA1; Thu, 25 Jul 2013 10:13:19 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id r6P9p2b2012860; Thu, 25 Jul 2013 11:51:02 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id r6P9p2UC012857; Thu, 25 Jul 2013 11:51:02 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 25 Jul 2013 11:51:02 +0200 (CEST) From: Wojciech Puchar To: Super Bisquit Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 25 Jul 2013 11:51:02 +0200 (CEST) X-Mailman-Approved-At: Thu, 25 Jul 2013 11:52:08 +0000 Cc: FreeBSD Hackers , Adrian Chadd , freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 10:13:20 -0000 > improved with a higher kern.hz rating. Unless the future holds an emu20k2, > there will be RAM used from the motherboard. > 1. I will need a real-time or a faster kernel- hence the high rate wanted- > because the devices to be built will be used in an active environment: art, > music, audio control. > 2. Any system with limited memory and a low CPU hertz rate benefits from > the higher kern.hz setting. rather opposite. more kern.hz=more interrupts. > 3. Why not? If it works for PowerPC, SPARC64, AMD64, and i386 then it may > work for other architectures. > 4. Some applications may be ran from within a jail. > > > On Wed, Jul 24, 2013 at 8:16 PM, Adrian Chadd wrote: > >> Well, why is it reducing latency? That's the thing you should investigate. >> >> Is it because processes aren't getting enough time? or too much time? >> Or the audio device isn't getting enough time to run? etc. >> >> >> >> -adrian >> >> On 24 July 2013 15:35, Super Bisquit wrote: >>> >> http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html >>> >>> This is the thread that I was referring to earlier. Since the patch is >> for >>> 2009, what are the chances it would work with 10.x or 9.x? >>> >>> On PowerPC machines with a low MHz rate- or any machine with a CPU rate >> of >>> 800 MHz or less- increasing the kern.hz improves performance and cuts >> down >>> on latency. I am building audio applications and suites that are used in >>> different projects. A G3 based machine should be able to run a kernel >> with >>> kern.hz=5000 with no problem. Unfortunately, this cannot be done. >>> >>> @PowerPC: some of you may find that performance does increase at a higher >>> kern.hz rate. >>> >>> @Hackers & Current: What's the chance that the default rate limit can be >>> raised to 5k? >>> _______________________________________________ >>> freebsd-ppc@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc >>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 15:15:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4DC202D3 for ; Thu, 25 Jul 2013 15:15:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 234C82E23 for ; Thu, 25 Jul 2013 15:15:37 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r6PFFRPY006249 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 25 Jul 2013 08:15:30 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51F14109.4070007@freebsd.org> Date: Thu, 25 Jul 2013 23:15:21 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current Subject: two Xen failures Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 15:15:38 -0000 I have a VPS on RootBSD (freebsd developer's discount). They use Xen on their vps servers. yesterday I tried to upgrade my server to -current and came across two interesting failure modes. 1/ I somehow wrote a kernel that made the loader crash when loading it (not running it). this was Not Good (TM) because the loader loads the kernel BEFORE it gets to the prompt so there was no way for me to type in the name of an alternate kernel. (actually I may have been ab;e to do it from the stage 2 loader if I could remember the syntax and hte stage 2 lader could load ELF binaries (I remember it could only do a.out .. is that still true?)) It's distressing that the loader can be made to crash from loading a misformed kernel. I still have it if anyone is still interested in pulling it apart to see what is weird about it. 2/ it is impossible for me to make a -current kernel that can mount root. it finds the drive, then it tastes it to see if there is a lable it wants, fails and then I get an infinite (apparently) set of "waiting for root device : usbus0" (or similar)messages. a kernel compiled from -current in Jan 1 this year boots just fine but I hav enot tried bisecting further (it is after all my MAIN server) I have tried a minimal kernel, a GENERIC kernel, and a XENHVM kernel. All behave the same. If I have some time I will try bisect further but I plan on asking RootBSD if htey can give me a different VPS to try fdo it on as I don't want to screw up my server.. (again). Julian From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 15:33:23 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EC290AF4; Thu, 25 Jul 2013 15:33:22 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2A0892F6A; Thu, 25 Jul 2013 15:33:22 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id y10so1124203wgg.4 for ; Thu, 25 Jul 2013 08:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QDkvwOUhHrrYfP6b9JPiFZChn8yYzEBo0AFscTo7yHg=; b=jpGEXNFnoNJjXjhPFlRs1GnM49XulvKWW936+auURSZ3UIne2zjR20u8585Y9YugFh U3vE255i2dVKVbPB3mOctY9dLEhlaB4Utp/j7KkcF0A/6ekPKHNZKE40nfKtDJBEGSqY 4h0LtaMjtZGuiX4Wbd3OBpdfQHYDtbXWn458sLrLZ4YxjLS5DDHlPrI/6/qabBa5RI4K 4ZxqT8HFoXh+TAA7kt2r4QGoOUlIZc8M4RlzeEDccShHVYlzTRVz+2AHW7Zji3eQrHOr BpYD9efomOC+xp8e6F3HfRiS9V0xW5QCxI3C5GafKJlf1/NRbkdYD6HLmAnnxxjRoeqf 4qSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QDkvwOUhHrrYfP6b9JPiFZChn8yYzEBo0AFscTo7yHg=; b=OvgCLH/GvYfpE6du9epBxrEW52fp/7oyw/nRXv7h6k6dqPXImN0k3p04uGrwvFESxd 1e7YZSut+ZQL4E4kH3ls6kg6GU5Z7nqa8dnTayUk3BLX71kVdeoF5NqY09TJ/x+bglWU 2xdTg6yV9L0vsi13OOTeXEqobVJguXz5P2nZb02Avwph95iSshIgsjdEi+se2cutjRBd MjSHFVKWbSF18GL/s5pZ8aXx/l0Em7u9CXHLIArTp5JLooHRt+HtnImhZ3T2Kl+6j9nz zpkOPRGYfFLswyqDEG5wQ2DCgYgU6u0Z1a16TS20KFrZWrELrmHRn2NrBJQkLI5w2mP/ zdEQ== X-Received: by 10.180.83.68 with SMTP id o4mr2615219wiy.5.1374766400316; Thu, 25 Jul 2013 08:33:20 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id nb12sm2607301wic.3.2013.07.25.08.33.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jul 2013 08:33:19 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 25 Jul 2013 17:33:17 +0200 From: Baptiste Daroussin To: Dmitry Samersoff Subject: Re: [Call For Help] Clang + OpenJDK + head + amd64 == cocktail of death (for clusters) Message-ID: <20130725153317.GN61207@ithaqua.etoilebsd.net> References: <20130725083917.GH41432@ithaqua.etoilebsd.net> <51F0EC1E.90100@samersoff.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5FetH82qe0Z6y/zI" Content-Disposition: inline In-Reply-To: <51F0EC1E.90100@samersoff.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@FreeBSD.org, java@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 15:33:23 -0000 --5FetH82qe0Z6y/zI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2013 at 01:13:02PM +0400, Dmitry Samersoff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Baptiste, >=20 > If I understand you correct, hotspot crashes because of out of memory > or some other resource constraint? >=20 > Could you send me whole hs_err_.log file (or better couple of it)? >=20 > - -Dmitry >=20 FYI Dmitry fixed the problem thank you very much ! With the following patch: http://www.andric.com/freebsd/ports/java__openjdk6-deoptimization-crash.diff The bug is known upstream as:=20 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D6636110 I have committed in the ports tree as it is necessary to finish properly building packages. regards, Bapt --5FetH82qe0Z6y/zI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHxRT0ACgkQ8kTtMUmk6EwnsACdFyDNiXdxDWUEP4ik76j88ZWW 4ZcAoLUJokjX0Duz5JjhmMPoLaWCbPIV =3cFz -----END PGP SIGNATURE----- --5FetH82qe0Z6y/zI-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 15:39:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 50021F2C; Thu, 25 Jul 2013 15:39:38 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2499B2FCF; Thu, 25 Jul 2013 15:39:37 +0000 (UTC) Received: from glenbarber.us (unknown [IPv6:2001:470:8:120e:1:1:c57c:729]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 6E9FF8DCC; Thu, 25 Jul 2013 15:39:36 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 6E9FF8DCC Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 25 Jul 2013 11:39:34 -0400 From: Glen Barber To: Johannes Totz Subject: Re: r253070 and "disappearing" zpool Message-ID: <20130725153934.GA2075@glenbarber.us> References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> <20130722203853.GB1400@garage.freebsd.pl> <51EFBEBF.601@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 15:39:38 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2013 at 04:33:58PM +0100, Johannes Totz wrote: > On 24/07/2013 12:47, Andriy Gapon wrote: > >on 22/07/2013 23:38 Pawel Jakub Dawidek said the following: > >>On Mon, Jul 22, 2013 at 10:29:40AM +0300, Andriy Gapon wrote: > >>>I think that this setup (on ZFS level) is quite untypical, although not > >>>impossible on FreeBSD (and perhaps only FreeBSD). > >>>It's untypical because you have separate boot pool (where loader, load= er.conf > >>>and kernel are taken from) and root pool (where "/" is mounted from). > >> > >>As I said elsewhere, it is pretty typical when full disk encryption is > >>used. > > > >I am judging by the number of reports / amount of feedback so far. >=20 > I'm using a similar configuration too, where I have a USB stick with > unencrypted kernel and /boot bits which load a GELI keyfile (from > its own pool zboot), and then the rest of the system starts up from > the fully encrypted HDD (from another pool zsystem, so boot and > rootfs are on different pools). >=20 > I'm not sure I understand the problem though. What exactly "broke" > after your commit? The pool that contains the bits that would > normally go to /boot is not imported automatically, but the rest is > working (ie. /boot symlink pointing to nowhere)? Or does booting > somehow fail? >=20 "/boot" disappears and becomes a broken symlink. Glen --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR8Ua2AAoJEFJPDDeguUajZLAH/3W+Z8J31TL8M5hG7lj0cPwB OsT/lehsktd/rD4TYgefUCxQiVBikIIElXLb4+jorW1v/Ml7TzigzMeoy5+PwfoF iewRyniyYcmMapGzB9g59UcJ+KD52WdILUyiM0f2pxB/ZKPIhnYcz83iRyqhxJQm v57DLisjhfOFRCdimXKy2jUdet9yv+fwe2y8rddr+NFSpLcaCzG/ewoQfrBPQQfP UqLDGgV0/Bvu9kqD/SeKNe9u0W/6yZHA4OmvKlkvn8778ODu2CbqaB2upnuSVJZe rHdPc9bY2U3+cGXULV6HTrU0twab4+UG6qzGJTD4X4q8K2Mg4ehX5wUmV0htMas= =HngW -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 16:11:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BE406CF8; Thu, 25 Jul 2013 16:11:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04C32217E; Thu, 25 Jul 2013 16:11:38 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b13so1846798wgh.19 for ; Thu, 25 Jul 2013 09:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=giv0WWIGpI3VrGnbHPt7xc3L6V+CXUsSA5jYbeAPgZY=; b=EcvK1suJsy8bt/l9zJ+y0GrDG4zuukGuxdOqOZw2SkiDjGKH+vaneXYK5SJ5eGZ5X8 YhGoY0Tqn01NIeFbYriDBAYdYHrmQ/wC8X6Pn8rIy/72J/ho/YPUnL7CtNKVP2oYvQin oR1F3f3TCkk+uldjlmf9tmHVYd7zfMliqxzSlubruBXGAm6pVHAVha2FP+gXiVks38BD a/qsv9IAZQ+SeUnBnHLfm1xqlGiBRgxOaNnhu8nGWO3Xxx7/1vRQ9WFQYuXJX2wq+9j8 LaDMlcFnplZmx4hae25jiMZD2x+xLQWUMLrK5vltU7I6oOl/wTpVuOtbfbEDMCG0jQE1 eKWg== MIME-Version: 1.0 X-Received: by 10.194.92.6 with SMTP id ci6mr7227233wjb.79.1374768697270; Thu, 25 Jul 2013 09:11:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Thu, 25 Jul 2013 09:11:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jul 2013 09:11:37 -0700 X-Google-Sender-Auth: -vAecfRGuNGwy-4rjpi6FHKbS4E Message-ID: Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. From: Adrian Chadd To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 Cc: Super Bisquit , freebsd-current , FreeBSD Hackers , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 16:11:39 -0000 On 25 July 2013 02:51, Wojciech Puchar wrote: >> improved with a higher kern.hz rating. Unless the future holds an emu20k2, >> there will be RAM used from the motherboard. >> 1. I will need a real-time or a faster kernel- hence the high rate wanted- >> because the devices to be built will be used in an active environment: >> art, >> music, audio control. >> 2. Any system with limited memory and a low CPU hertz rate benefits from >> the higher kern.hz setting. > rather opposite. more kern.hz=more interrupts. Right. More hz == more interrupts and less ability for a CPU-bound process to chew all the CPU. So is it a scheduling issue, where you have multiple CPU bound userland processes that aren't being fair and consuming all the CPU? Is it that your device driver(s) aren't interrupting correctly, relying on the hz tick to make up the slack, etc. Is it a busted halt loop, which is being papered over with hz ticks? Have you tried -10 on that kit, with the more aggressive clock/timer code that won't interrupt unless it needs to? Has that changed things? -adrian From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 16:53:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 408FAC58; Thu, 25 Jul 2013 16:53:46 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92CEC23E2; Thu, 25 Jul 2013 16:53:44 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.89,744,1367971200"; d="scan'208";a="7101980" Received: from lonpex01cl01.citrite.net ([10.30.203.101]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 25 Jul 2013 16:53:36 +0000 Received: from Roger-2.local (10.30.203.1) by LONPEX01CL01.citrite.net (10.30.203.101) with Microsoft SMTP Server id 14.2.342.4; Thu, 25 Jul 2013 17:53:35 +0100 Message-ID: <51F15813.60406@citrix.com> Date: Thu, 25 Jul 2013 18:53:39 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Julian Elischer Subject: Re: two Xen failures References: <51F14109.4070007@freebsd.org> In-Reply-To: <51F14109.4070007@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.30.203.1] Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 16:53:46 -0000 On 25/07/13 17:15, Julian Elischer wrote: > I have a VPS on RootBSD (freebsd developer's discount). > They use Xen on their vps servers. > > yesterday I tried to upgrade my server to -current and came across two > interesting failure modes. > > 1/ I somehow wrote a kernel that made the loader crash when loading it > (not running it). > this was Not Good (TM) because the loader loads the kernel BEFORE it > gets to the prompt so there was no way for me to type in the name of an > alternate kernel. (actually I may have been ab;e to do it from the stage > 2 loader if I could remember the syntax and hte stage 2 lader could load > ELF binaries (I remember it could only do a.out .. is that still true?)) > > It's distressing that the loader can be made to crash from loading a > misformed kernel. > I still have it if anyone is still interested in pulling it apart to see > what is weird about it. > > 2/ it is impossible for me to make a -current kernel that can mount root. > it finds the drive, then it tastes it to see if there is a lable it > wants, fails and then I get an infinite (apparently) set of "waiting for > root device : usbus0" > (or similar)messages. I've just tested a current XENHVM amd64 kernel and it seems to work just fine, tip commit is: commit 0f5a145fe0fcb6e9907f1458db21e478f874b760 Author: glebius Date: Tue Jul 23 10:25:34 2013 +0000 Add constant for PPP-Max-PayLoad tag. Submitted by: Dmitry Luhtionov Justin committed a change to blkfront not long ago that changed the translation of "xbd" devices to "ada" instead of "ad", you should rename your "ad" devices in /etc/fstab to "ada". Your problem however doesn't seem to be related to that change, or you will at least get a prompt asking for your root device instead of being stuck in an infinite wait. I guess there's no way you can execute "xenstore-ls -fp" on the Dom0 in order to see the state of the PV devices? Here is the full verbose bootlog: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=02 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=01 base=0000000000100000 len=000000000f6ff000 SMAP type=02 base=000000000f7ff000 len=0000000000001000 SMAP type=02 base=00000000fc000000 len=0000000004000000 Table 'FACP' at 0xfc009a20 Table 'APIC' at 0xfc009b20 APIC: Found table at 0xfc009b20 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 1: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 2: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 6 ACPI ID 3: enabled SMP: Added CPU 6 (AP) MADT: Found CPU APIC ID 8 ACPI ID 4: enabled SMP: Added CPU 8 (AP) MADT: Found CPU APIC ID 10 ACPI ID 5: enabled SMP: Added CPU 10 (AP) MADT: Found CPU APIC ID 12 ACPI ID 6: enabled SMP: Added CPU 12 (AP) MADT: Found CPU APIC ID 14 ACPI ID 7: disabled MADT: Found CPU APIC ID 16 ACPI ID 8: disabled MADT: Found CPU APIC ID 18 ACPI ID 9: disabled MADT: Found CPU APIC ID 20 ACPI ID 10: disabled MADT: Found CPU APIC ID 22 ACPI ID 11: disabled MADT: Found CPU APIC ID 24 ACPI ID 12: disabled MADT: Found CPU APIC ID 26 ACPI ID 13: disabled MADT: Found CPU APIC ID 28 ACPI ID 14: disabled MADT: Found CPU APIC ID 30 ACPI ID 15: disabled MADT: Found CPU APIC ID 32 ACPI ID 16: disabled MADT: Found CPU APIC ID 34 ACPI ID 17: disabled MADT: Found CPU APIC ID 36 ACPI ID 18: disabled MADT: Found CPU APIC ID 38 ACPI ID 19: disabled MADT: Found CPU APIC ID 40 ACPI ID 20: disabled MADT: Found CPU APIC ID 42 ACPI ID 21: disabled MADT: Found CPU APIC ID 44 ACPI ID 22: disabled MADT: Found CPU APIC ID 46 ACPI ID 23: disabled MADT: Found CPU APIC ID 48 ACPI ID 24: disabled MADT: Found CPU APIC ID 50 ACPI ID 25: disabled MADT: Found CPU APIC ID 52 ACPI ID 26: disabled MADT: Found CPU APIC ID 54 ACPI ID 27: disabled MADT: Found CPU APIC ID 56 ACPI ID 28: disabled MADT: Found CPU APIC ID 58 ACPI ID 29: disabled MADT: Found CPU APIC ID 60 ACPI ID 30: disabled MADT: Found CPU APIC ID 62 ACPI ID 31: disabled MADT: Found CPU APIC ID 64 ACPI ID 32: disabled MADT: Found CPU APIC ID 66 ACPI ID 33: disabled MADT: Found CPU APIC ID 68 ACPI ID 34: disabled MADT: Found CPU APIC ID 70 ACPI ID 35: disabled MADT: Found CPU APIC ID 72 ACPI ID 36: disabled MADT: Found CPU APIC ID 74 ACPI ID 37: disabled MADT: Found CPU APIC ID 76 ACPI ID 38: disabled MADT: Found CPU APIC ID 78 ACPI ID 39: disabled MADT: Found CPU APIC ID 80 ACPI ID 40: disabled MADT: Found CPU APIC ID 82 ACPI ID 41: disabled MADT: Found CPU APIC ID 84 ACPI ID 42: disabled MADT: Found CPU APIC ID 86 ACPI ID 43: disabled MADT: Found CPU APIC ID 88 ACPI ID 44: disabled MADT: Found CPU APIC ID 90 ACPI ID 45: disabled MADT: Found CPU APIC ID 92 ACPI ID 46: disabled MADT: Found CPU APIC ID 94 ACPI ID 47: disabled MADT: Found CPU APIC ID 96 ACPI ID 48: disabled MADT: Found CPU APIC ID 98 ACPI ID 49: disabled MADT: Found CPU APIC ID 100 ACPI ID 50: disabled MADT: Found CPU APIC ID 102 ACPI ID 51: disabled MADT: Found CPU APIC ID 104 ACPI ID 52: disabled MADT: Found CPU APIC ID 106 ACPI ID 53: disabled MADT: Found CPU APIC ID 108 ACPI ID 54: disabled MADT: Found CPU APIC ID 110 ACPI ID 55: disabled MADT: Found CPU APIC ID 112 ACPI ID 56: disabled MADT: Found CPU APIC ID 114 ACPI ID 57: disabled MADT: Found CPU APIC ID 116 ACPI ID 58: disabled MADT: Found CPU APIC ID 118 ACPI ID 59: disabled MADT: Found CPU APIC ID 120 ACPI ID 60: disabled MADT: Found CPU APIC ID 122 ACPI ID 61: disabled MADT: Found CPU APIC ID 124 ACPI ID 62: disabled MADT: Found CPU APIC ID 126 ACPI ID 63: disabled MADT: Found CPU APIC ID 128 ACPI ID 64: disabled MADT: Found CPU APIC ID 130 ACPI ID 65: disabled MADT: Found CPU APIC ID 132 ACPI ID 66: disabled MADT: Found CPU APIC ID 134 ACPI ID 67: disabled MADT: Found CPU APIC ID 136 ACPI ID 68: disabled MADT: Found CPU APIC ID 138 ACPI ID 69: disabled MADT: Found CPU APIC ID 140 ACPI ID 70: disabled MADT: Found CPU APIC ID 142 ACPI ID 71: disabled MADT: Found CPU APIC ID 144 ACPI ID 72: disabled MADT: Found CPU APIC ID 146 ACPI ID 73: disabled MADT: Found CPU APIC ID 148 ACPI ID 74: disabled MADT: Found CPU APIC ID 150 ACPI ID 75: disabled MADT: Found CPU APIC ID 152 ACPI ID 76: disabled MADT: Found CPU APIC ID 154 ACPI ID 77: disabled MADT: Found CPU APIC ID 156 ACPI ID 78: disabled MADT: Found CPU APIC ID 158 ACPI ID 79: disabled MADT: Found CPU APIC ID 160 ACPI ID 80: disabled MADT: Found CPU APIC ID 162 ACPI ID 81: disabled MADT: Found CPU APIC ID 164 ACPI ID 82: disabled MADT: Found CPU APIC ID 166 ACPI ID 83: disabled MADT: Found CPU APIC ID 168 ACPI ID 84: disabled MADT: Found CPU APIC ID 170 ACPI ID 85: disabled MADT: Found CPU APIC ID 172 ACPI ID 86: disabled MADT: Found CPU APIC ID 174 ACPI ID 87: disabled MADT: Found CPU APIC ID 176 ACPI ID 88: disabled MADT: Found CPU APIC ID 178 ACPI ID 89: disabled MADT: Found CPU APIC ID 180 ACPI ID 90: disabled MADT: Found CPU APIC ID 182 ACPI ID 91: disabled MADT: Found CPU APIC ID 184 ACPI ID 92: disabled MADT: Found CPU APIC ID 186 ACPI ID 93: disabled MADT: Found CPU APIC ID 188 ACPI ID 94: disabled MADT: Found CPU APIC ID 190 ACPI ID 95: disabled MADT: Found CPU APIC ID 192 ACPI ID 96: disabled MADT: Found CPU APIC ID 194 ACPI ID 97: disabled MADT: Found CPU APIC ID 196 ACPI ID 98: disabled MADT: Found CPU APIC ID 198 ACPI ID 99: disabled MADT: Found CPU APIC ID 200 ACPI ID 100: disabled MADT: Found CPU APIC ID 202 ACPI ID 101: disabled MADT: Found CPU APIC ID 204 ACPI ID 102: disabled MADT: Found CPU APIC ID 206 ACPI ID 103: disabled MADT: Found CPU APIC ID 208 ACPI ID 104: disabled MADT: Found CPU APIC ID 210 ACPI ID 105: disabled MADT: Found CPU APIC ID 212 ACPI ID 106: disabled MADT: Found CPU APIC ID 214 ACPI ID 107: disabled MADT: Found CPU APIC ID 216 ACPI ID 108: disabled MADT: Found CPU APIC ID 218 ACPI ID 109: disabled MADT: Found CPU APIC ID 220 ACPI ID 110: disabled MADT: Found CPU APIC ID 222 ACPI ID 111: disabled MADT: Found CPU APIC ID 224 ACPI ID 112: disabled MADT: Found CPU APIC ID 226 ACPI ID 113: disabled MADT: Found CPU APIC ID 228 ACPI ID 114: disabled MADT: Found CPU APIC ID 230 ACPI ID 115: disabled MADT: Found CPU APIC ID 232 ACPI ID 116: disabled MADT: Found CPU APIC ID 234 ACPI ID 117: disabled MADT: Found CPU APIC ID 236 ACPI ID 118: disabled MADT: Found CPU APIC ID 238 ACPI ID 119: disabled MADT: Found CPU APIC ID 240 ACPI ID 120: disabled MADT: Found CPU APIC ID 242 ACPI ID 121: disabled MADT: Found CPU APIC ID 244 ACPI ID 122: disabled MADT: Found CPU APIC ID 246 ACPI ID 123: disabled MADT: Found CPU APIC ID 248 ACPI ID 124: disabled MADT: Found CPU APIC ID 250 ACPI ID 125: disabled MADT: Found CPU APIC ID 252 ACPI ID 126: disabled MADT: Found CPU APIC ID 254 ACPI ID 127: disabled Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #315: Thu Jul 25 17:58:17 CEST 2013 root@:/usr/obj/usr/src/sys/XENHVM amd64 FreeBSD clang version 3.3 (trunk 178860) 20130405 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81964000. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff81964180. Hypervisor: Origin = "XenVMMXenVMM" Calibrating TSC clock ... TSC clock: 3066838465 Hz CPU: Intel(R) Xeon(R) CPU W3550 @ 3.07GHz (3066.84-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 0x6 Model = 0x1a Stepping = 5 Features=0x1783fbff Features2=0x81b82201 AMD Features=0x28100800 AMD Features2=0x1 real memory = 260046848 (248 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000001989000 - 0x000000000f156fff, 226287616 bytes (55246 pages) avail memory = 214065152 (204 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 2 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 8 as a target INTR: Adding local APIC 10 as a target INTR: Adding local APIC 12 as a target FreeBSD/SMP: Multiprocessor System Detected: 7 CPUs FreeBSD/SMP: 1 package(s) x 7 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 cpu4 (AP): APIC ID: 8 cpu5 (AP): APIC ID: 10 cpu6 (AP): APIC ID: 12 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff80003a4000 x86bios: EBDA 0x09f000-0x09ffff at 0xfffffe000009f000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 APIC: CPU 4 has ACPI ID 4 APIC: CPU 5 has ACPI ID 5 APIC: CPU 6 has ACPI ID 6 lapic0: CMCI unmasked random device not loaded; using insecure entropy ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ULE: setup cpu 4 ULE: setup cpu 5 ULE: setup cpu 6 ACPI: RSDP 0xfd900 00024 (v02 Xen) ACPI: XSDT 0xfc00a0f0 00054 (v01 Xen HVM 00000000 HVML 00000000) ACPI: FACP 0xfc009a20 000F4 (v04 Xen HVM 00000000 HVML 00000000) ACPI: DSDT 0xfc0013d0 085CD (v02 Xen HVM 00000000 INTL 20100528) ACPI: FACS 0xfc001390 00040 ACPI: APIC 0xfc009b20 00460 (v02 Xen HVM 00000000 HVML 00000000) ACPI: HPET 0xfc00a000 00038 (v01 Xen HVM 00000000 HVML 00000000) ACPI: WAET 0xfc00a040 00028 (v01 Xen HVM 00000000 HVML 00000000) ACPI: SSDT 0xfc00a070 00031 (v02 Xen HVM 00000000 INTL 20100528) ACPI: SSDT 0xfc00a0b0 00031 (v02 Xen HVM 00000000 INTL 20100528) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 5, irq 5 ioapic0: intpin 5 trigger: level ioapic0: intpin 5 polarity: low MADT: Interrupt override: source 10, irq 10 ioapic0: intpin 10 trigger: level ioapic0: intpin 10 polarity: low MADT: Interrupt override: source 11, irq 11 ioapic0: intpin 11 trigger: level ioapic0: intpin 11 polarity: low MADT: Forcing active-low polarity and level trigger for SCI ioapic0: intpin 9 polarity: low ioapic0: intpin 9 trigger: level ioapic0 irqs 0-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 Event-channel device installed. wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 null: nfslock: pseudo-device random: VESA: INT 0x10 vector 0xc000:0x83f9 VESA: information block 0000 56 45 53 41 00 02 80 83 00 c0 00 00 00 00 40 00 0010 00 02 40 00 00 01 80 83 00 c0 80 83 00 c0 99 83 0020 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 01 01 10 01 11 01 12 01 03 01 13 01 14 01 15 01 0050 05 01 16 01 17 01 18 01 07 01 19 01 1a 01 ff ff 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 15 mode(s) found VESA: v2.0, 4096k memory, flags:0x0, mode table:0xffffff80003ff040 (2000040) VESA: VGABIOS Cirrus extension VESA: VGABIOS Cirrus extension VGABIOS Cirrus extension 1.0 io: kbd: new array size 4 kbd1 at kbdmux0 mem: hptnr: R750/DC7280 controller driver v1.0 hpt27xx: RocketRAID 27xx controller driver v1.1 hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard ACPI: All ACPI Tables successfully acquired ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a0000 (3) failed cpu0: Processor \_SB_.PR00 (ACPI ID 0) -> APIC ID 0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: Processor \_SB_.PR01 (ACPI ID 1) -> APIC ID 1 cpu1: on acpi0 cpu2: Processor \_SB_.PR02 (ACPI ID 2) -> APIC ID 2 cpu2: on acpi0 cpu3: Processor \_SB_.PR03 (ACPI ID 3) -> APIC ID 3 cpu3: on acpi0 cpu4: Processor \_SB_.PR04 (ACPI ID 4) -> APIC ID 4 cpu4: on acpi0 cpu5: Processor \_SB_.PR05 (ACPI ID 5) -> APIC ID 5 cpu5: on acpi0 cpu6: Processor \_SB_.PR06 (ACPI ID 6) -> APIC ID 6 cpu6: on acpi0 ACPI: Processor \_SB_.PR07 (ACPI ID 7) ignored ACPI: Processor \_SB_.PR08 (ACPI ID 8) ignored ACPI: Processor \_SB_.PR09 (ACPI ID 9) ignored ACPI: Processor \_SB_.PR0A (ACPI ID 10) ignored ACPI: Processor \_SB_.PR0B (ACPI ID 11) ignored ACPI: Processor \_SB_.PR0C (ACPI ID 12) ignored ACPI: Processor \_SB_.PR0D (ACPI ID 13) ignored ACPI: Processor \_SB_.PR0E (ACPI ID 14) ignored ACPI: Processor \_SB_.PR0F (ACPI ID 15) ignored ACPI: Processor \_SB_.PR10 (ACPI ID 16) ignored ACPI: Processor \_SB_.PR11 (ACPI ID 17) ignored ACPI: Processor \_SB_.PR12 (ACPI ID 18) ignored ACPI: Processor \_SB_.PR13 (ACPI ID 19) ignored ACPI: Processor \_SB_.PR14 (ACPI ID 20) ignored ACPI: Processor \_SB_.PR15 (ACPI ID 21) ignored ACPI: Processor \_SB_.PR16 (ACPI ID 22) ignored ACPI: Processor \_SB_.PR17 (ACPI ID 23) ignored ACPI: Processor \_SB_.PR18 (ACPI ID 24) ignored ACPI: Processor \_SB_.PR19 (ACPI ID 25) ignored ACPI: Processor \_SB_.PR1A (ACPI ID 26) ignored ACPI: Processor \_SB_.PR1B (ACPI ID 27) ignored ACPI: Processor \_SB_.PR1C (ACPI ID 28) ignored ACPI: Processor \_SB_.PR1D (ACPI ID 29) ignored ACPI: Processor \_SB_.PR1E (ACPI ID 30) ignored ACPI: Processor \_SB_.PR1F (ACPI ID 31) ignored ACPI: Processor \_SB_.PR20 (ACPI ID 32) ignored ACPI: Processor \_SB_.PR21 (ACPI ID 33) ignored ACPI: Processor \_SB_.PR22 (ACPI ID 34) ignored ACPI: Processor \_SB_.PR23 (ACPI ID 35) ignored ACPI: Processor \_SB_.PR24 (ACPI ID 36) ignored ACPI: Processor \_SB_.PR25 (ACPI ID 37) ignored ACPI: Processor \_SB_.PR26 (ACPI ID 38) ignored ACPI: Processor \_SB_.PR27 (ACPI ID 39) ignored ACPI: Processor \_SB_.PR28 (ACPI ID 40) ignored ACPI: Processor \_SB_.PR29 (ACPI ID 41) ignored ACPI: Processor \_SB_.PR2A (ACPI ID 42) ignored ACPI: Processor \_SB_.PR2B (ACPI ID 43) ignored ACPI: Processor \_SB_.PR2C (ACPI ID 44) ignored ACPI: Processor \_SB_.PR2D (ACPI ID 45) ignored ACPI: Processor \_SB_.PR2E (ACPI ID 46) ignored ACPI: Processor \_SB_.PR2F (ACPI ID 47) ignored ACPI: Processor \_SB_.PR30 (ACPI ID 48) ignored ACPI: Processor \_SB_.PR31 (ACPI ID 49) ignored ACPI: Processor \_SB_.PR32 (ACPI ID 50) ignored ACPI: Processor \_SB_.PR33 (ACPI ID 51) ignored ACPI: Processor \_SB_.PR34 (ACPI ID 52) ignored ACPI: Processor \_SB_.PR35 (ACPI ID 53) ignored ACPI: Processor \_SB_.PR36 (ACPI ID 54) ignored ACPI: Processor \_SB_.PR37 (ACPI ID 55) ignored ACPI: Processor \_SB_.PR38 (ACPI ID 56) ignored ACPI: Processor \_SB_.PR39 (ACPI ID 57) ignored ACPI: Processor \_SB_.PR3A (ACPI ID 58) ignored ACPI: Processor \_SB_.PR3B (ACPI ID 59) ignored ACPI: Processor \_SB_.PR3C (ACPI ID 60) ignored ACPI: Processor \_SB_.PR3D (ACPI ID 61) ignored ACPI: Processor \_SB_.PR3E (ACPI ID 62) ignored ACPI: Processor \_SB_.PR3F (ACPI ID 63) ignored ACPI: Processor \_SB_.PR40 (ACPI ID 64) ignored ACPI: Processor \_SB_.PR41 (ACPI ID 65) ignored ACPI: Processor \_SB_.PR42 (ACPI ID 66) ignored ACPI: Processor \_SB_.PR43 (ACPI ID 67) ignored ACPI: Processor \_SB_.PR44 (ACPI ID 68) ignored ACPI: Processor \_SB_.PR45 (ACPI ID 69) ignored ACPI: Processor \_SB_.PR46 (ACPI ID 70) ignored ACPI: Processor \_SB_.PR47 (ACPI ID 71) ignored ACPI: Processor \_SB_.PR48 (ACPI ID 72) ignored ACPI: Processor \_SB_.PR49 (ACPI ID 73) ignored ACPI: Processor \_SB_.PR4A (ACPI ID 74) ignored ACPI: Processor \_SB_.PR4B (ACPI ID 75) ignored ACPI: Processor \_SB_.PR4C (ACPI ID 76) ignored ACPI: Processor \_SB_.PR4D (ACPI ID 77) ignored ACPI: Processor \_SB_.PR4E (ACPI ID 78) ignored ACPI: Processor \_SB_.PR4F (ACPI ID 79) ignored ACPI: Processor \_SB_.PR50 (ACPI ID 80) ignored ACPI: Processor \_SB_.PR51 (ACPI ID 81) ignored ACPI: Processor \_SB_.PR52 (ACPI ID 82) ignored ACPI: Processor \_SB_.PR53 (ACPI ID 83) ignored ACPI: Processor \_SB_.PR54 (ACPI ID 84) ignored ACPI: Processor \_SB_.PR55 (ACPI ID 85) ignored ACPI: Processor \_SB_.PR56 (ACPI ID 86) ignored ACPI: Processor \_SB_.PR57 (ACPI ID 87) ignored ACPI: Processor \_SB_.PR58 (ACPI ID 88) ignored ACPI: Processor \_SB_.PR59 (ACPI ID 89) ignored ACPI: Processor \_SB_.PR5A (ACPI ID 90) ignored ACPI: Processor \_SB_.PR5B (ACPI ID 91) ignored ACPI: Processor \_SB_.PR5C (ACPI ID 92) ignored ACPI: Processor \_SB_.PR5D (ACPI ID 93) ignored ACPI: Processor \_SB_.PR5E (ACPI ID 94) ignored ACPI: Processor \_SB_.PR5F (ACPI ID 95) ignored ACPI: Processor \_SB_.PR60 (ACPI ID 96) ignored ACPI: Processor \_SB_.PR61 (ACPI ID 97) ignored ACPI: Processor \_SB_.PR62 (ACPI ID 98) ignored ACPI: Processor \_SB_.PR63 (ACPI ID 99) ignored ACPI: Processor \_SB_.PR64 (ACPI ID 100) ignored ACPI: Processor \_SB_.PR65 (ACPI ID 101) ignored ACPI: Processor \_SB_.PR66 (ACPI ID 102) ignored ACPI: Processor \_SB_.PR67 (ACPI ID 103) ignored ACPI: Processor \_SB_.PR68 (ACPI ID 104) ignored ACPI: Processor \_SB_.PR69 (ACPI ID 105) ignored ACPI: Processor \_SB_.PR6A (ACPI ID 106) ignored ACPI: Processor \_SB_.PR6B (ACPI ID 107) ignored ACPI: Processor \_SB_.PR6C (ACPI ID 108) ignored ACPI: Processor \_SB_.PR6D (ACPI ID 109) ignored ACPI: Processor \_SB_.PR6E (ACPI ID 110) ignored ACPI: Processor \_SB_.PR6F (ACPI ID 111) ignored ACPI: Processor \_SB_.PR70 (ACPI ID 112) ignored ACPI: Processor \_SB_.PR71 (ACPI ID 113) ignored ACPI: Processor \_SB_.PR72 (ACPI ID 114) ignored ACPI: Processor \_SB_.PR73 (ACPI ID 115) ignored ACPI: Processor \_SB_.PR74 (ACPI ID 116) ignored ACPI: Processor \_SB_.PR75 (ACPI ID 117) ignored ACPI: Processor \_SB_.PR76 (ACPI ID 118) ignored ACPI: Processor \_SB_.PR77 (ACPI ID 119) ignored ACPI: Processor \_SB_.PR78 (ACPI ID 120) ignored ACPI: Processor \_SB_.PR79 (ACPI ID 121) ignored ACPI: Processor \_SB_.PR7A (ACPI ID 122) ignored ACPI: Processor \_SB_.PR7B (ACPI ID 123) ignored ACPI: Processor \_SB_.PR7C (ACPI ID 124) ignored ACPI: Processor \_SB_.PR7D (ACPI ID 125) ignored ACPI: Processor \_SB_.PR7E (ACPI ID 126) ignored ACPI: Processor \_SB_.PR7F (ACPI ID 127) ignored hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 62500000Hz 64bit, 3 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), 64bit, periodic hpet0: t2: irqs 0x00f00000 (0), 64bit, periodic Timecounter "HPET" frequency 62500000 Hz quality 950 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 49 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 50 Event timer "RTC" frequency 32768 Hz quality 0 ACPI timer: 1/90 1/11 1/10 1/15 1/11 1/14 1/11 1/14 1/10 1/12 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 10 11 Validation 0 5 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 10 11 Validation 0 10 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 10 11 Validation 0 11 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 10 11 Validation 0 5 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xf0000000-0xfbffffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x1237, revid=0x02 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0004, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7000, revid=0x00 domain=0, bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0004, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7010, revid=0x00 domain=0, bus=0, slot=1, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:1:1 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:1:1 pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:1:1 pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:1:1 map[20]: type I/O Port, range 32, base 0xc300, size 4, enabled pcib0: allocated type 4 (0xc300-0xc30f) for rid 20 of pci0:0:1:1 found-> vendor=0x8086, dev=0x7113, revid=0x03 domain=0, bus=0, slot=1, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0004, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 20 found-> vendor=0x1013, dev=0x00b8, revid=0x00 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xf0000000, size 25, enabled pcib0: allocated type 3 (0xf0000000-0xf1ffffff) for rid 10 of pci0:0:2:0 map[14]: type Memory, range 32, base 0xf3030000, size 12, enabled pcib0: allocated type 3 (0xf3030000-0xf3030fff) for rid 14 of pci0:0:2:0 found-> vendor=0x5853, dev=0x0001, revid=0x01 domain=0, bus=0, slot=3, func=0 class=ff-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib0: allocated type 4 (0xc000-0xc0ff) for rid 10 of pci0:0:3:0 map[14]: type Prefetchable Memory, range 32, base 0xf2000000, size 24, enabled pcib0: allocated type 3 (0xf2000000-0xf2ffffff) for rid 14 of pci0:0:3:0 pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 28 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc300-0xc30f at device 1.1 on pci0 ata0: at channel 0 on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 51 ata1: at channel 1 on atapci0 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 52 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xf0000000-0xf1ffffff,0xf3030000-0xf3030fff at device 2.0 on pci0 xenpci0: port 0xc000-0xc0ff mem 0xf2000000-0xf2ffffff irq 28 at device 3.0 on pci0 xenpci0: Xen version 4.4. ioapic0: routing intpin 28 (PCI IRQ 28) to lapic 0 vector 53 xenstore0: on xenpci0 Grant table initialized psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0061 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 54 atkbd0: [GIANT-LOCKED] psm0: current command byte:0061 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 00 00 64 psm: status 00 03 64 psm: status 00 03 64 psm: data 08 00 00 psm: status 00 02 64 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 55 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 56 uart0: fast interrupt ppc0: using extended I/O port range ppc0: SPP ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 57 ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ACPI: Enabled 2 GPEs in block 00 to 0F qpi0: on motherboard acpi0: wakeup code va 0xffffff801a68c000 pa 0x4000 ex_isa_identify() pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 ahc_isa_identify 0: ioport 0xc00 alloc failed ahc_isa_identify 1: ioport 0x1c00 alloc failed ahc_isa_identify 2: ioport 0x2c00 alloc failed ahc_isa_identify 3: ioport 0x3c00 alloc failed ahc_isa_identify 4: ioport 0x4c00 alloc failed ahc_isa_identify 5: ioport 0x5c00 alloc failed ahc_isa_identify 6: ioport 0x6c00 alloc failed ahc_isa_identify 7: ioport 0x7c00 alloc failed ahc_isa_identify 8: ioport 0x8c00 alloc failed ahc_isa_identify 9: ioport 0x9c00 alloc failed ahc_isa_identify 10: ioport 0xac00 alloc failed ahc_isa_identify 11: ioport 0xbc00 alloc failed ahc_isa_identify 12: ioport 0xcc00 alloc failed ahc_isa_identify 13: ioport 0xdc00 alloc failed ahc_isa_identify 14: ioport 0xec00 alloc failed isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xee800-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 fdc0: No FDOUT register! fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 uart1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 50000689 Hz Timecounters tick every 10.000 msec vlan: initialized, using hash tables with chaining tcp_init: net.inet.tcp.tcbhashsize auto tuned to 2048 lo0: bpf attached hptnr: no controller detected. hpt27xx: no controller detected. hptrr: no controller detected. xenbusb_front0: on xenstore0 ata0: reset tp1 mask=03 ostat0=00 ostat1=00 ata0: stat0=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x0 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 xenbusb_add_device: Device device/suspend/event-channel ignored. State 6 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0xff msb=0xff ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 can't re-use a leaf (max_requests)! pass0 at ata1 bus 0 scbus1 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: Serial Number QM00003 pass0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, xbd0: 20480MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ada0 xbd0: features: flush, write_barrier xbd0: synchronize cache commands enabled. can't re-use a leaf (max_requests)! xn0: at device/vif/0 on xenbusb_front0 xn0: bpf attached xn0: Ethernet address: 00:16:3e:47:d4:52 xn1: at device/vif/1 on xenbusb_front0 GEOM: new disk ada0 xn1: bpf attached xn1: Ethernet address: 00:16:3e:47:d4:53 xenbusb_back0: on xenstore0 xctrl0: on xenstore0 PIO 65534bytes) cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number QM00003 cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present xn0: backend features: feature-sg feature-gso-tcp4 xn1: backend features: feature-sg feature-gso-tcp4 xbd1: 1000MB at device/vbd/832 on xenbusb_front0 xbd1: attaching as ada1 lapic8: CMCI unmasked lapic2: CMCI unmasked SMP: AP CPU #4 Launched! lapic6: CMCI unmasked cpu4 AP: lapic10: CMCI unmasked ID: 0x08000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lapic12: CMCI unmasked lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff lapic4: CMCI unmasked timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x04000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #5 Launched! cpu5 AP: ID: 0x0a000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x06000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #6 Launched! cpu6 AP: ID: 0x0c000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 2 vector 48 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 4 vector 48 ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 6 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 8 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 10 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 12 vector 48 ioapic0: routing intpin 28 (PCI IRQ 28) to lapic 2 vector 49 TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1533419232 Hz quality -100 WARNING: WITNESS option enabled, expect reduced performance. GEOM: new disk cd0 GEOM: new disk ada1 Trying to mount root from ufs:/dev/ada0p2 [rw]... start_init: trying /sbin/init Setting hostuuid: c9230f36-1a54-489e-877c-1d15b8f463e9. Setting hostid: 0xd52252c7. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ada0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0p2: clean, 670674 free (10762 frags, 82489 blocks, 0.2% fragmentation) Mounting local file systems:. From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 15:40:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 410B3145 for ; Thu, 25 Jul 2013 15:40:06 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA5002FE8 for ; Thu, 25 Jul 2013 15:40:05 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1V2Ne7-0001tK-43 for freebsd-current@freebsd.org; Thu, 25 Jul 2013 17:40:03 +0200 Received: from ip-109-45-0-12.web.vodafone.de ([109.45.0.12]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jul 2013 17:40:03 +0200 Received: from johannes by ip-109-45-0-12.web.vodafone.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jul 2013 17:40:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Johannes Totz Subject: Re: r253070 and "disappearing" zpool Date: Thu, 25 Jul 2013 16:33:58 +0100 Lines: 144 Message-ID: References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> <20130722203853.GB1400@garage.freebsd.pl> <51EFBEBF.601@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip-109-45-0-12.web.vodafone.de User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 In-Reply-To: <51EFBEBF.601@FreeBSD.org> X-Mailman-Approved-At: Thu, 25 Jul 2013 17:52:06 +0000 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 15:40:06 -0000 On 24/07/2013 12:47, Andriy Gapon wrote: > on 22/07/2013 23:38 Pawel Jakub Dawidek said the following: >> On Mon, Jul 22, 2013 at 10:29:40AM +0300, Andriy Gapon wrote: >>> I think that this setup (on ZFS level) is quite untypical, although not >>> impossible on FreeBSD (and perhaps only FreeBSD). >>> It's untypical because you have separate boot pool (where loader, loader.conf >>> and kernel are taken from) and root pool (where "/" is mounted from). >> >> As I said elsewhere, it is pretty typical when full disk encryption is >> used. > > I am judging by the number of reports / amount of feedback so far. I'm using a similar configuration too, where I have a USB stick with unencrypted kernel and /boot bits which load a GELI keyfile (from its own pool zboot), and then the rest of the system starts up from the fully encrypted HDD (from another pool zsystem, so boot and rootfs are on different pools). I'm not sure I understand the problem though. What exactly "broke" after your commit? The pool that contains the bits that would normally go to /boot is not imported automatically, but the rest is working (ie. /boot symlink pointing to nowhere)? Or does booting somehow fail? > >> The /boot/ has to be unencrypted and can be stored on eg. USB >> pendrive which is never left unattended, unlike laptop which can be left >> in eg. a hotel room, but with entire disk encrypted. > > As we discussed elsewhere, there are many options of configuring full disk > encryption. Including decisions whether root filesystem should be separate from > boot filesystem, choice of filesystem type for boot fs, ways of tying various > pieces together, and many more. > > I do not believe that my change is incompatible with full disk encryption in > general. > >>> So, I see three ways of resolving the problem that my changes caused for your >>> configuration. >>> >>> 1. [the easiest] Put zpool.cache loading instructions that used to be in >>> defaults/loader.conf into your loader.conf. This way everything should work as >>> before -- zpool.cache would be loaded from your boot pool. >>> >>> 2. Somehow (I don't want to go into any technical details here) arrange that >>> your root pool has /boot/zfs/zpool.cache that describes your boot pool. This is >>> probably hard given that your /boot is a symlink at the moment. This probably >>> would be easier to achieve if zpool.cache lived in /etc/zfs. >>> >>> 3. [my favorite] Remove an artificial difference between your boot and root >>> pools, so that they are a single root+boot pool (as zfs gods intended). As far >>> as I understand your setup, you use GELI to protect some sensitive data. >>> Apparently your kernel is not sensitive data, so I wonder if your /bin/sh or >>> /sbin/init are really sensitive either. >>> So perhaps you can arrange your unencrypted pool to hold all of the base system >>> (boot + root) and put all your truly sensitive filesystems (like e.g. /home or >>> /var/data or /opt/xyz) onto your encrypted pool. >> >> If all you care about is laptop being stolen, then that would work. >> >> If you however want to be protected from someone replacing your /sbin/init >> with something evil then you use encryption or even better integrity >> verification also supported by GELI. > > There are different ways to ensure that. Including storing cryptographic > checksums in a safe place or keeping init in the same place where kernel is > kept. And probably many more. > >> Remember, tools not policies. > > I am not trying to enforce any policy on end-users here. > >> There is also option number 4 - backing out your commit. > > That's definitely an option. I'll discuss it a few lines below. > >> When I saw your commit removing those entries from defaults/loader.conf, >> I thought it is fine, as we now don't require zpool.cache to import the >> root pool, which was, BTW, very nice and handy improvement. Now that we >> know it breaks existing installations I'd prefer the commit to be backed >> out. > > "breaks" sounds dramatic, but let's take a step back and see what exactly is broken. > The system in question still can boot without a problem, it is fully usable and > it is possible to change its configuration without any hassle. The only thing > that changed is that its boot pool is not imported automatically. > Let's also recall that the system was not created / configured by any of the > existing official or semi-official tools and thus it does not represent any > recommended way of setting up such systems. Glen configured it this way, but it > doesn't mean that that is the way. > > I think that there are many of ways of changing configuration of that system to > make behave as before again. > Three I mentioned already. Another is to add rc script to import the boot pool, > given that it is a special, designated pool. Yet another is to place > zpool.cache onto the root pool and use nullfs (instead of a symlink) to make > /boot be from the boot pool but /boot/zfs be from the root pool. > >> This is because apart from breaking some existing installations it >>> doesn't gain us anything. > > I think I addressed the "breaking" part, as to the gains - a few lines below. > >>> So I understand that my change causes a problem for a setup like yours, but I >>> believe that the change is correct. >> >> The change is clearly incorrect or incomplete as it breaks existing >> installations and doesn't allow for full disk encryption configuration >> on ZFS-only systems. > > I think I addressed the breaking part and also addressed your overly general > statement about full disk encryption. So I don't think that my change is > "clearly incorrect", otherwise that would be clear even to me. > >> BTW. If moving zpool.cache to /etc/zfs/ will work for both cases that's >> fine by me, although the migration might be tricky. > > Yes, that's migration that's scary to me too. > > > Now, about the postponed points. > I will reproduce a section from my email that you've snipped. > >>> P.S. >>> ZFS/FreeBSD boot process is extremely flexible. For example zfsboot can take >>> zfsloader from pool1/fsA, zfsloader can boot kernel from pool2/fsB and kernel >>> can mount / from pool3/fsC. Of these 3 filesystems from where should >>> zpool.cache be taken? >>> My firm opinion is that it should be taken from / (pool3/fsC in the example >>> above). Because it is the root filesystem that defines what a system is going >>> to do ultimately: what daemons are started, with what configurations, etc. >>> And thus it should also determine what pools to auto-import. >>> We can say that zpool.cache is analogous to /etc/fstab in this respect. > > So do you or do you not agree with my reasoning about from where zpool.cache > should be taken? > If you do not, then please explain why. > If you do, then please explain how this would be compatible with the old way of > loading zpool.cache. > > I think that ensuring that zpool.cache is always loaded from a root filesystem > is the gain from my change. > From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 19:47:30 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 64E09B2D; Thu, 25 Jul 2013 19:47:30 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 571162C58; Thu, 25 Jul 2013 19:47:27 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id AC1881E5; Thu, 25 Jul 2013 21:42:21 +0200 (CEST) Date: Thu, 25 Jul 2013 21:48:03 +0200 From: Pawel Jakub Dawidek To: Andriy Gapon Subject: Re: r253070 and "disappearing" zpool Message-ID: <20130725194803.GA1400@garage.freebsd.pl> References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> <20130722203853.GB1400@garage.freebsd.pl> <51EFBEBF.601@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <51EFBEBF.601@FreeBSD.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org, Glen Barber , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 19:47:30 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 02:47:11PM +0300, Andriy Gapon wrote: > on 22/07/2013 23:38 Pawel Jakub Dawidek said the following: > > The /boot/ has to be unencrypted and can be stored on eg. USB > > pendrive which is never left unattended, unlike laptop which can be left > > in eg. a hotel room, but with entire disk encrypted. >=20 > As we discussed elsewhere, there are many options of configuring full disk > encryption. Including decisions whether root filesystem should be separa= te from > boot filesystem, choice of filesystem type for boot fs, ways of tying var= ious > pieces together, and many more. >=20 > I do not believe that my change is incompatible with full disk encryption= in > general. Maybe you can imagine many ways of configuring it, but definiately the most typical one is to have separate /boot/ from /, where /boot/ is unencrypted and where you use one file system type for both (UFS or ZFS). > Let's also recall that the system was not created / configured by any of = the > existing official or semi-official tools and thus it does not represent a= ny > recommended way of setting up such systems. Glen configured it this way,= but it > doesn't mean that that is the way. Note that there are no official tools to install FreeBSD on ZFS. Is that enough reason to stop supporting it? What Glen did is the recommended way of setting up full disk encryption with ZFS. I'd do it the same way and I'd recommend this configuration to anyone who will (or did) ask me. > I think that there are many of ways of changing configuration of that sys= tem to > make behave as before again. > Three I mentioned already. Another is to add rc script to import the boo= t pool, > given that it is a special, designated pool. Yet another is to place > zpool.cache onto the root pool and use nullfs (instead of a symlink) to m= ake > /boot be from the boot pool but /boot/zfs be from the root pool. Come on... > > BTW. If moving zpool.cache to /etc/zfs/ will work for both cases that's > > fine by me, although the migration might be tricky. >=20 > Yes, that's migration that's scary to me too. >=20 >=20 > Now, about the postponed points. > I will reproduce a section from my email that you've snipped. >=20 > >> P.S. > >> ZFS/FreeBSD boot process is extremely flexible. For example zfsboot c= an take > >> zfsloader from pool1/fsA, zfsloader can boot kernel from pool2/fsB and= kernel > >> can mount / from pool3/fsC. Of these 3 filesystems from where should > >> zpool.cache be taken? > >> My firm opinion is that it should be taken from / (pool3/fsC in the ex= ample > >> above). Because it is the root filesystem that defines what a system = is going > >> to do ultimately: what daemons are started, with what configurations, = etc. > >> And thus it should also determine what pools to auto-import. > >> We can say that zpool.cache is analogous to /etc/fstab in this respect. >=20 > So do you or do you not agree with my reasoning about from where zpool.ca= che > should be taken? > If you do not, then please explain why. > If you do, then please explain how this would be compatible with the old = way of > loading zpool.cache. I don't have a strong opinion about this. As I said above I'm fine with moving zpool.cache to /etc/zfs/ if we can ensure it won't break existing installations. Still I'm not sure this was your initial goal, because you weren't aware of systems with separate boot pool until recently (if you were aware of this I hope you wouldn't commit the change without prior discussion). Which means in your eyes zpool.cache was always part of the root pool, because /boot/ was. > I think that ensuring that zpool.cache is always loaded from a root files= ystem > is the gain from my change. Were people complaining about zpool.cache being loaded from /boot/zfs/ and not from /etc/zfs/? I don't think so. But people do complain about boot pool not being autoimported. In my opinion for the end user it doesn't really matter if it is /etc/zfs/zpool.cache or /boot/zfs/zpool.cache, as both directories are available once the system is booted. For most people those two directories are placed on the same file system. For some people who actually care if this is /etc/zfs/ or /boot/zfs/, because those are separate file systems the latter works, the former doesn't. In my opinion the gain, if any, is only theoretical. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHxgPMACgkQForvXbEpPzReWQCgkMDxrjg0k3SuZ6aWKb4kIpiY IB8AoMwG4xOx8ncJX2KGtip2br8AtQjo =bkm1 -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 20:31:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 326FE6F2; Thu, 25 Jul 2013 20:31:55 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3EFA2E64; Thu, 25 Jul 2013 20:31:54 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n12so5499057oag.36 for ; Thu, 25 Jul 2013 13:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MWXqU+js3bXhIe/rtkwsupkW59SZPsfz2LuMMeYKeTs=; b=qSmbQWpn41VlKDsHvI9XN3X0O/twhX5lmqx22ipULqUNvahKpzTUC8wLuJG1meRXDL z9Hn1iv3E6T2Lxv/HJEIx6lgM32m0znBVclEk9QcnNcbMvdoHHz3K9wuAEGi1cbVNrpO TTl9SRBGEDrM/dmw/HSRYt4835XIK19Jmhbqi6nUFwLMdDXsYcCOInYt7UGOc6Tis0gd WvLFQ4Adga8/HfqTM1v98iq+yDk0UPR3M61kW6UzDxJthLS+fUzpCfi8k129VberpJah kjt5mMMBul54WsjaD0zQd23imL0jWTsuudvBdvfc7LVFB5trZlDYKsZm66mxB6wLxVcl Swxg== MIME-Version: 1.0 X-Received: by 10.60.52.78 with SMTP id r14mr45103404oeo.9.1374784314010; Thu, 25 Jul 2013 13:31:54 -0700 (PDT) Received: by 10.182.115.194 with HTTP; Thu, 25 Jul 2013 13:31:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jul 2013 16:31:53 -0400 Message-ID: Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. From: Super Bisquit To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Wojciech Puchar , freebsd-current , FreeBSD Hackers , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 20:31:55 -0000 I haven't done much messing with scheduling. It is set at the default ULE for this machine. On Thu, Jul 25, 2013 at 12:11 PM, Adrian Chadd wrote: > On 25 July 2013 02:51, Wojciech Puchar > wrote: > >> improved with a higher kern.hz rating. Unless the future holds an > emu20k2, > >> there will be RAM used from the motherboard. > >> 1. I will need a real-time or a faster kernel- hence the high rate > wanted- > >> because the devices to be built will be used in an active environment: > >> art, > >> music, audio control. > >> 2. Any system with limited memory and a low CPU hertz rate benefits from > >> the higher kern.hz setting. > > > rather opposite. more kern.hz=more interrupts. > > Right. > > More hz == more interrupts and less ability for a CPU-bound process to > chew all the CPU. > > So is it a scheduling issue, where you have multiple CPU bound > userland processes that aren't being fair and consuming all the CPU? > Is it that your device driver(s) aren't interrupting correctly, > relying on the hz tick to make up the slack, etc. > > Is it a busted halt loop, which is being papered over with hz ticks? > > Have you tried -10 on that kit, with the more aggressive clock/timer > code that won't interrupt unless it needs to? Has that changed things? > > > > -adrian > From owner-freebsd-current@FreeBSD.ORG Thu Jul 25 20:37:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 59DDAA97; Thu, 25 Jul 2013 20:37:23 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 072AE2EED; Thu, 25 Jul 2013 20:37:22 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n12so5513166oag.36 for ; Thu, 25 Jul 2013 13:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GVKW2uqi4jjMHno3l5dHxzWLhhN5fQR6HD51M/2JFSM=; b=j8zl/ppDO53vdMLGaTyL34gYpQQ4I/A85gX4VT7p+9sILqPPThoIGKiamgQirQMwN8 5fttjop381Jod0LlSTQf/202oCAyvAAnnhtJn1G7HTaaROrhoGwE4HJO9Ke4BeKgk6CL PCaMDh1dGUpQcjHySoiqe2nZ1MxI9jsbf9FqbgqME2EVA5BdH081YcQlDCwKrnICx2uG Y0aYy6183wKKzlxyV1MIo+n8ZV9MtQjxUWZTb9YbOkMivP3gxal1xe3nCNbGuLz+8D2t BIa7lU0dwe3P7uxD4h2VDNBGnl9hr5WN8Gg9vHtFtYFpdEK/X5PI/O7pJUXJB4eJlZSu ErVg== MIME-Version: 1.0 X-Received: by 10.60.102.41 with SMTP id fl9mr44534074oeb.37.1374784642376; Thu, 25 Jul 2013 13:37:22 -0700 (PDT) Received: by 10.182.115.194 with HTTP; Thu, 25 Jul 2013 13:37:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jul 2013 16:37:22 -0400 Message-ID: Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. From: Super Bisquit To: Adrian Chadd , FreeBSD PowerPC ML , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 25 Jul 2013 20:37:23 -0000 On Thu, Jul 25, 2013 at 12:11 PM, Adrian Chadd wrote: > On 25 July 2013 02:51, Wojciech Puchar > wrote: > >> improved with a higher kern.hz rating. Unless the future holds an > emu20k2, > >> there will be RAM used from the motherboard. > >> 1. I will need a real-time or a faster kernel- hence the high rate > wanted- > >> because the devices to be built will be used in an active environment: > >> art, > >> music, audio control. > >> 2. Any system with limited memory and a low CPU hertz rate benefits from > >> the higher kern.hz setting. > > > rather opposite. more kern.hz=more interrupts. > > Right. > > More hz == more interrupts and less ability for a CPU-bound process to > chew all the CPU. > > So is it a scheduling issue, where you have multiple CPU bound > userland processes that aren't being fair and consuming all the CPU? > Is it that your device driver(s) aren't interrupting correctly, > relying on the hz tick to make up the slack, etc. > The G3 had the other scheduler- not ULE- when I built the system. > > Is it a busted halt loop, which is being papered over with hz ticks? > I wouldn't know. How would I test for this? > > Have you tried -10 on that kit, with the more aggressive clock/timer > code that won't interrupt unless it needs to? Set the rate to -10 ? I'll try the aggressive clock/timer code if someone would point me to a tutorial for setting it up. That sounds more like a solution I like. > Has that changed things? > If I can implement it, it may be the best solution. > > > > -adrian > From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 03:13:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5FB09B0; Fri, 26 Jul 2013 03:13:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C07F42FA6; Fri, 26 Jul 2013 03:13:18 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id n11so318374wgh.2 for ; Thu, 25 Jul 2013 20:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bhWMmD+w+JxVKwgdEJ8655qzdF0R1W0gMKC7gB2gMb8=; b=OQndwZBFUfBJEN3LXvxQTaqyGEultRQ1XCt8q6yLCMGw2GE0GtNmyZS/meco8/gqj3 5vAoPSExjBPU9uywKvMbKC7IpglOK1UhEiVNHGADwRISz3Zyg5eR5iy/i3EGUh5WXCM8 ztsi8ieaHWjjJZBZVl78a2qkDie0sK9wxCONG9/iZpJVKaaXKbuT2P4exH5GjnP/INyO NQ/dtSDsOdwOBBIPGkvKixugH5HGuHIkiqs8gII78AJXbZusrNP93a3GFomGcf3b5znG ibGD3LYCXqES03U3YqasktNeqVhKbQZiqJZAkuwtqI6D5MhhcgTz0NmyjzoyE2CXUEae dxcA== MIME-Version: 1.0 X-Received: by 10.180.185.148 with SMTP id fc20mr4238558wic.0.1374808397082; Thu, 25 Jul 2013 20:13:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Thu, 25 Jul 2013 20:13:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jul 2013 20:13:17 -0700 X-Google-Sender-Auth: S7FwV8QhAaymw-EJ_NK-935KXLc Message-ID: Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. From: Adrian Chadd To: Super Bisquit Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 03:13:19 -0000 I mean, try -10 on it and report back. -adrian From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 04:35:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E0C57B22; Fri, 26 Jul 2013 04:35:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E46B2362; Fri, 26 Jul 2013 04:35:38 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id g12so6469984oah.11 for ; Thu, 25 Jul 2013 21:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mEnMzkBOXB/zcEVesoHgMF1BVtYZpd1IN7+i/gvhT64=; b=ZbD+oS3WI1YWOJ/YO9JWpecCFYOOx/JuNBU0WizUji58RJrAZUITHwafQa9bg+VymG QMp8ms3olArB7kgG7qlSouQTFGLBt1nQGiQ74Vt4X6SjoETSfD5on0+5ptTmxCbWMwSB b1cwFP413kz6jI6UUog1ke5sevjy3rlrbaspMvgrK5dfPOhgk9G8NI+LFGb0JlKOc/Ka Cr5Fey6wSJveaU2Z2Y5o5pFwrPYavscnlAduwWI26EJT2J0y/XweATjqPOH9lFJ40ZAw xdkm7ib2gQWfjtimi9onvd+ebfdhnSUZz/xIG7QmzEbvPhzA9F1Fut5DxfOc1e9+0BNv Q69A== MIME-Version: 1.0 X-Received: by 10.182.50.200 with SMTP id e8mr40458607obo.35.1374813337894; Thu, 25 Jul 2013 21:35:37 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Thu, 25 Jul 2013 21:35:37 -0700 (PDT) In-Reply-To: <20130724223125.GD41432@ithaqua.etoilebsd.net> References: <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> <20130724152216.GE63694@ithaqua.etoilebsd.net> <51F01A0C.2070808@gmail.com> <20130724183610.GI63694@ithaqua.etoilebsd.net> <20130724184929.GA41432@ithaqua.etoilebsd.net> <51F0389B.3020800@FreeBSD.org> <20130724223125.GD41432@ithaqua.etoilebsd.net> Date: Thu, 25 Jul 2013 21:35:37 -0700 X-Google-Sender-Auth: l8nCXOeDWjjwxMDcLChaxYPrGyU Message-ID: Subject: Re: FUSE not work. From: Kevin Oberman To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Alexander Panyushkin , Pedro Giffuni , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 04:35:39 -0000 On Wed, Jul 24, 2013 at 3:31 PM, Baptiste Daroussin wrote: > On Wed, Jul 24, 2013 at 03:27:07PM -0500, Pedro Giffuni wrote: > > On 24.07.2013 13:49, Baptiste Daroussin wrote: > > > ... > > >> Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to > that version > > >> and it will work, I'm investigating. > > >> > > >> What I fix is the umount umounting all the FS. > > >> > > >> regards, > > >> Bapt > > > Forgot to say r248084 is the last working revision. > > > > Sorry for the delay, > > > > OK, I reverted the kernel header update in revision 253619 > > hopefully this will save everyone affected some pain ... > > > Thank you very much ! > > regards, > Bapt > Thanks, Bapt. Works great... not to mention being MUCH cleaner. I also updated the patch-set for the fusefs kernel for 9-stable to include all of the changes to head. (Well, all that are appropriate to 9-stable.) I can post it if anyone is interested. It's nearly identical to the stuff for head. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 05:35:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 46E99362; Fri, 26 Jul 2013 05:35:26 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0E382532; Fri, 26 Jul 2013 05:35:25 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id m46so1424471wev.22 for ; Thu, 25 Jul 2013 22:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=nrKAlKtowi66lS4Hnse5QYTGRGbgP2TPJP7HrGcnKvU=; b=D1KFOKjKMc10leLgYhS9pjSDGoP0kbQLPoSWFMQCyDM38umHAo9ZFqAIo/fbrOmc17 hHWaWmJkDO4WXqvHAPnLIllD+6L7uTBnI85iylgvqbdKwUvNELIjyKoUzp9+vrHnxrLj swf+L2qlnXcdiQmPxIKCBwg3Nh6Ksoyqh9j4SBxJXi9aegAyF5x1Y9hfdz3lJfeBt6LW neR0ePH84gp8rIqZL5BK8pEtEDHHiEz4YGQqgkB1wCR1jpFlZqKMwVUvVGk/52ZIET1O YNTsNgYIrm+/PC6s6mM7kBQQGVmCjCeQso0FIqUO/vHZEYwv4ifGD3yYqaYtSle2JNo3 oL/g== X-Received: by 10.181.11.133 with SMTP id ei5mr4486960wid.4.1374816923062; Thu, 25 Jul 2013 22:35:23 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id hb2sm2279855wib.0.2013.07.25.22.35.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jul 2013 22:35:22 -0700 (PDT) Sender: Baptiste Daroussin Date: Fri, 26 Jul 2013 07:35:19 +0200 From: Baptiste Daroussin To: Kevin Oberman Subject: Re: FUSE not work. Message-ID: <20130726053519.GS61207@ithaqua.etoilebsd.net> References: <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> <20130724152216.GE63694@ithaqua.etoilebsd.net> <51F01A0C.2070808@gmail.com> <20130724183610.GI63694@ithaqua.etoilebsd.net> <20130724184929.GA41432@ithaqua.etoilebsd.net> <51F0389B.3020800@FreeBSD.org> <20130724223125.GD41432@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BuGwuXnZwGGQ9GEc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Panyushkin , Pedro Giffuni , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 05:35:26 -0000 --BuGwuXnZwGGQ9GEc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2013 at 09:35:37PM -0700, Kevin Oberman wrote: > On Wed, Jul 24, 2013 at 3:31 PM, Baptiste Daroussin wro= te: >=20 > > On Wed, Jul 24, 2013 at 03:27:07PM -0500, Pedro Giffuni wrote: > > > On 24.07.2013 13:49, Baptiste Daroussin wrote: > > > > ... > > > >> Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to > > that version > > > >> and it will work, I'm investigating. > > > >> > > > >> What I fix is the umount umounting all the FS. > > > >> > > > >> regards, > > > >> Bapt > > > > Forgot to say r248084 is the last working revision. > > > > > > Sorry for the delay, > > > > > > OK, I reverted the kernel header update in revision 253619 > > > hopefully this will save everyone affected some pain ... > > > > > Thank you very much ! > > > > regards, > > Bapt > > >=20 > Thanks, Bapt. Works great... not to mention being MUCH cleaner. >=20 > I also updated the patch-set for the fusefs kernel for 9-stable to include > all of the changes to head. (Well, all that are appropriate to 9-stable.)= I > can post it if anyone is interested. It's nearly identical to the stuff > for head. Sure that is interesting please post it somewhere :) regards, Bapt --BuGwuXnZwGGQ9GEc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHyCpcACgkQ8kTtMUmk6ExLEQCeIFwpegu98Q+H8DRxiaArfmtk oPgAn3KHaiwjsUWJieLr1w7eQ9ZogG+X =SnT7 -----END PGP SIGNATURE----- --BuGwuXnZwGGQ9GEc-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 06:11:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C711ABDD; Fri, 26 Jul 2013 06:11:45 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 70F592666; Fri, 26 Jul 2013 06:11:45 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id i10so1443329oag.30 for ; Thu, 25 Jul 2013 23:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FEq3d925RMSqw9Pcqf1UDHN7LQvHOBMDdZJxAqB9GOs=; b=qnKat0HgnXWQdFw4kRplh09EY55hSuJH0Rag2NWzmZg+ehXSVh+XNg9JCz/5ToRQVS CsfQFrauBrjJ7aWY2K5h17AC38ozSo4yyJ1i+L0aY/Ge2x/Spbzx4p/hkU1yRvr2G97W HEXr8gB1PoC0j5VkpUA+7cVhSC739X7AdG4Yn15rQHT85wpTS78VnO+j+4AXcHrqo2os M5NMiaE7MqLq3Igf0O4ETEF0hQoc1LL7b6cH1ucyhSuxqpiwCb1j7GlHrSOyk/HSHdTt cdaRUQqSbw38alzvR3NLT/Qr5ldv1RkuazKIH03pipIlvVWdVH5HnM0Uc46zkeQz14sE lT1Q== MIME-Version: 1.0 X-Received: by 10.43.144.82 with SMTP id jp18mr20361808icc.100.1374819104629; Thu, 25 Jul 2013 23:11:44 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.64.165.104 with HTTP; Thu, 25 Jul 2013 23:11:44 -0700 (PDT) In-Reply-To: <20130726053519.GS61207@ithaqua.etoilebsd.net> References: <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> <20130724152216.GE63694@ithaqua.etoilebsd.net> <51F01A0C.2070808@gmail.com> <20130724183610.GI63694@ithaqua.etoilebsd.net> <20130724184929.GA41432@ithaqua.etoilebsd.net> <51F0389B.3020800@FreeBSD.org> <20130724223125.GD41432@ithaqua.etoilebsd.net> <20130726053519.GS61207@ithaqua.etoilebsd.net> Date: Thu, 25 Jul 2013 23:11:44 -0700 X-Google-Sender-Auth: 4TGAkT8jCj1w4dwjmZPR_xTfAjg Message-ID: Subject: Re: FUSE not work. From: Kevin Oberman To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Alexander Panyushkin , Pedro Giffuni , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 06:11:45 -0000 On Thu, Jul 25, 2013 at 10:35 PM, Baptiste Daroussin wrote: > On Thu, Jul 25, 2013 at 09:35:37PM -0700, Kevin Oberman wrote: > > On Wed, Jul 24, 2013 at 3:31 PM, Baptiste Daroussin >wrote: > > > > > On Wed, Jul 24, 2013 at 03:27:07PM -0500, Pedro Giffuni wrote: > > > > On 24.07.2013 13:49, Baptiste Daroussin wrote: > > > > > ... > > > > >> Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to > > > that version > > > > >> and it will work, I'm investigating. > > > > >> > > > > >> What I fix is the umount umounting all the FS. > > > > >> > > > > >> regards, > > > > >> Bapt > > > > > Forgot to say r248084 is the last working revision. > > > > > > > > Sorry for the delay, > > > > > > > > OK, I reverted the kernel header update in revision 253619 > > > > hopefully this will save everyone affected some pain ... > > > > > > > Thank you very much ! > > > > > > regards, > > > Bapt > > > > > > > Thanks, Bapt. Works great... not to mention being MUCH cleaner. > > > > I also updated the patch-set for the fusefs kernel for 9-stable to > include > > all of the changes to head. (Well, all that are appropriate to > 9-stable.) I > > can post it if anyone is interested. It's nearly identical to the stuff > > for head. > > Sure that is interesting please post it somewhere :) > > regards, > Bapt > This is really Attilio's work. I just updated his patch to apply cleanly on today's (OK, yesterday's) 9-stable and to include all updates to head that could be applied to 9. One set of updates to fuse_io.c and fuse_vnops.c that switched to wlock locks could not be included as they require the changes to that only exist in head. It also has the updates to fuse_kernel.h that broke things rolled back. They match the state of head as of 253619. The patch file can be found at: https://docs.google.com/file/d/0B9QNUQlebx5UdlhPUTB4TXF6enc/edit?usp=sharing Note that I had to create the required directories before applying the patch to avoid stepping on existing files and to avoid errors when patching. I had to create /usr/src/sys/fs/fuse/ and /usr/src/sbin/mount_fusef/, though I think recent stable systems may have the latter. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 06:56:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 448E7260 for ; Fri, 26 Jul 2013 06:56:09 +0000 (UTC) (envelope-from vsityz@gmail.com) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA229282F for ; Fri, 26 Jul 2013 06:56:08 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id d17so869195eek.0 for ; Thu, 25 Jul 2013 23:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zSjKngYUKIJgZq5xbPR/XLkj3J056pjSZswooiya0qA=; b=StRmGJMpnmap8Y4gG2dY1aYjqCsq/ZcH+X9UJP3qJBIfsRzPgClWz5r4u/10ZJRp3y a2qRPTCVC2/4fq1OHXjrS3l5avjI68ktEW5eokQ553zBl7UBdnQB6JrtZiUqKEU8v/m/ mx0EM6mc+pJJA/kAEbVvzh3sdPWcvE2QuopbTeE+l70yiCTRPv70ZoLrP7Bo2GxC4GAi NLPEQntGvnfvG9zMBzz8hI8bV+9r4b6C6DTbQON3QqZdbKXEXyT0UmYaFAPoCn/BddiN BSb5Id5nxZS0skG1NiT4wewa3ZOkNN593ujmIpwxmEDZIOQlIzkJXtL6HvIGfmNI/BMm gZaQ== X-Received: by 10.14.149.141 with SMTP id x13mr46079714eej.77.1374821766924; Thu, 25 Jul 2013 23:56:06 -0700 (PDT) Received: from scorpion.kiev.ua ([46.247.180.158]) by mx.google.com with ESMTPSA id ci50sm78871699eeb.12.2013.07.25.23.56.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 23:56:05 -0700 (PDT) Message-ID: <51F21D82.8060406@gmail.com> Date: Fri, 26 Jul 2013 09:56:02 +0300 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130721 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current Subject: Re: FUSE not work. References: <51E94F09.4020109@FreeBSD.org> <51E95B4D.4030104@gmail.com> <51E96C84.3000209@FreeBSD.org> <51E97265.8040507@gmail.com> <51E9E669.3090500@FreeBSD.org> <51EAA6A3.0@FreeBSD.org> <51EFE69A.9050100@gmail.com> In-Reply-To: <51EFE69A.9050100@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 06:56:09 -0000 FUSE for ntfs is working on FreeBSD 10 Thanks! From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 08:17:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F35A2636 for ; Fri, 26 Jul 2013 08:17:13 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DADD2BA0 for ; Fri, 26 Jul 2013 08:17:13 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hj3so528779wib.4 for ; Fri, 26 Jul 2013 01:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=M4ANaU3NMWeAl2dfKLSCrDhIZjQkYQW7XWglsfYAes4=; b=tBSukjKCeVQfoVGtOQGj4+96Y3DIJLw4fd8E4P1UHXkPgrSOxZ5bzrna5L1AXVTGp3 Jn1x7g9w+OJi3TK+aF2nrWCw2prydeQfhgZIL3YTnCVvNxA/hYYtAPos/t2dG48tAeWJ yb0HaNrcSIXX1B8hw99wZ1K/V2Jut/F4T7bq6qUwrCGTffoTdPoetRjmYfS9y7BKiNgq In4IAyn6LF2tZzzzvMnvaty2/10o/t/Ofe0cDncZkoxffUyOpZLuSDW6Bn2Yk/cqJFZ7 J+X2l3VGZgQ+9/DUodN8b04zpMpIzN08wRMr0n5cTjd6IzFOYHZfgvLRG4tT4JkhV3iu faeA== MIME-Version: 1.0 X-Received: by 10.194.87.9 with SMTP id t9mr35277876wjz.39.1374826631974; Fri, 26 Jul 2013 01:17:11 -0700 (PDT) Received: by 10.216.82.70 with HTTP; Fri, 26 Jul 2013 01:17:11 -0700 (PDT) Date: Fri, 26 Jul 2013 12:17:11 +0400 Message-ID: Subject: [patch] expand_number(3): check strtoumax(3) for ERANGE From: Sergey Kandaurov To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 08:17:14 -0000 Hi, As of now expand_number(3) does not properly check too large data. It currently handles errors only for prefixed values. (an argument is intentionally signed to be closer to the real buggish world, e.g. as it's currently done in truncate(1). This should not compile, though see bsd.sys.mk@169723). int64_t sz; if (expand_number(argv[1], &sz) < 0) err(1, "expand_number"); printf("%ld\n", sz); [pluknet@omg] ./expand_number 8000p 9007199254740992000 [pluknet@omg] ./expand_number 9000p -8313644912125935616 [pluknet@omg] ./expand_number 19000p expand_number: expand_number: Result too large [pluknet@omg] ./expand_number 0x7fffffffffffffff (INT64_MAX) 9223372036854775807 [pluknet@omg] ./expand_number 0xffffffffffffffff (UINT64_MAX) -1 But [pluknet@omg] ./expand_number 0xfffffffffffffffff (> UINT64_MAX) -1 (actually UINTMAX_MAX expressed as signed) This is how it should work: [pluknet@omg] ./expand_number 0xfffffffffffffffff (> UINT64_MAX) expand_number: expand_number: Result too large Index: lib/libutil/expand_number.c =================================================================== --- lib/libutil/expand_number.c (revision 253546) +++ lib/libutil/expand_number.c (working copy) @@ -55,6 +55,10 @@ number = strtoumax(buf, &endptr, 0); + if (number == UINTMAX_MAX && errno == ERANGE) { + return (-1); + } + if (endptr == buf) { /* No valid digits. */ errno = EINVAL; -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 12:12:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A578AAC2 for ; Fri, 26 Jul 2013 12:12:31 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6422B2564 for ; Fri, 26 Jul 2013 12:12:31 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1V2gsg-0000XJ-E8 for freebsd-current@freebsd.org; Fri, 26 Jul 2013 15:12:22 +0300 Date: Fri, 26 Jul 2013 15:12:22 +0300 From: Vitalij Satanivskij To: freebsd-current@freebsd.org Subject: Memory leack in Wired? Message-ID: <20130726121222.GA1220@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 12:12:31 -0000 Hello Some time ago, after update system on several servers I'm notice strange memory behavior For example Mem: 1245M Active, 937M Inact, 4093M Wired, 13M Cache, 1670M Free ARC: 495M Total, 50M MFU, 192M MRU, 17M Anon, 29M Header, 208M Other For zfs configures is vm.kmem_size="3G" vfs.zfs.arc_max="2G" vfs.zfs.arc_min="1G" prefetcher disabled. All machines have zfs only fs. Wired slowly grow until processes begin killed by "out of swap". Stoping all active software, unmount and export main zfs pool's (with dbs or another kind of data) don't free any memory. That's behavior notice on current begin from May. Older system eg r245701 working just fine. Untile 18/07/2013 (last system upgrade) no change in behavior. Memory usage grow very slowly on system with 32gb around two-there weeks. First it ets all free memory, than begin eating zfs arc memory, and than we must reboot machine. First question - hove to detect is it realy problem (vmstat -m don't tell any sumsystem to eat memory) and for what this memory allocated? Second - is anybody have similar problem ? From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 12:35:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 91B56754 for ; Fri, 26 Jul 2013 12:35:00 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5747027DB for ; Fri, 26 Jul 2013 12:35:00 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V2hEX-000Myd-QP for freebsd-current@freebsd.org; Fri, 26 Jul 2013 14:34:58 +0200 Message-ID: <51F26CEB.9010200@dumbbell.fr> Date: Fri, 26 Jul 2013 14:34:51 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130626 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: 802.1X: dhclient started before the auth. process ends X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2BMBCNEPAFULXSHJHNGEE" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 12:35:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2BMBCNEPAFULXSHJHNGEE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi! At $WORK, we use 802.1X to authenticate computers on the network. Authenticated computers receive a lease in the 192.168.X.X/24 network. Unauthenticated ones receive a lease in the 172.16.X.X/24 network. Today, I upgraded one computer running 10-CURRENT to latest HEAD and it seems that the interface is brought up to early now: dhclient is started before wpa_supplicant finishes. This was working perfectly before the upgrade. I don't have logs of the working case, but here are the logs of the non-working one: http://pastebin.com/ZHcbHLQZ Was I lucky with wpa_supplicant/dhclient timing? Or is there a real issue here? --=20 Jean-S=E9bastien P=E9dron ------enig2BMBCNEPAFULXSHJHNGEE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHybPEACgkQa+xGJsFYOlPOIQCgtDCZQXINxJlAYUg8ApR9C0o+ 0L8AoMuriXOvvN1ewpQkyPj0GpTuUwd3 =0C/m -----END PGP SIGNATURE----- ------enig2BMBCNEPAFULXSHJHNGEE-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 14:40:26 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 19323FF9; Fri, 26 Jul 2013 14:40:26 +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 F052B2EC0; Fri, 26 Jul 2013 14:40:24 +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 RAA27064; Fri, 26 Jul 2013 17:40:23 +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 1V2jBu-000IA3-So; Fri, 26 Jul 2013 17:40:22 +0300 Message-ID: <51F28A33.7040209@FreeBSD.org> Date: Fri, 26 Jul 2013 17:39:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current , freebsd-stable List Subject: [HEADS UP] change in devfs path matching logic X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 14:40:26 -0000 I have just committed a significant change to devfs path matching logic http://svnweb.freebsd.org/changeset/base/253677 Jaakko Heinonen (jh@) has full credit for the code while I have full responsibility for any consequences of the commit. Before this change the logic of matching the devfs paths to the patterns in devfs rules was quite arcane. Now this logic should be much simpler and logical (sorry for tautology). Please note that nothing changes with respect to matching simple paths like /dev/something. It is the complex paths that involve subdirectories that are affected. I think that if you knew how the old logic worked and were able to devise rules for it, then you will have no problem to change those rules for the new logic. Just please don't forget to do it when you upgrade! I hope that overall you will find this change to be an improvement. P.S. I notify stable@ because I currently plan to MFC this change after 1 month period. If you know a reason why the MFC should not be done, please alert me to it. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 15:03:48 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 05A8EB63 for ; Fri, 26 Jul 2013 15:03:48 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id BEFCA2037 for ; Fri, 26 Jul 2013 15:03:47 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3A8517300A; Fri, 26 Jul 2013 17:01:32 +0200 (CEST) Date: Fri, 26 Jul 2013 17:01:32 +0200 From: Luigi Rizzo To: FreeBSD Current Subject: any need to "undo" a selrecord() ? Message-ID: <20130726150132.GA74293@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 15:03:48 -0000 hi, in an attempt to simplify the locking in netmap, i would like to code the poll handler along these lines netmap_poll() { ... /* PART1 */ revents = 0; /* see if any of the rings has data */ for (i = first_ring; i < last_ring; i++) { na->nm_txsync(ifp, i, 1); /* check for space */ if (kring->ring->avail > 0) revents |= POLLOUT; } if (!(revents & POLLOUT)) { selrecord(td, main_wq); /* apparently not, want wakeup */ } /* PART2 */ /* but then retry in case someone new data comes in */ for (i = first_ring; i < last_ring; i++) { na->nm_txsync(ifp, i, 1); /* check for space */ if (kring->ring->avail > 0) revents |= POLLOUT; } ... } The tx interrupt service routine would only do a *_tx_interrupt() { ... selwakeuppri(main_wq, PI_NET); ... } The existing code does not have the PART2 block, and wraps both "PART1" and the selwakeuppri() in a lock/unlock pair, so there is no race between the txsync()/test/selrecord() and selwakeup(). But the nesting of locks (*_txsync() has its own lock) complicates the code a lot, especially when attaching NICs and VALE switches, not to mention that PART1 can be fairly time consuming so I don't want other threads to spin waiting for it to finish. Hence i am willing to pay the cost of a retry phase and remove the "external" lock. My concern is whether i should do something to "undo" the selrecord() in case i find that some queue is available in the retry phase. Probably not (since the same problem would occur if another file descriptor becomes ready), but just wanted to be sure. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 15:08:45 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1FD25EB0; Fri, 26 Jul 2013 15:08:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB05208D; Fri, 26 Jul 2013 15:08:43 +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 SAA27281; Fri, 26 Jul 2013 18:08:42 +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 1V2jdK-000ICZ-7H; Fri, 26 Jul 2013 18:08:42 +0300 Message-ID: <51F290C2.3090808@FreeBSD.org> Date: Fri, 26 Jul 2013 18:07:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current , freebsd-stable List Subject: Re: [HEADS UP] change in devfs path matching logic References: <51F28A33.7040209@FreeBSD.org> In-Reply-To: <51F28A33.7040209@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 15:08:45 -0000 on 26/07/2013 17:39 Andriy Gapon said the following: > Please note that nothing changes with respect to matching simple paths like > /dev/something. I must add: and thus rules in etc/defaults/devfs.rules should not be affected except for their unintended side-effects. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jul 26 21:15:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 999831A2 for ; Fri, 26 Jul 2013 21:15:22 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm41-vm4.bullet.mail.bf1.yahoo.com (nm41-vm4.bullet.mail.bf1.yahoo.com [216.109.114.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 419982095 for ; Fri, 26 Jul 2013 21:15:21 +0000 (UTC) Received: from [98.139.214.32] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jul 2013 21:12:08 -0000 Received: from [98.139.213.10] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jul 2013 21:12:08 -0000 Received: from [127.0.0.1] by smtp110.mail.bf1.yahoo.com with NNFMP; 26 Jul 2013 21:12:08 -0000 X-Yahoo-Newman-Id: 834922.29077.bm@smtp110.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 62PnGkAVM1kDyztN4sjqbpMvZxztzqg065BndtkySBNPVCK vttClF3dOJYnKwAZ.hMx0XAwRf39xCq_qeID1Bg1uEvbdX4Az8Aca1zJc76e n38oPwwoGUFTvgU8tp8ZR148J5JQ80zc08QcTTU9wPu8xfqFb0sfN5dLNi28 89Z17_TJwKLQ0AloNv4HkNRb3qy0SuFFTA7eS9MG3j4BoMevlwk5_vVvGuOr A8FBykgnKQ9PK8dlqezTyz7wWF2p7Hqp9TFIzLYDtKG2X5ylpg4QW4GjsKLr 5GRl68nctKIctsF8OvxrXcZN5zMVBHDeFM3JFnlDKxD7UKmrIFD8.c5vETvv afhHOsRumXCmWxLEcYZBAqUphR9LHzp7ym5SvJhwH1otCevnZ6wGkfqOA1fQ kuHisaacN_rLRwQJfOwn30eXsO8xndCY8VG2riUDIHADyla7loJzGXXYqYi1 y3Yyrf3EdqMYsB4Gm2m35usCzA3trGn45HTGIOcjS3kzW1g2fm8.dy7bdNhM US5OHdP5fV7jXB0ANLGOOByEeoQ-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp110.mail.bf1.yahoo.com with SMTP; 26 Jul 2013 14:12:08 -0700 PDT Message-ID: <51F2E627.9090907@FreeBSD.org> Date: Fri, 26 Jul 2013 16:12:07 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current Subject: [Heads up] BSD-licensed patch becoming the default RSN. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 26 Jul 2013 21:15:22 -0000 Hello; After an exp-run it was found that only two ports presented regressions with the new BSD-licensed patch derived from Open/DragonFly BSD. The issue was related to some patch level detection the previous GNU patch has and the new patch lacks. Otherwise both versions are basically equivalent. Both ports affected have been fixed to use the specific patch levels so we can throw the switch now. The new patch has been rather well tested, and (a derivative) is already the default on the other BSDs, but you never know so a new WITH_GNU_PATCH option will be available to aid the transition. Enjoy! Pedro. From owner-freebsd-current@FreeBSD.ORG Sat Jul 27 01:02:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E5D04B9A; Sat, 27 Jul 2013 01:02:26 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from outgoing.tormail.org (outgoing.tormail.org [82.221.96.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 984D129F9; Sat, 27 Jul 2013 01:02:24 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=internal.tormail.org) by outgoing.tormail.org with esmtp (Exim 4.72) (envelope-from ) id 1V2stn-0002Gy-OB; Sat, 27 Jul 2013 05:02:20 +0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:Date:X-TorMail-User:Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From; bh=jVHwJLu9CxjduCVO73s5uGBx3YRIC2/54WLIBnYqWRc=; b=kaVdlqg5Y5pctpF+hrmpa/R2e5N9ONglz8Zkuc6pyChY5IJmm7of4uFV57AwmheLtvm5PhpCr+l7ggHexYwJomzhCwMpkZMLsbjOPohGj+5gFMUYybqZQhsyfrsGCn7W9mog07LqkOQIsEUr2FkGmVtYB2WUBHOdE/HlQC4mnbs=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1V2ssp-000Nrk-Q8; Sat, 27 Jul 2013 01:01:21 +0000 From: Jan Beich To: Pedro Giffuni Subject: Re: [Heads up] BSD-licensed patch becoming the default RSN. In-Reply-To: <51F2E627.9090907@FreeBSD.org> (Pedro Giffuni's message of "Fri, 26 Jul 2013 16:12:07 -0500") References: <51F2E627.9090907@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Date: Sat, 27 Jul 2013 01:01:21 +0000 Message-Id: <1V2ssp-000Nrk-Q8@internal.tormail.org> Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Jul 2013 01:02:27 -0000 bsdpatch doesn't list files of the failed hunks with -C and -s option. This may be less convenient if you edit a patch directly rather than regen it after polluting the tree. $ patch -CEfsp0 -i /path/to/varsym.diff 1 out of 1 hunks failed 1 out of 2 hunks failed 2 out of 2 hunks failed 1 out of 5 hunks failed 1 out of 1 hunks failed 1 out of 1 hunks failed 1 out of 1 hunks failed zsh: exit 1 $ gnupatch -CEfsp0 -i /path/to/varsym.diff 1 out of 1 hunks failed--saving rejects to contrib/openbsm/etc/audit_event.rej 1 out of 2 hunks failed--saving rejects to lib/libc/sys/Makefile.inc.rej 2 out of 2 hunks failed--saving rejects to sys/security/audit/audit_private.h.rej 1 out of 5 hunks failed--saving rejects to sys/security/audit/audit.h.rej 1 out of 1 hunks failed--saving rejects to sys/bsm/audit_kevents.h.rej 1 out of 1 hunks failed--saving rejects to sys/kern/syscalls.master.rej 1 out of 1 hunks failed--saving rejects to sys/sys/priv.h.rej zsh: exit 8 From owner-freebsd-current@FreeBSD.ORG Sat Jul 27 01:32:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0D7D3EED for ; Sat, 27 Jul 2013 01:32:18 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm7-vm4.bullet.mail.gq1.yahoo.com (nm7-vm4.bullet.mail.gq1.yahoo.com [98.136.218.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A1D6B2B1A for ; Sat, 27 Jul 2013 01:32:17 +0000 (UTC) Received: from [216.39.60.180] by nm7.bullet.mail.gq1.yahoo.com with NNFMP; 27 Jul 2013 01:29:45 -0000 Received: from [208.71.42.204] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 27 Jul 2013 01:29:45 -0000 Received: from [127.0.0.1] by smtp215.mail.gq1.yahoo.com with NNFMP; 27 Jul 2013 01:29:45 -0000 X-Yahoo-Newman-Id: 740697.53523.bm@smtp215.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: G3hCB8oVM1k8lbmrWiJLJd8nTIQpBw7wFApdRahBwHGUwjN J93CKH4T6ZtSUJLuz0I93VyanY6lidBmdqDGf4A1PZDMrd2EFRTztp0WxRWi 706P5lghOAnyz4JCGw7bZl0EBju9zTz3UA_t4H_w5tpd_kpgTmKlYywJa71P 3F_fJ4BMdik_eTK1gNkQZGEuHM4y6t5gXN1YbJlS2bV94bDg2UurP2srp7ag FMV8zVoLMDzV7PsIc3OW6YLdFeC0xQ94UrJZS8pg5tmMXeRIq6ul3yIMEOkx h300TaUYNVMCIMZu72ajF.4qw9v1flli8FzQy6fknUWny.i16U9zX8iM1Kjn Z70dwq593P0JwVr1Z0PQF.k8GxfN1sX4S_lJpYaXOTVlgoYuoM..G0FVrITX wKT0ZVKsnUXtQcQstxTLcjeaYjWi92RjNtZHA8iq.H.WUn18JgO.sNgJ7YXn ZBh0vIWIVLjwzm1xXVyjHLTqgPywAKEV8WMl2lIij0fhArcNvBQwEoZSWvJe dHm.OeCly4ZF4YqquZY6tQufR_UTQvKE- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp215.mail.gq1.yahoo.com with SMTP; 26 Jul 2013 18:29:45 -0700 PDT Message-ID: <51F32288.7050701@FreeBSD.org> Date: Fri, 26 Jul 2013 20:29:44 -0500 From: Pedro Giffuni Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jan Beich Subject: Re: [Heads up] BSD-licensed patch becoming the default RSN. References: <51F2E627.9090907@FreeBSD.org> <1V2ssp-000Nrk-Q8@internal.tormail.org> In-Reply-To: <1V2ssp-000Nrk-Q8@internal.tormail.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Jul 2013 01:32:18 -0000 Hi Jan; El 26/07/2013 8:01 p. m., Jan Beich escribió: > bsdpatch doesn't list files of the failed hunks with -C and -s option. > This may be less convenient if you edit a patch directly rather than > regen it after polluting the tree. > > $ patch -CEfsp0 -i /path/to/varsym.diff > 1 out of 1 hunks failed > 1 out of 2 hunks failed > 2 out of 2 hunks failed > 1 out of 5 hunks failed > 1 out of 1 hunks failed > 1 out of 1 hunks failed > 1 out of 1 hunks failed > zsh: exit 1 > > $ gnupatch -CEfsp0 -i /path/to/varsym.diff > 1 out of 1 hunks failed--saving rejects to contrib/openbsm/etc/audit_event.rej > 1 out of 2 hunks failed--saving rejects to lib/libc/sys/Makefile.inc.rej > 2 out of 2 hunks failed--saving rejects to sys/security/audit/audit_private.h.rej > 1 out of 5 hunks failed--saving rejects to sys/security/audit/audit.h.rej > 1 out of 1 hunks failed--saving rejects to sys/bsm/audit_kevents.h.rej > 1 out of 1 hunks failed--saving rejects to sys/kern/syscalls.master.rej > 1 out of 1 hunks failed--saving rejects to sys/sys/priv.h.rej > zsh: exit 8 > Very interesting, thank you! Now, just some food for thought, but if you are unsure your patch applies cleanly, why would you choose to use the -s (silent) option? It would seem to me that some people may want the -s option to be truly silent (those paths may be long) and since those .rej files are not really being created it is consistent not to list them. FWIW, one thing that I have been thinking is that it may make sense to update gnupatch to the latest GPLv2 version and decide later when to drop it. Regards, Pedro. From owner-freebsd-current@FreeBSD.ORG Sat Jul 27 02:13:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E051B20A; Sat, 27 Jul 2013 02:13:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A43682BCB; Sat, 27 Jul 2013 02:13:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6R1qen9060612; Fri, 26 Jul 2013 21:52:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6R1qeR2060578; Sat, 27 Jul 2013 01:52:40 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 27 Jul 2013 01:52:40 GMT Message-Id: <201307270152.r6R1qeR2060578@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 , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 02:13:25 -0000 TB --- 2013-07-27 00:52:38 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-27 00:52:38 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-27 00:52:38 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-07-27 00:52:38 - cleaning the object tree TB --- 2013-07-27 00:52:38 - /usr/local/bin/svn stat /src TB --- 2013-07-27 00:52:57 - At svn revision 253687 TB --- 2013-07-27 00:52:58 - building world TB --- 2013-07-27 00:52:58 - CROSS_BUILD_TESTING=YES TB --- 2013-07-27 00:52:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-27 00:52:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-27 00:52:58 - SRCCONF=/dev/null TB --- 2013-07-27 00:52:58 - TARGET=pc98 TB --- 2013-07-27 00:52:58 - TARGET_ARCH=i386 TB --- 2013-07-27 00:52:58 - TZ=UTC TB --- 2013-07-27 00:52:58 - __MAKE_CONF=/dev/null TB --- 2013-07-27 00:52:58 - cd /src TB --- 2013-07-27 00:52:58 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Jul 27 00:53:06 UTC 2013 >>> 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 [...] ranlib libllvmtransformutils.a ===> lib/clang/libllvmvectorize (all) c++ -O2 -pipe -I/src/lib/clang/libllvmvectorize/../../../contrib/llvm/include -I/src/lib/clang/libllvmvectorize/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmvectorize/../../../contrib/llvm/lib/Transforms/Vectorize -I. -I/src/lib/clang/libllvmvectorize/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmvectorize/../../../contrib/llvm/lib/Transforms/Vectorize/BBVectorize.cpp -o BBVectorize.o /src/lib/clang/libllvmvectorize/../../../contrib/llvm/lib/Transforms/Vectorize/BBVectorize.cpp: In member function 'void::BBVectorize::findBestDAGFor(llvm::DenseMap >, llvm::DenseMapInfo >&, llvm::DenseSet, llvm::DenseMapInfo > >&, llvm::DenseMap, int, llvm::DenseMapInfo > >&, std::vector >&, llvm::DenseSet, llvm::DenseMapInfo > >&, llvm::DenseMap, std::pair >, unsigned int, llvm::DenseMapInfo, std::pair > > >&, llvm::DenseMap, std:! :vector, std::allocator > >, llvm::DenseMapInfo > >&, llvm::DenseMap, std::vector, std::allocator > >, llvm::DenseMapInfo > >&, llvm::DenseSet, llvm::DenseMapInfo > >&, llvm::DenseMap, std::vector, std::allocator > >, llvm::DenseMapInfo > >&, llvm::DenseSet, std::pair >, llvm::DenseMapInfo, std::pair > > >&, llvm::DenseMap >&, llvm::DenseSet! , llvm::DenseMapInfo > >&, size_t&, int&, llvm::Value*, std::vector >&, bool)': /src/lib/clang/libllvmvectorize/../../../contrib/llvm/lib/Transforms/Vectorize/BBVectorize.cpp:1735: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake: stopped in /src/lib/clang/libllvmvectorize *** Error code 1 Stop. bmake: stopped in /src/lib/clang *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-27 01:52:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-27 01:52:39 - ERROR: failed to build world TB --- 2013-07-27 01:52:39 - 3149.34 user 332.86 system 3601.48 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 27 04:07:49 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2DF00630 for ; Sat, 27 Jul 2013 04:07:49 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A06A825AD for ; Sat, 27 Jul 2013 04:07:48 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r6R47She005319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 27 Jul 2013 13:07:39 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r6R47QN8069981 for ; Sat, 27 Jul 2013 13:07:28 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 27 Jul 2013 13:06:41 +0900 (JST) Message-Id: <20130727.130641.1045344958497890348.hrs@allbsd.org> To: current@FreeBSD.org Subject: NMI on shutdown From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Jul_27_13_06_41_2013_678)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sat, 27 Jul 2013 13:07:39 +0900 (JST) X-Spam-Status: No, score=-89.6 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,FAKEDWORD_ONE,FAKEDWORD_VERTICALLINE,RCVD_IN_PBL, SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Jul 2013 04:07:49 -0000 ----Security_Multipart(Sat_Jul_27_13_06_41_2013_678)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, The following log messages are displayed on a box where I am testing stable/9. It occurs only when trying to shutdown the box: | Waiting (max 60 seconds) for system process `vnlru' to stop...done | Waiting (max 60 seconds) for system process `bufdaemon' to stop...done | Waiting (max 60 seconds) for system process `syncer' to stop... | Syncing disks, vnodes remaining...2 2 0 0 done | All buffers synced. | Uptime: 8d2h4m58s | NMI ISA 30, EISA 0 | NMI ISA 20, EISA 0 | NMI ... going to debugger | NMI ... going to debugger | NMI ISA 20, EISA 0 | NMI ISA 30, EISA 0 | NMI ... going to debugger | NMI ... going to debugger | NMI ISA 20, EISA 0 ... | timeout stopping cpus | [ thread pid 11 tid 100016 ] | Stopped at acpi_cpu_c1+0x6: leave | db> timeout stopping cpus | timeout stopping cpus | [ thread pid 11 tid 100015 ] | Stopped at acpi_cpu_c1+0x6: leave | db> timeout stopping cpus | timeout stopping cpus Once these are displayed, a power cycle is required to recover. Shutdown sometimes works, and sometimes not. DDB prompt does not work because it does not accept entered characters properly. And, this symptom seems not specific to stable/9. This may be a hardware specific issue, but where should I start to debug this from? -- Hiroki ----Security_Multipart(Sat_Jul_27_13_06_41_2013_678)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHzR1EACgkQTyzT2CeTzy3K7gCeMR5BBWTULotF10UmNg6AhD9K KdcAoKTkdRDEWrpyOCFMdd1aTtluRGYq =AK9z -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Jul_27_13_06_41_2013_678)---- From owner-freebsd-current@FreeBSD.ORG Sat Jul 27 04:12:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 09F1377B; Sat, 27 Jul 2013 04:12:12 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from outgoing.tormail.org (outgoing.tormail.org [82.221.96.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0D3925D5; Sat, 27 Jul 2013 04:12:11 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=internal.tormail.org) by outgoing.tormail.org with esmtp (Exim 4.72) (envelope-from ) id 1V2vrU-0002f7-Jo; Sat, 27 Jul 2013 08:12:09 +0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:Date:X-TorMail-User:Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From; bh=sGl6HP6GNE8Afwawg9HnJWe+KxdCvICD8B0lh201Gg0=; b=ItRP6u2vCVaptWvW4fbhml3UqA3OqR/3Hcf5sjq6TZu1sHi0VccbRuvhF/ebMtyYOjG9IqeWSpWDFZBEBgQKxdSpD4JhzFX428nu8ykt6O8/KAvN3YOs6ahY8pllW5rTPZ4NFPdxvIFTNmtwmuXFcBzmCW8Hzux457uyxZdd1oE=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1V2vqT-000JNd-DJ; Sat, 27 Jul 2013 04:11:06 +0000 From: Jan Beich To: Pedro Giffuni Subject: Re: [Heads up] BSD-licensed patch becoming the default RSN. In-Reply-To: <51F32288.7050701@FreeBSD.org> (Pedro Giffuni's message of "Fri, 26 Jul 2013 20:29:44 -0500") References: <51F2E627.9090907@FreeBSD.org> <1V2ssp-000Nrk-Q8@internal.tormail.org> <51F32288.7050701@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Date: Sat, 27 Jul 2013 04:11:06 +0000 Message-Id: <1V2vqT-000JNd-DJ@internal.tormail.org> Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Jul 2013 04:12:12 -0000 Pedro Giffuni writes: > Now, just some food for thought, but if you are unsure your patch > applies cleanly, why would you choose to use the -s (silent) option? Because by default patch(1) is overly verbose. At first, I'm only interested if a patch applies cleanly, then what files fail to apply. To fix the patch I just repeat over edit a hunk (or two) and confirm patch(1) no longer rejects it. With -Cs giving up is easy at any time. One may not care about a failed hunk in a man page or prefer to edit a patch as the whole instead of on per-file (.rej file) basis. > It would seem to me that some people may want the -s option to be > truly silent (those paths may be long) and since those .rej files are > not > really being created it is consistent not to list them. If you need -s to be truly silent then you're probably writing a script. At which point -C being a BSD extension and -s behaving differently from GNU patch would make more pain than not using them. A new option may be better e.g., -q, --quiet Do not write anything to standard output. Exit immediately with non-zero status if any hunk fails to apply. From owner-freebsd-current@FreeBSD.ORG Sat Jul 27 14:50:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9A3D8D82 for ; Sat, 27 Jul 2013 14:50:56 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm26-vm6.bullet.mail.ne1.yahoo.com (nm26-vm6.bullet.mail.ne1.yahoo.com [98.138.91.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 42FCD288D for ; Sat, 27 Jul 2013 14:50:56 +0000 (UTC) Received: from [98.138.226.179] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 27 Jul 2013 14:48:06 -0000 Received: from [98.138.84.41] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 27 Jul 2013 14:48:06 -0000 Received: from [127.0.0.1] by smtp109.mail.ne1.yahoo.com with NNFMP; 27 Jul 2013 14:48:06 -0000 X-Yahoo-Newman-Id: 103804.50300.bm@smtp109.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pQFWW8cVM1lU3_o3fS6bR2W_jn54wtv7L.i6X.Qs.FOsVuE iPXmGevMvGdGHREo5b8TZigH5JFuPtletDx7XZUXksY7XynwAr7TULIzTtne WCRFSqsZbEyEXxvvhqDCNJqgjXZuBcJtHpSqDHiP3Vyq5xunbodF2fUeW_xu IotY0N5DpaGAWh.nNX5h8Y3OYBvEhChIOXQ7bOJJ1Dnx7Fj0Cif6zr3JI56g fXR.dHq8oqK7xr13U2_iHvRTLpcq3wYISfsHl8sJrmvNBA7Gmh4.h.Cp_88H Jal7kjYKC_WW8wq9xnpz_cab.5lKDnef0MCoYU1te1xMDHZe6E_aTam2lLtz tMWW3baDAB6rXeXDaePqKU0i6dFpGhc1FO9LCPh7mAsYVCRaAERN6.HRh70s cHtJCtuIgQaLIEbGPEJGl1EYNVITsYuutAdunsz0nsqZVOB.DI2YgLfcePPy 4t.m0MCNYpMMfaR4S2gNwEDC95f.UyM4Xd_672jac.BmUQIEfiWuMwr8NCIg 4_w79VSvgCGxHjCw- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp109.mail.ne1.yahoo.com with SMTP; 27 Jul 2013 07:48:05 -0700 PDT Message-ID: <51F3DDA3.8010606@FreeBSD.org> Date: Sat, 27 Jul 2013 09:48:03 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jan Beich Subject: Re: [Heads up] BSD-licensed patch becoming the default RSN. References: <51F2E627.9090907@FreeBSD.org> <1V2ssp-000Nrk-Q8@internal.tormail.org> <51F32288.7050701@FreeBSD.org> <1V2vqT-000JNd-DJ@internal.tormail.org> In-Reply-To: <1V2vqT-000JNd-DJ@internal.tormail.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Jul 2013 14:50:56 -0000 On 26.07.2013 23:11, Jan Beich wrote: > Pedro Giffuni writes: > >> Now, just some food for thought, but if you are unsure your patch >> applies cleanly, why would you choose to use the -s (silent) option? > Because by default patch(1) is overly verbose. At first, I'm only > interested if a patch applies cleanly, then what files fail to apply. > To fix the patch I just repeat over edit a hunk (or two) and confirm > patch(1) no longer rejects it. > > With -Cs giving up is easy at any time. One may not care about > a failed hunk in a man page or prefer to edit a patch as the whole > instead of on per-file (.rej file) basis. I would tend to do -Cs just to see if it applies cleanly or not and if there is a failure then do -C to see the failure. Actually I always use -C from the start. In any case, I find it reasonable to want to preserve the GNU patch behaviour. The code is rather simple so I would encourage other interested people to look at it, or I will look at it at a later time. Pedro. From owner-freebsd-current@FreeBSD.ORG Sat Jul 27 15:08:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E899C2F9 for ; Sat, 27 Jul 2013 15:08:26 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 710DD292C for ; Sat, 27 Jul 2013 15:08:26 +0000 (UTC) Received: from [98.139.212.152] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 27 Jul 2013 15:08:19 -0000 Received: from [98.139.213.9] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 27 Jul 2013 15:08:19 -0000 Received: from [127.0.0.1] by smtp109.mail.bf1.yahoo.com with NNFMP; 27 Jul 2013 15:08:19 -0000 X-Yahoo-Newman-Id: 170996.99060.bm@smtp109.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1l4IKDEVM1kOzMyvfo61.BF9i6.N55Y3mtlN0Mgw6NcsGHr yrNgyFOdY4GJrz2lSH4WnOhwsBHXbiqS3cVlz5x80bskNmVV0b2x8iCklNNi a6ckFmFSElSH9MtAw6TVF_m3GLZF1dVmiioJbDWtkMxnxsMQXyTkSiPVHJoY 4YEv1lIat8Pz17mam78OWRyBZqVmuTBNqdR7Fs7CweD55bm94jKV8TOwi4Dj qhztsA3UMWWugov1YqcXwFWIihitrD3cJdjGQbLVKWAFTih8CZmy6SMRffnn 63zxTO96o51ynej5j9zTSUdwsKTMiAcMEOUrpnseyCiOYwQG.GH_a8SYpslm jRLl90DwEUt7bFraL2WnmYnLMqrNrJ_eskn6tYBIfiOK1lMjLscBzZL3D1qf WPpQrzRxA..TyGLH.WnPWrf6Hs52aT.9pWh.eTnsjVP3YcaT7MjgrxFh4t.m DTpdNQa1GStwnQMBmxw71K0GpV6pXay64GQtL1QdA4U.KLA9AV2E_xd2Qygf MIoYcSy1hl1DEhH3jykGihTcKnZauRwCx9GX3uAIFBZpUE0zwzx.TuP9DllC 7pxw._fml_Z3VjmR7_21IemkNVkkw8U82opG.sRQ6_9HxqMnrMDXvXAHv6mx kDnxee6z2C2EqywhUfDzUad0JC2F4.ho0jDGt4_PQV_tQ9YEQhktoz8Dndf_ NqrIWxYNCmig9e08ul.V9cq2hgebuZUVM7.zzsE64oXCSvRxFCG1y.RrBQL0 5pGiJArK9MvKeE_F4_bn6KJQ5DQ-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp109.mail.bf1.yahoo.com with SMTP; 27 Jul 2013 08:08:19 -0700 PDT Message-ID: <51F3E261.9090903@FreeBSD.org> Date: Sat, 27 Jul 2013 10:08:17 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jan Beich Subject: Re: [Heads up] BSD-licensed patch becoming the default RSN. References: <51F2E627.9090907@FreeBSD.org> <1V2ssp-000Nrk-Q8@internal.tormail.org> In-Reply-To: <1V2ssp-000Nrk-Q8@internal.tormail.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Xin Li X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Jul 2013 15:08:27 -0000 OK; On further revision ... On 26.07.2013 20:01, Jan Beich wrote: > bsdpatch doesn't list files of the failed hunks with -C and -s option. > This may be less convenient if you edit a patch directly rather than > regen it after polluting the tree. > > $ patch -CEfsp0 -i /path/to/varsym.diff > 1 out of 1 hunks failed > 1 out of 2 hunks failed > 2 out of 2 hunks failed > 1 out of 5 hunks failed > 1 out of 1 hunks failed > 1 out of 1 hunks failed > 1 out of 1 hunks failed > zsh: exit 1 > > $ gnupatch -CEfsp0 -i /path/to/varsym.diff > 1 out of 1 hunks failed--saving rejects to contrib/openbsm/etc/audit_event.rej > 1 out of 2 hunks failed--saving rejects to lib/libc/sys/Makefile.inc.rej > 2 out of 2 hunks failed--saving rejects to sys/security/audit/audit_private.h.rej > 1 out of 5 hunks failed--saving rejects to sys/security/audit/audit.h.rej > 1 out of 1 hunks failed--saving rejects to sys/bsm/audit_kevents.h.rej > 1 out of 1 hunks failed--saving rejects to sys/kern/syscalls.master.rej > 1 out of 1 hunks failed--saving rejects to sys/sys/priv.h.rej > zsh: exit 8 The change came from OpenBSD, which took it from DragonFlyBSD: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/patch/patch.c.diff?r1=1.49;r2=1.50 It was merged as part of some OpenBSD syncing in patch.c http://svnweb.freebsd.org/base?view=revision&revision=246091 Cheers, Pedro. From owner-freebsd-current@FreeBSD.ORG Sat Jul 27 16:33:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 801CC4B4 for ; Sat, 27 Jul 2013 16:33:18 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm34-vm8.bullet.mail.bf1.yahoo.com (nm34-vm8.bullet.mail.bf1.yahoo.com [72.30.239.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F09E02BB4 for ; Sat, 27 Jul 2013 16:33:17 +0000 (UTC) Received: from [98.139.212.146] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 27 Jul 2013 16:33:16 -0000 Received: from [68.142.230.71] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 27 Jul 2013 16:33:16 -0000 Received: from [127.0.0.1] by smtp228.mail.bf1.yahoo.com with NNFMP; 27 Jul 2013 16:33:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1374942796; bh=2TE1dDfD06fmu2+6MeVbcJuMaW5WX/Is+fi9QwzQ7aM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=FiUsAI/jOB1xqC0/XLpDtCSpMPiSgU1y0dMQiSRoFOK3/04wIa8srz3tCTfbCZy83iJw726XpY3ouW2HecLHVcb3gThTfFAhw1h/gYb3DIWfsKiLDsnaeOoUcBsaup+86hNjJbAGLmhxGn51RCeqyLaDpcTi22zzhHt/HBaNv3c= X-Yahoo-Newman-Id: 243287.63868.bm@smtp228.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: H3fMaSIVM1kfrUmJKM4MGHmhgGhTTC3q8DwfXfxFk96SN6A Er2MePmM0m2GhBzTHpILR0I4M60wdF.lDv87JWI2SgMuQ4P5LC0xqJvhJtN8 3eqOVa0dV1cUtDNpK29sorxwk6gsBVFJYpiSppyuscZjkfOBWnzw3qX9t.zL RkHUJz7un7eKShodTfNtsXFssvTL0SxzH6KIGsa8cz0MogsSUxsYdBVeKMkE 08lQ2nibtOo6dLk4RgI6wouacwRxqAjMlUrVeAKWFnv9Uzfy5XdL3uIEu2wY rOo_iegDZK.SdDLPdJ8WyIG0AOzYmddurfWml3vQOCUgcADvoce9c.XAqOFd EzAdxngKZqAjUHXG18PjnhBMRMNXrzcaraeOz76DxZw8Nghm1McOxemEKwfn 4OmEpcCBqKg4_Av5ojA4IGPba6OfI25C9CqFIBt8CI7j0sofYyJ1u7pPWD4X ZgJ0w1jHK3DZFCFj.jE4cW6D3ddypWWk4FP46CwBFAMCrpYZaRbTsaSCpPsE q26VuGcfSpv5hN_U454U6T44- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [192.168.1.210] (sean_bruno@71.202.40.63 with ) by smtp228.mail.bf1.yahoo.com with SMTP; 27 Jul 2013 16:33:16 +0000 UTC Subject: Re: NMI on shutdown From: Sean Bruno To: Hiroki Sato In-Reply-To: <20130727.130641.1045344958497890348.hrs@allbsd.org> References: <20130727.130641.1045344958497890348.hrs@allbsd.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ucjGMHAx35DlMpGLoNMl" Date: Sat, 27 Jul 2013 09:33:14 -0700 Message-ID: <1374942794.1431.37.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 16:33:18 -0000 --=-ucjGMHAx35DlMpGLoNMl Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sat, 2013-07-27 at 13:06 +0900, Hiroki Sato wrote: > Hi, >=20 > The following log messages are displayed on a box where I am testing > stable/9. It occurs only when trying to shutdown the box: >=20 > | Waiting (max 60 seconds) for system process `vnlru' to stop...done > | Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > | Waiting (max 60 seconds) for system process `syncer' to stop... > | Syncing disks, vnodes remaining...2 2 0 0 done > | All buffers synced. > | Uptime: 8d2h4m58s > | NMI ISA 30, EISA 0 > | NMI ISA 20, EISA 0 > | NMI ... going to debugger > | NMI ... going to debugger > | NMI ISA 20, EISA 0 > | NMI ISA 30, EISA 0 > | NMI ... going to debugger > | NMI ... going to debugger > | NMI ISA 20, EISA 0 > ... > | timeout stopping cpus > | [ thread pid 11 tid 100016 ] > | Stopped at acpi_cpu_c1+0x6: leave > | db> timeout stopping cpus > | timeout stopping cpus > | [ thread pid 11 tid 100015 ] > | Stopped at acpi_cpu_c1+0x6: leave > | db> timeout stopping cpus > | timeout stopping cpus >=20 > Once these are displayed, a power cycle is required to recover. > Shutdown sometimes works, and sometimes not. DDB prompt does not > work because it does not accept entered characters properly. And, > this symptom seems not specific to stable/9. >=20 > This may be a hardware specific issue, but where should I start to > debug this from? >=20 > -- Hiroki :-) I just spent the week looking at something that looks like this on my Dell machines. In my testing the NMI EISA problem seems to be coming from the fact that IPMI pokes at both the ACPI and ISA interfaces to the IPMI controller resulting in an attempt to create /dev/ipmi0 and /dev/ipmi1. Somewhere in the recent past (affects 9 as well) the ACPI and ISA IPMI device nodes where children of the same parent and ipmi_isa.c::ipmi_isa_identitfy() would see the ACPI attachment and do nothing. Now the two interfaces have different parents in the device tree. On bce(4) based systems, even if not using IPMI, this seems to crash/confuse older version of the management firmware and yield results similar to what you see. I've just commited a tested fix from Yahoo on this that Peter and I worked out. see svn R 253708 Sean --=-ucjGMHAx35DlMpGLoNMl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJR8/ZDAAoJEBkJRdwI6BaHtD4H/2oEGpm8QStpMdpVPjweyAZ8 n1hONZTt2HDU8jaqfwlZ5FWhOGWhnp+Cwze57rQ8xKAzr+MCSMuhFtTICiMfkmJ+ PQZlRXMEC7H1D1SHA2EU3szdYSMcKuRbw+cFZO3GdLucd1vIbxj6grvF5tYR9c0q Sw34CIHoHCFtGnJLWXgEmVScdsWsTj/bKkkyou3swUyVhqomKSGRCqQZnEhWAuon eC+OjoPXR4k1CUWhAIYtAJVVBTgTmIcW/R4sodT56WcOeiorA4/5+JaOfrupSqFP FP2uLuMNw6h9VWRKYNuhyF3KMetFYUvj/Jd47zdIk6p/2KT1TDiwv8iC78jal9U= =NjOl -----END PGP SIGNATURE----- --=-ucjGMHAx35DlMpGLoNMl-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 27 20:54:07 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ECB8B58C; Sat, 27 Jul 2013 20:54: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 EC988249B; Sat, 27 Jul 2013 20:54:06 +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 XAA12090; Sat, 27 Jul 2013 23:53:58 +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 1V3BV0-000O9L-E7; Sat, 27 Jul 2013 23:53:58 +0300 Message-ID: <51F4332D.5020000@FreeBSD.org> Date: Sat, 27 Jul 2013 23:53:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Current Subject: GENERIC: options KDB_TRACE X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 27 Jul 2013 20:54:08 -0000 What is the reason to have the following option commented out in GENERIC in head: #options KDB_TRACE ? Wouldn't it be more helpful to have it enabled? -- Andriy Gapon