From owner-freebsd-current@FreeBSD.ORG Sun Aug 3 08:02:11 2014 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 ESMTPS id C1E96225 for ; Sun, 3 Aug 2014 08:02:11 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FD4129E5 for ; Sun, 3 Aug 2014 08:02:11 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id j5so7662747qga.15 for ; Sun, 03 Aug 2014 01:02:10 -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=lTSg1GEmdWZiWj4/RZ4LAZT5P03Rq5m90s9PE+688j0=; b=FYS/fjQAGvsgh/0mLVhkVJWzbPOfkSXrISDggNhwXVe94hlQJ6ZgjwT+/hRJqbZubR yGVkDRs8d5gSjhtaOYorLtl6iDJOjWSmXVLSW0/xR8BeKMB8XpHd7lQcUAhF3n76RPBJ q5kzaiRcMELYRaxqMDxsjLHvNr64jPLDotD9/+REGwrL1tfbVZcQKV3PAN792/0vnkJz 0VcAVMw/qqcEjhi+A6UpCWFBe5vEp66uV7Ds6os4MQ4BXTfJueNBFd+RSS0qDXN41mgb cjUWtqIttU2EnrNG6iBeaKKqbDU3T4+eDRqFHwl53Hk6Fq0JS2PkXZVraDx43g+m+htg utgA== MIME-Version: 1.0 X-Received: by 10.140.16.67 with SMTP id 61mr23905886qga.28.1407052930649; Sun, 03 Aug 2014 01:02:10 -0700 (PDT) Received: by 10.140.48.2 with HTTP; Sun, 3 Aug 2014 01:02:10 -0700 (PDT) In-Reply-To: <20140802200149.GO50495@funkthat.com> References: <20140801193403.GE50495@funkthat.com> <20140801222118.GH50495@funkthat.com> <20140802183259.GL50495@funkthat.com> <20140802200149.GO50495@funkthat.com> Date: Sun, 3 Aug 2014 10:02:10 +0200 Message-ID: Subject: Re: domain_add(xxx) after domainfinalize... From: Svatopluk Kraus To: John-Mark Gurney Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 03 Aug 2014 08:02:11 -0000 On Sat, Aug 2, 2014 at 10:01 PM, John-Mark Gurney wrote: > Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 21:27 +0200: > > On Sat, Aug 2, 2014 at 8:32 PM, John-Mark Gurney > wrote: > > > > > Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 15:20 +0200: > > > > Well, I did not look at network stack for long time, so the following > > > > things could be obsolete now, but at least: > > > > > > > > (1) There is some room left in mbuf header on its allocation, so > > > protocols > > > > (link) headers can be added in the front of data without need of > > > > reallocation or data copying. The size of the room is evaluated from > all > > > > domains at boot time. > > > > > > > > (2) All network address masks are shared among domains and protocols > in > > > > mask radix tree. The tree is created with particular key size, which > is > > > > again evaluated from all domains as maximal size of all known > addresses. > > > > > > > > So, if new domain added after these evaluations does not break both > them > > > > and some other things, there is no problem. Otherwise, some warnings > are > > > > always nice if things go bad. > > > > > > But would anyone who sees these issues know that this is the problem? > > > And what would they do, report the problem? We'd say, yeh, we know, > > > but do you hit this every day? Nope, ok, we won't fix it... > > > > > > > Maybe some function which examine new domain and say there is no > risk to > > > > add it would be nice. > > > > > > I agree... These things should have been done in the first place, but > > > clearly this warning wasn't enough to cause anyone to fix it.. :) > > > > You are right, but the warning is remainder that there is something > > unresolved. Remove the warning and forget, imho, it's not well. > > Sorry, nine years[1] of the warning existing yet no fix clearly > demonstrates that it's already been forgoten, otherwise it would have > been fixed by now.. > > Also, a bug report or XXX comment is enough IMO, and will probably > receive the same amount of attention over the next nine years... > > [1] https://svnweb.freebsd.org/changeset/base/138239 > > I agree that the warning is pointless stres for anyone but network domain developer. And such developer knows if he/she is careful enough to ignore it. However, I still remember time when I was starting with FreeBSD kernel development. So much things one should be aware of. In those time, any however small glue, which could help, was appreciated. So, put the warning under INVARIANTS or something like that as FreeBSD is open source and without rookies will die. And no one wants to make kernel development harder than it is. Svata > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-current@FreeBSD.ORG Sun Aug 3 08:34:25 2014 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 ESMTPS id DCCA08E5 for ; Sun, 3 Aug 2014 08:34:25 +0000 (UTC) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A9D32D78 for ; Sun, 3 Aug 2014 08:34:25 +0000 (UTC) Received: by mail-qg0-f50.google.com with SMTP id q108so7723932qgd.9 for ; Sun, 03 Aug 2014 01:34:24 -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:message-id:subject :from:to:cc:content-type; bh=5j4LFDF6Y1cvVOtdbP+jtClkAr0qdi6YNSEYXPmVq9Y=; b=kqSt/wq0+liwHMw09l8rtbLJwvshiwBMbq7W9/qwSNpPF0IOy4CGoRYZ+tTNZMgAeJ JHhDKi3FNBqO2Z8qJ5IUCmPHpOSTM0USaj6x6Sl7a/PLBjEr/QEgqm36+/z8MLQJgwwc yAk2nfu9VR3zVpPBU8oZe//3TDjRvaU/fTQe5vJ9rx5HC0KR66QY5ZceNu+ccm8rfeuF hAJdzQQvFDz2SAndvCslQJx/p5KMP1/QGkC48mPevEdV2Iq4aJv/GUJ+vkReRROc0SyK 0gARqqqj9AWtNU2GrQlf2r1wRxXIzWY9vozWPBM6h8Lo66smGeegXZi9Jma0noi4fet3 Mr2g== MIME-Version: 1.0 X-Received: by 10.140.92.13 with SMTP id a13mr23693822qge.88.1407054864633; Sun, 03 Aug 2014 01:34:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sun, 3 Aug 2014 01:34:24 -0700 (PDT) In-Reply-To: References: <20140801193403.GE50495@funkthat.com> <20140801222118.GH50495@funkthat.com> <20140802183259.GL50495@funkthat.com> <20140802200149.GO50495@funkthat.com> Date: Sun, 3 Aug 2014 01:34:24 -0700 X-Google-Sender-Auth: 1BVHr4TAVeWCQBCrzcWnSWnOg-M Message-ID: Subject: Re: domain_add(xxx) after domainfinalize... From: Adrian Chadd To: Svatopluk Kraus Content-Type: text/plain; charset=UTF-8 Cc: John-Mark Gurney , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 03 Aug 2014 08:34:25 -0000 On 3 August 2014 01:02, Svatopluk Kraus wrote: > > I agree that the warning is pointless stres for anyone but network domain > developer. And such developer knows if he/she is careful enough to ignore > it. However, I still remember time when I was starting with FreeBSD kernel > development. So much things one should be aware of. In those time, any > however small glue, which could help, was appreciated. So, put the warning > under INVARIANTS or something like that as FreeBSD is open source and > without rookies will die. And no one wants to make kernel development > harder than it is. I think putting it under INVARIANTS and maybe tweaking it to explain why it's a bad idea is .. well, a good idea. Great suggestion! -a From owner-freebsd-current@FreeBSD.ORG Mon Aug 4 12:52:49 2014 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 ESMTPS id AFF126D7; Mon, 4 Aug 2014 12:52:49 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 655722836; Mon, 4 Aug 2014 12:52:48 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5C2A525D3A8F; Mon, 4 Aug 2014 12:52:40 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 898C3C25F5C; Mon, 4 Aug 2014 12:52:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id E3RNOI9ffDiH; Mon, 4 Aug 2014 12:52:38 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (unknown [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 08F5CC25F5A; Mon, 4 Aug 2014 12:52:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFT] Autofs. From: "Bjoern A. Zeeb" In-Reply-To: <20140730071933.GA20122@pc5.home> Date: Mon, 4 Aug 2014 12:52:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> References: <20140730071933.GA20122@pc5.home> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 04 Aug 2014 12:52:49 -0000 On 30 Jul 2014, at 07:19 , Edward Tomasz Napiera=C5=82a = wrote: > At the link below you will find a patch that adds the new automounter. > The patch is against yesterdays 11.0-CURRENT. >=20 > http://people.freebsd.org/~trasz/autofs-head-20140729.diff I also just submitted = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192379 to allow -o = vers=3D mount_nfs compatibility, which makes it easier to integrate with = Linux/OSX/Solaris LDAP setups and mount options from LDAP. > Testing is welcome. Please start with manual pages, eg. automount(8). I found one case now doing the aforementioned where when the initial = mount_nfs fails (e.g., for invalid options), then a later mount did not = succeed either, with the correct mount options; I did try to run = automount -u in between tries, as well as service automountd restart, = but that did not make a change; given I was short on time, a reboot of = my desktop made this go away. Is there some =E2=80=9Cnegative = caching=E2=80=9D in the kernel module possibly that will not retry the = mount for another time or something=E2=80=94as in if I were more patient = and waited 5 minutes, would it maybe just have worked again? Bjoern =E2=80=94=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-current@FreeBSD.ORG Mon Aug 4 16:17:11 2014 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 ESMTPS id 3A5C2B21; Mon, 4 Aug 2014 16:17:11 +0000 (UTC) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E0592566; Mon, 4 Aug 2014 16:17:10 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id w61so7885752wes.25 for ; Mon, 04 Aug 2014 09:17:06 -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:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=BssA/C/kbOXvuXH2a0TGeeDDA+1jqGQdZ4/oi0mHk+k=; b=GdDq0AWR9Bb0GWkik2Gtep7KUFCW62cjmPyjdCWaz4jyQEPemzaY96Ex9cKtSh0QcS IrrIrFeROI6FFcPrXoEZ0lqpC9cID+w7DvkjhhCA6jXjS0zEUazahwtqftT3V5i5pKmn Ohxv6hJ7yRAx7wPAi88EgqpaVQoE8AKDgwx/qyq586Ghi6VIgKoSu+/370dmr4cWthwJ c2KqOs6fU/3VyJqwink2rSkO5cKXibYvPFYjf5ecQesBbMRzlpCfN4+FI6fvrTAyYBRJ Am5oW5o9yirTT+xct433FPBdcLLX3EX+T93lU7+ia91R7iKkXwUqT4rPaoyXXDxMhr8j 5O6w== X-Received: by 10.194.6.101 with SMTP id z5mr33836739wjz.79.1407169025676; Mon, 04 Aug 2014 09:17:05 -0700 (PDT) Received: from pc5.home (adhg143.neoplus.adsl.tpnet.pl. [79.184.162.143]) by mx.google.com with ESMTPSA id m1sm37783346wiy.7.2014.08.04.09.17.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 09:17:05 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 4 Aug 2014 18:17:10 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Bjoern A. Zeeb" Subject: Re: [CFT] Autofs. Message-ID: <20140804161710.GA32801@pc5.home> Mail-Followup-To: "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org References: <20140730071933.GA20122@pc5.home> <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 04 Aug 2014 16:17:11 -0000 On 0804T1252, Bjoern A. Zeeb wrote: > On 30 Jul 2014, at 07:19 , Edward Tomasz Napierała wrote: > > > At the link below you will find a patch that adds the new automounter. > > The patch is against yesterdays 11.0-CURRENT. > > > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > I also just submitted https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192379 to allow -o vers= mount_nfs compatibility, which makes it easier to integrate with Linux/OSX/Solaris LDAP setups and mount options from LDAP. Nice! Will you commit it? > > Testing is welcome. Please start with manual pages, eg. automount(8). > > > I found one case now doing the aforementioned where when the initial mount_nfs fails (e.g., for invalid options), then a later mount did not succeed either, with the correct mount options; I did try to run automount -u in between tries, as well as service automountd restart, but that did not make a change; given I was short on time, a reboot of my desktop made this go away. Is there some “negative caching” in the kernel module possibly that will not retry the mount for another time or something—as in if I were more patient and waited 5 minutes, would it maybe just have worked again? There is no negative caching. I'll see if I can figure out the cause for this. From owner-freebsd-current@FreeBSD.ORG Mon Aug 4 16:35:25 2014 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 ESMTPS id 3B7F54D6; Mon, 4 Aug 2014 16:35:25 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5203278C; Mon, 4 Aug 2014 16:35:24 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 827DA25D3810; Mon, 4 Aug 2014 16:35:22 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A12F7C26033; Mon, 4 Aug 2014 16:35:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id XEZJxJIN6D5n; Mon, 4 Aug 2014 16:35:20 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (unknown [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 45C0CC26030; Mon, 4 Aug 2014 16:35:17 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFT] Autofs. From: "Bjoern A. Zeeb" In-Reply-To: <20140804161710.GA32801@pc5.home> Date: Mon, 4 Aug 2014 16:35:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5C88BFBD-798C-4F99-92E2-5F75FE622613@lists.zabbadoz.net> References: <20140730071933.GA20122@pc5.home> <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> <20140804161710.GA32801@pc5.home> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 04 Aug 2014 16:35:25 -0000 On 04 Aug 2014, at 16:17 , Edward Tomasz Napiera=C5=82a = wrote: > On 0804T1252, Bjoern A. Zeeb wrote: >> On 30 Jul 2014, at 07:19 , Edward Tomasz Napiera=C5=82a = wrote: >>=20 >>> At the link below you will find a patch that adds the new = automounter. >>> The patch is against yesterdays 11.0-CURRENT. >>>=20 >>> http://people.freebsd.org/~trasz/autofs-head-20140729.diff >>=20 >> I also just submitted = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192379 to allow -o = vers=3D mount_nfs compatibility, which makes it easier to integrate with = Linux/OSX/Solaris LDAP setups and mount options from LDAP. >=20 > Nice! Will you commit it? Yeah and MFC for 10.1 unless someone speaks up the next day or two. I = have updated the man page locally and I emailed Rick Macklem; will see = if he=E2=80=99s around. >>> Testing is welcome. Please start with manual pages, eg. = automount(8). >>=20 >>=20 >> I found one case now doing the aforementioned where when the initial = mount_nfs fails (e.g., for invalid options), then a later mount did not = succeed either, with the correct mount options; I did try to run = automount -u in between tries, as well as service automountd restart, = but that did not make a change; given I was short on time, a reboot of = my desktop made this go away. Is there some =E2=80=9Cnegative = caching=E2=80=9D in the kernel module possibly that will not retry the = mount for another time or something=E2=80=94as in if I were more patient = and waited 5 minutes, would it maybe just have worked again? >=20 > There is no negative caching. I'll see if I can figure out the cause > for this. Thanks. I can possibly try to do some more tracing and debugging later = in the week if needed. =E2=80=94=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-current@FreeBSD.ORG Mon Aug 4 17:41:52 2014 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 ESMTPS id 92511FA9; Mon, 4 Aug 2014 17:41:52 +0000 (UTC) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3FED21D8; Mon, 4 Aug 2014 17:41:51 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id w61so8131272wes.39 for ; Mon, 04 Aug 2014 10:41:50 -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:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=pg1Olvv6j8jiXU1Q8+gDz7CFz6pdXrEZ1KXGPJFM8Eo=; b=GGoG3xdXleAFhznhMPYSNHWQKv6w3FLDwfa5Nwl4ViaF47xAHJbg/EZ0sgbxjC5osg uJq0HDmwL9oXSX44WzsbsSZ3Ui9KVF7JgF2uNKR4WhrG+4N+sSRuQPEL+dKbp2egE+Uy zhD44WsmEwYvdK6SaH/0t+HiHbl1SJ7hsKmigUiYflwLAweTiWoTRqc1Xj6hEFqXFP2G svSIUD0XGmjoiVzhcVQTBOzts/JOsra7hWt45aedl1zcDvTJ49rm3zBwrDzFdBpxNbFU 6KN+011ax51shlJc9xCvXB1HwdcEKr01W+wdnM0p/RgMqbtxBkdGMYcwAhgCtyqDw5vJ 0E2A== X-Received: by 10.180.39.172 with SMTP id q12mr31003625wik.55.1407174109991; Mon, 04 Aug 2014 10:41:49 -0700 (PDT) Received: from pc5.home (adhg143.neoplus.adsl.tpnet.pl. [79.184.162.143]) by mx.google.com with ESMTPSA id 10sm45007077wjx.26.2014.08.04.10.41.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 10:41:49 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 4 Aug 2014 19:41:53 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Bjoern A. Zeeb" Subject: Re: [CFT] Autofs. Message-ID: <20140804174153.GA33041@pc5.home> Mail-Followup-To: "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org References: <20140730071933.GA20122@pc5.home> <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> <20140804161710.GA32801@pc5.home> <5C88BFBD-798C-4F99-92E2-5F75FE622613@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5C88BFBD-798C-4F99-92E2-5F75FE622613@lists.zabbadoz.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 04 Aug 2014 17:41:52 -0000 On 0804T1635, Bjoern A. Zeeb wrote: > > On 04 Aug 2014, at 16:17 , Edward Tomasz Napierała wrote: > > > On 0804T1252, Bjoern A. Zeeb wrote: > >> On 30 Jul 2014, at 07:19 , Edward Tomasz Napierała wrote: > >> > >>> At the link below you will find a patch that adds the new automounter. > >>> The patch is against yesterdays 11.0-CURRENT. > >>> > >>> http://people.freebsd.org/~trasz/autofs-head-20140729.diff > >> > >> I also just submitted https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192379 to allow -o vers= mount_nfs compatibility, which makes it easier to integrate with Linux/OSX/Solaris LDAP setups and mount options from LDAP. > > > > Nice! Will you commit it? > > Yeah and MFC for 10.1 unless someone speaks up the next day or two. I have updated the man page locally and I emailed Rick Macklem; will see if he’s around. Thanks! > >>> Testing is welcome. Please start with manual pages, eg. automount(8). > >> > >> > >> I found one case now doing the aforementioned where when the initial mount_nfs fails (e.g., for invalid options), then a later mount did not succeed either, with the correct mount options; I did try to run automount -u in between tries, as well as service automountd restart, but that did not make a change; given I was short on time, a reboot of my desktop made this go away. Is there some “negative caching” in the kernel module possibly that will not retry the mount for another time or something—as in if I were more patient and waited 5 minutes, would it maybe just have worked again? > > > > There is no negative caching. I'll see if I can figure out the cause > > for this. > > Thanks. I can possibly try to do some more tracing and debugging later in the week if needed. Ok. Now, to make sure I get it right: at first, the trigger failed, because of invalid mount options in map. The filesystem didn't get mounted, and the command that triggered the mount returned some kind of Input/Output Error. After fixing the map and trying to access the same directory again... what exactly happened at this point? In what way exactly did the second mount fail? From owner-freebsd-current@FreeBSD.ORG Mon Aug 4 18:51:13 2014 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 ESMTPS id 17128F4D; Mon, 4 Aug 2014 18:51:13 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id AF35A2905; Mon, 4 Aug 2014 18:51:12 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssEAG3V31ODaFve/2dsb2JhbABbFoNJVwSCdMk8CoZ3UwGBJ3eEAwEBAQMBAQEBICsgCwUWGAICDRkCKQEJJgYIBwQBHASIGQgNrWiXDBeBLI1PAQEbATMHgnmBUgWOWIo6hEiTC4NpIS8BBoEGOQ X-IronPort-AV: E=Sophos;i="5.01,799,1400040000"; d="scan'208";a="146251524" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 04 Aug 2014 14:51:11 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5B70083DA2; Mon, 4 Aug 2014 14:51:11 -0400 (EDT) Date: Mon, 4 Aug 2014 14:51:11 -0400 (EDT) From: Rick Macklem To: "Bjoern A. Zeeb" Message-ID: <1593472917.6916985.1407178271363.JavaMail.root@uoguelph.ca> In-Reply-To: <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> Subject: Re: [CFT] Autofs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-current@FreeBSD.org, Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 04 Aug 2014 18:51:13 -0000 Bjoern A. Zeeb wrote: > On 30 Jul 2014, at 07:19 , Edward Tomasz Napiera=C5=82a > wrote: >=20 > > At the link below you will find a patch that adds the new > > automounter. > > The patch is against yesterdays 11.0-CURRENT. > >=20 > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff >=20 > I also just submitted > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192379 to allow -o > vers=3D mount_nfs compatibility, which makes it easier to integrate > with Linux/OSX/Solaris LDAP setups and mount options from LDAP. >=20 >=20 > > Testing is welcome. Please start with manual pages, eg. > > automount(8). >=20 >=20 > I found one case now doing the aforementioned where when the initial > mount_nfs fails (e.g., for invalid options), then a later mount did > not succeed either, with the correct mount options; I did try to > run automount -u in between tries, as well as service automountd > restart, but that did not make a change; given I was short on time, > a reboot of my desktop made this go away. Is there some =E2=80=9Cnegati= ve > caching=E2=80=9D in the kernel module possibly that will not retry the mo= unt > for another time or something=E2=80=94as in if I were more patient and > waited 5 minutes, would it maybe just have worked again? >=20 If I recall it correctly, it retries a mount attempt that fails after something like 1min (which seems like a long time when you are waiting for it;-). I think that was done so that clients don't flood a rebooting server with mount attempts, but that code was written long, long ago. rick ps: I just reviewed and thanked Bjoern for the -vers=3D patch. > Bjoern >=20 > =E2=80=94 > Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, > 1983 >=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Aug 4 19:48:02 2014 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 ESMTPS id AFAF872F for ; Mon, 4 Aug 2014 19:48:02 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C28520CA for ; Mon, 4 Aug 2014 19:48:01 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s74JlxKH010895 for ; Mon, 4 Aug 2014 12:47:59 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s74JlxPV010894 for current@freebsd.org; Mon, 4 Aug 2014 12:47:59 -0700 (PDT) (envelope-from david) Date: Mon, 4 Aug 2014 12:47:59 -0700 From: David Wolfskill To: current@freebsd.org Subject: Build machine OK; laptop panics @r269515 Message-ID: <20140804194759.GT1228@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YqKeQn+qkMVHQmbT" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 04 Aug 2014 19:48:02 -0000 --YqKeQn+qkMVHQmbT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I held off until the build machine was able to build & (try to boot) head; unfortunately for me, it had no problems: FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1571 r269515M/269515:1100028: Mon Aug 4 12:14:39 PDT 2014 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 The laptop -- also i386, with a copy of the same sources (though kernel config mostly includes GENERIC, turns off a bunch of stuff I don't ever expect to have on a laptop, and enables IPFW in default-deny mode) -- tried to boot after building head @r269515... and that process terminated quickly: reported uptime was 3 secnds. I was unable to get a crash dump, and I only recorded the offsets in the backtrace (no arguments; sorry -- I was expecting the build machine to allow me to investigate on a machine with a serial console): =2E.. SMP: AP CPU #1 Launched! panic: aatpic_assign_cpu: bad cookie cpuid=3D0 atpic_assign_cpu(...) at atpic_assign_cpu+0x1a/frame 0xc2820d0c intr_shuffle_irqs(...) at intr_shuffle_irqs+0x97/frame 0xc2820d30 mi_startup(...) at mi_startup+0xe7/frame 0xc2820d58 begin(...) at begin+0x2c db>=20 So... what can I do to help figure out what went wrong? As noted, I have no serial console on the laptop, and while I have captured crash dumps in the past, I'm guessing that at the point the above happens, the machine has yet to obtain a clue about where it might put a dump if one were created. (No problems with stable/9 (@r269499) or stable/10 (@r269498) on the same hardware.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --YqKeQn+qkMVHQmbT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT3+NuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7uREP/2lQvcGfUSE1Zf9Jc3p+qGIq oh2zyZbTce+Z3gwxkmVaP3M1uRqC8dzEsWxWk7M81baQKb+AOGU01w1kW3cJq1Dg csqe1oVO4vAEjhRxf2PjZLwZq0xw3z0E/4mODNgXopo4UjbnKtL1QW9fW56AxV6C NbbGZbHywp3PGSh0QD8CxoPiENNPvT+mE3ljqlFpBbPuiIq/Y53iILOt2H5ymQR4 X9t22fBCBN9mxhx3jIilQOzF1vRPARk3VhTX3c0rMc0t3BSvPM4k9STi2iEDlcAz 8Hm1I1WcSFPF9DXOVnrx6q4nZlKWsvfqg+5Gg5T6HRrPI2eLDWEIeGYitjzKW7b3 WrWMvyXASUxaGD/b4VWshrPDZhEiWXxovPWNPHJWKQXUKP3F4NMlw3MIw5GXuvj/ 0Di45vq+dVqXbBBj7c9ECsWVnfQ9cPmJ+rUYLlGNcVrt/x/Xc4TgEiEsQDOCqhdm 4/pDD+QOuc1/UwLoxmmjDoO7B3vvDIkp98VkYvgcD5oDvvY6Ut/NrhjR0LSSFeWN MqnguDKUj5PNwIdJj10rWocTGNJw26xnIdCjZAkJ+wLbjKERCL3p5wU+3Y0g+JuV GjQl3cJZlKy+PbClm54jPtExIDovn81Kz1Pf4tiy5sz84qyPIy4HemXr92T54rCe skQzef8byuFHZqgo8IeC =BorR -----END PGP SIGNATURE----- --YqKeQn+qkMVHQmbT-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 4 21:53:46 2014 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 ESMTPS id 205FA75D; Mon, 4 Aug 2014 21:53:46 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83B3E20F7; Mon, 4 Aug 2014 21:53:45 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id l18so58953wgh.2 for ; Mon, 04 Aug 2014 14:53:43 -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:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=qqhFUNbxfJ8w9GqMZSfDNUbPo9/O/e8DHRN/QkXi6Cg=; b=wv8BOngF4hXlOuVnNT+zO9NkvoeRpixv0THhEhqlZd7D9cnTSrky6J4IOMOv4z/wI1 fAqTUBiXl7UvnArfCgjLw76viMe5KbnMLzYVXry9C+PYCimAZSCxPcM80oR5RtDix0UB uYFn5vb1KfPBthc6adHvNEBYNydmMgQox1DnGh95b2OWWI/+9gisHr3TKOP5DQw9YHeh /ivzSSLTA+TVJYbjxf4duaFR1qpqbi5ZHz2y+qpFoZR6/tVpCsJESIpx6DB4bW9KLEoP 5tDY75jDMoEELbCzYHC2WQ2kIHzOZZhe2FHvIbTsmgnLqt0nO7U/ASbS8b5g3Xqm9cEe Sr6w== X-Received: by 10.180.93.8 with SMTP id cq8mr511578wib.17.1407189223807; Mon, 04 Aug 2014 14:53:43 -0700 (PDT) Received: from pc5.home (adhg143.neoplus.adsl.tpnet.pl. [79.184.162.143]) by mx.google.com with ESMTPSA id o2sm1006023wij.24.2014.08.04.14.53.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 14:53:43 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 4 Aug 2014 23:53:49 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Rick Macklem Subject: Re: [CFT] Autofs. Message-ID: <20140804215349.GA33526@pc5.home> Mail-Followup-To: Rick Macklem , "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org References: <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> <1593472917.6916985.1407178271363.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1593472917.6916985.1407178271363.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 04 Aug 2014 21:53:46 -0000 On 0804T1451, Rick Macklem wrote: > Bjoern A. Zeeb wrote: > > On 30 Jul 2014, at 07:19 , Edward Tomasz Napierała > > wrote: > > > > > At the link below you will find a patch that adds the new > > > automounter. > > > The patch is against yesterdays 11.0-CURRENT. > > > > > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > > > I also just submitted > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192379 to allow -o > > vers= mount_nfs compatibility, which makes it easier to integrate > > with Linux/OSX/Solaris LDAP setups and mount options from LDAP. > > > > > > > Testing is welcome. Please start with manual pages, eg. > > > automount(8). > > > > > > I found one case now doing the aforementioned where when the initial > > mount_nfs fails (e.g., for invalid options), then a later mount did > > not succeed either, with the correct mount options; I did try to > > run automount -u in between tries, as well as service automountd > > restart, but that did not make a change; given I was short on time, > > a reboot of my desktop made this go away. Is there some “negative > > caching” in the kernel module possibly that will not retry the mount > > for another time or something—as in if I were more patient and > > waited 5 minutes, would it maybe just have worked again? > > > If I recall it correctly, it retries a mount attempt that fails after > something like 1min (which seems like a long time when you are waiting > for it;-). I think that was done so that clients don't flood a rebooting > server with mount attempts, but that code was written long, long ago. >From what I've seen mount_nfs(8) retries indefinitely; that's why automountd disables that behaviour by default, by passing "retrycnt=1". From owner-freebsd-current@FreeBSD.ORG Tue Aug 5 07:00:48 2014 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 ESMTPS id 8261B420; Tue, 5 Aug 2014 07:00:48 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 461D22875; Tue, 5 Aug 2014 07:00:48 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id rd3so837205pab.40 for ; Tue, 05 Aug 2014 00:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=giHKNzW0DZ1sHBGkodsDnCTZP6SRU/ygybOON99L6IQ=; b=j938scUlRdUZWqaMdjD7dAVrNBy0OHDntJ14WM+jy+jf2LHhidDaiAfg67J8CGdqtX 2j9atRg6wlOOiDnqbzLPwA0CTkzNWACtM+W6icrtoNjndqO7sq8FqR4oGwD1L6goHeCF gKlj/yrH0VVeRueYxOZCdtkB31U+1GGqlXp96e7AhH/5TYroibwfgsLUCQgR9G/uMyJr RrAAgqCW8YU9qIgjcbW+btyLRtpsyBdbLs7S+x/U9eA+xQa5kv/y6g3bEJS3bBFp9oTL deH2CI2Kv0x5ye3mHCFya4eomxpd/Pm9f2qauxOZraBtUlKPIjcFFqwbmvQB8DBOJ2WG Xirw== X-Received: by 10.68.137.67 with SMTP id qg3mr1848657pbb.113.1407222047774; Tue, 05 Aug 2014 00:00:47 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:7d38:a334:f5b3:d383? ([2601:8:ab80:7d6:7d38:a334:f5b3:d383]) by mx.google.com with ESMTPSA id j1sm1408258pdh.31.2014.08.05.00.00.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 00:00:46 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1F3FA187-E16E-49C3-B5E6-41DD50F2542D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Bootstrap-related build failure with gcc due to change in sctp system headers; not with clang (was Re: svn commit: r269527 - in head: lib/libc/net sys/netinet) From: Garrett Cooper In-Reply-To: <53dfe808.5881.578e6c00@svn.freebsd.org> Date: Tue, 5 Aug 2014 00:00:44 -0700 Message-Id: <7593D813-3049-4CD9-A2D2-7421035010A0@gmail.com> References: <53dfe808.5881.578e6c00@svn.freebsd.org> To: FreeBSD Current X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-toolchain@freebsd.org, Michael Tuexen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 05 Aug 2014 07:00:48 -0000 --Apple-Mail=_1F3FA187-E16E-49C3-B5E6-41DD50F2542D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 4, 2014, at 1:07 PM, Michael Tuexen wrote: > Author: tuexen > Date: Mon Aug 4 20:07:35 2014 > New Revision: 269527 > URL: http://svnweb.freebsd.org/changeset/base/269527 >=20 > Log: > Add support for the SCTP_RECONFIG_SUPPORTED and the corresponding > sysctl controlling the negotiation of the RE-CONFIG extension. >=20 > MFC after: 3 days Hi FreeBSD toolchain, I ran into a build bootstrap problem where it only seems to fail = with gcc after this commit because it=92s picking up installed system = headers instead of the system headers in the obj tree. I=92ve filed = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192394 to track this = issue . Thank you, -Garrett --Apple-Mail=_1F3FA187-E16E-49C3-B5E6-41DD50F2542D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT4IEcAAoJEMZr5QU6S73eCZAIALFyUEEqBN70PcRLRY/hLprG Vey3N2IfqzzLtGFSssoqkJk/AI/w0wTjkayxFtCX94PdEC2SNWWogSslBc+3sJoY YaanjEoVO1csjU0S6DqFXuBofdrbsWIKkGVi+90BnXhEusZvMrIg6QZzthf9OPEb i3S593S2TC2WaImue4c2hZfK+0STPZQ/W9Mpxg4J+td8PjFwZLbuJxU6Y635VOJO /AIvvJGaJrKf18+UTxwwG+KoQ2Mla1pYdEi0YI0+vJef48DFlUYacGFGXwcf0LSB FBXzWYsIq7/qOsUcvN4VI26hlEb7BIJkvYr5Ku47jF8Fp/xgrIJESsSTdzgfhcU= =qMCp -----END PGP SIGNATURE----- --Apple-Mail=_1F3FA187-E16E-49C3-B5E6-41DD50F2542D-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 5 14:29:16 2014 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 ESMTPS id D734D84B; Tue, 5 Aug 2014 14:29:16 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5BBF24E5; Tue, 5 Aug 2014 14:29:15 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s75ETEO4017054; Tue, 5 Aug 2014 07:29:14 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s75ETEOh017053; Tue, 5 Aug 2014 07:29:14 -0700 (PDT) (envelope-from david) Date: Tue, 5 Aug 2014 07:29:14 -0700 From: David Wolfskill To: current@freebsd.org Subject: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] Message-ID: <20140805142914.GJ1228@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20140804194759.GT1228@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VPk9As2FDNdbSgZX" Content-Disposition: inline In-Reply-To: <20140804194759.GT1228@albert.catwhisker.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 05 Aug 2014 14:29:17 -0000 --VPk9As2FDNdbSgZX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 04, 2014 at 12:47:59PM -0700, David Wolfskill wrote: > ... > I was unable to get a crash dump, and I only recorded the offsets in the > backtrace (no arguments; sorry -- I was expecting the build machine to > allow me to investigate on a machine with a serial console): >=20 > ... > SMP: AP CPU #1 Launched! > panic: aatpic_assign_cpu: bad cookie > cpuid=3D0 > atpic_assign_cpu(...) at atpic_assign_cpu+0x1a/frame 0xc2820d0c > intr_shuffle_irqs(...) at intr_shuffle_irqs+0x97/frame 0xc2820d30 > mi_startup(...) at mi_startup+0xe7/frame 0xc2820d58 > begin(...) at begin+0x2c > db>=20 >=20 > So... what can I do to help figure out what went wrong? As noted, I > have no serial console on the laptop, and while I have captured crash > dumps in the past, I'm guessing that at the point the above happens, the > machine has yet to obtain a clue about where it might put a dump if one > were created. >=20 > (No problems with stable/9 (@r269499) or stable/10 (@r269498) on the > same hardware.) > .... By booting from the previously-built kernel: FreeBSD 11.0-CURRENT #1327 r269469M/269469:1100028: Sun Aug 3 06:16:24 PD= T 2014 root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i3= 86 I was able to update sources to r269580 & rebuild (successfully -- both userland & kernel); the resulting kernel, however, exhibited the same symptoms -- "panic: aatpic_assign_cpu: bad cookie", with a similar (if not identical -- I couldn't refer to the previous one while I was observing the current panic) backtrace. I'm willing to try hacking at code (if necessary) to figure out what's wrong & fix it; I'll need some guidance, though. Given that my build machine did not exhibit the symptoms, and given the references to atpic, it may be relevant to point out that the machine where I see the panic is a Dell Precision M4400 laptop. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --VPk9As2FDNdbSgZX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT4Oo4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk73b4QAJmpYF+dr/ZVNdhSCuCh5AQx kfRqenOVVG90Rs2/79/EvHJoe9xDEbMKED8C0liwlckewFeIULbb3RfxKpUo7tRg 4zMjo2Dcws45wIBGgrUXes/uH07wQ+6jfOxkzC7ycZX/C+/0PfCy5kC3FwcXJtP7 rCfVCVDBIe3FLR7OSqXgELw82LEIy1ph078urE/8jaZLolmW2wNARsLEOt0+IOx3 qtW6Tw5ycuSADQP0bgqPA5WwORQFpEFd4K9FkZw1ewccDHePabLQAwo9NbSd9cCZ AD6s/jrRDQPp0mLn52iM57NF7b2HTx086ONhBy4naRO/3nrQG3IvE/4HVAQxyaK4 sLn5E7lhUQv9mpBNjByaEvY2mt4G7bdqifWFcQkqABr446I7xA4JE83ZP6m8wDIX n8M//jk7zMRdl3yV9f+ap+tEJk8NzQsqKJzGLWF1NnqTNYGHhmdWz7Bk9FFXAPd1 0vNiTgKoe/XRTFGU7BP6o0PoSNjF//PNZtEPvB/zBCJ9IsAy0YO/E7mrXvZSmiQu 7nzu6j2YxKSyE8GCOpmY2LLKmqy6Z2B5EeWyPLzGSR/B5ruUUVGZKwDcqVz72yLr WWfzDT/DQYnzzv5k/PZSocn9xZyPkaZJFcrSP5af4ioOzsKP26mFF3Cr2MAoLiJI auUkI4DYtxdgiz2w7snS =C9Yh -----END PGP SIGNATURE----- --VPk9As2FDNdbSgZX-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 5 20:02:31 2014 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 ESMTPS id 0C61174E for ; Tue, 5 Aug 2014 20:02:31 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7A6A2FDA for ; Tue, 5 Aug 2014 20:02:30 +0000 (UTC) Received: from [192.168.1.75] (75-48-77-17.lightspeed.cncrca.sbcglobal.net [75.48.77.17]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4327EB913; Tue, 5 Aug 2014 16:02:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] From: John Baldwin In-Reply-To: <20140805142914.GJ1228@albert.catwhisker.org> Date: Tue, 5 Aug 2014 13:02:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> To: David Wolfskill X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 05 Aug 2014 16:02:30 -0400 (EDT) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 05 Aug 2014 20:02:31 -0000 On Aug 5, 2014, at 7:29 AM, David Wolfskill = wrote: > On Mon, Aug 04, 2014 at 12:47:59PM -0700, David Wolfskill wrote: >> ... >> I was unable to get a crash dump, and I only recorded the offsets in = the >> backtrace (no arguments; sorry -- I was expecting the build machine = to >> allow me to investigate on a machine with a serial console): >>=20 >> ... >> SMP: AP CPU #1 Launched! >> panic: aatpic_assign_cpu: bad cookie >> cpuid=3D0 >> atpic_assign_cpu(...) at atpic_assign_cpu+0x1a/frame 0xc2820d0c >> intr_shuffle_irqs(...) at intr_shuffle_irqs+0x97/frame 0xc2820d30 >> mi_startup(...) at mi_startup+0xe7/frame 0xc2820d58 >> begin(...) at begin+0x2c >> db>=20 >>=20 >> So... what can I do to help figure out what went wrong? As noted, I >> have no serial console on the laptop, and while I have captured crash >> dumps in the past, I'm guessing that at the point the above happens, = the >> machine has yet to obtain a clue about where it might put a dump if = one >> were created. >>=20 >> (No problems with stable/9 (@r269499) or stable/10 (@r269498) on the >> same hardware.) >> .... >=20 > By booting from the previously-built kernel: >=20 > FreeBSD 11.0-CURRENT #1327 r269469M/269469:1100028: Sun Aug 3 = 06:16:24 PDT 2014 = root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 >=20 > I was able to update sources to r269580 & rebuild (successfully -- = both > userland & kernel); the resulting kernel, however, exhibited the same > symptoms -- "panic: aatpic_assign_cpu: bad cookie", with a similar (if > not identical -- I couldn't refer to the previous one while I was > observing the current panic) backtrace. >=20 > I'm willing to try hacking at code (if necessary) to figure out what's > wrong & fix it; I'll need some guidance, though. >=20 > Given that my build machine did not exhibit the symptoms, and given = the > references to atpic, it may be relevant to point out that the machine > where I see the panic is a Dell Precision M4400 laptop. My guess is that the recent Xen changes tickled something. However, can = you capture a verbose dmesg from your working kernel? --=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 5 20:10:04 2014 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 ESMTPS id 594B9AF0; Tue, 5 Aug 2014 20:10:04 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DF242039; Tue, 5 Aug 2014 20:10:02 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s75K9rrF018250; Tue, 5 Aug 2014 13:09:53 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s75K9rdo018249; Tue, 5 Aug 2014 13:09:53 -0700 (PDT) (envelope-from david) Date: Tue, 5 Aug 2014 13:09:53 -0700 From: David Wolfskill To: John Baldwin Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] Message-ID: <20140805200953.GN1228@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , John Baldwin , current@freebsd.org References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lGa3FpvTyf1CgKg0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 05 Aug 2014 20:10:04 -0000 --lGa3FpvTyf1CgKg0 Content-Type: multipart/mixed; boundary="EVQB43uFympFEer4" Content-Disposition: inline --EVQB43uFympFEer4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 05, 2014 at 01:02:25PM -0700, John Baldwin wrote: =2E.. > My guess is that the recent Xen changes tickled something. However, can = you capture a verbose dmesg from your working kernel? That was my current hunch, as well. I've attached /var/run/dmesg.boot from a verbose boot running: FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1327 r269= 469M/269469:1100028: Sun Aug 3 06:16:24 PDT 2014 root@g1-252.catwhiske= r.org:/common/S4/obj/usr/src/sys/CANARY i386 Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --EVQB43uFympFEer4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" Content-Transfer-Encoding: quoted-printable Table 'FACP' at 0xdf45449c Table 'HPET' at 0xdf454700 Table '____' at 0xdf462c00 Table 'APIC' at 0xdf454800 APIC: Found table at 0xdf454800 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 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: disabled MADT: Found CPU APIC ID 3 ACPI ID 3: disabled Copyright (c) 1992-2014 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 11.0-CURRENT #1327 r269469M/269469:1100028: Sun Aug 3 06:16:24 PD= T 2014 root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc8c00000 MEMGUARD map size: 104964 KBytes Preloaded elf kernel "/boot/kernel/kernel" at 0xc2442000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc2442898. Preloaded elf module "/boot/kernel/coretemp.ko" at 0xc2442d5c. Preloaded elf module "/boot/kernel/iwn5000fw.ko" at 0xc244310c. Preloaded elf module "/boot/modules/nvidia.ko" at 0xc2443494. Calibrating TSC clock ... TSC clock: 3059068114 Hz CPU: Intel(R) Core(TM)2 Duo CPU T9900 @ 3.06GHz (3059.07-MHz 686-class= CPU) Origin=3D"GenuineIntel" Id=3D0x1067a Family=3D0x6 Model=3D0x17 Steppi= ng=3D10 Features=3D0xbfebfbff Features2=3D0x408e3fd AMD Features=3D0x20100000 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 6144 kbytes, 16-way associative, 64 bytes/line real memory =3D 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000002826000 - 0x00000000db869fff, 3640934400 bytes (888900 pages) avail memory =3D 3639803904 (3471 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 bios32: Found BIOS32 Service Directory header at 0xc00ffa00 bios32: Entry =3D 0xffa10 (c00ffa10) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xf0000+0xa7f6 pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry =3D f0000:e2f4 Rev =3D 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xfb9b0 00024 (v02 DELL ) ACPI: XSDT 0xdf454600 0006C (v01 DELL M09 27DD0604 ASL 00000061) ACPI: FACP 0xdf45449c 000F4 (v04 DELL M09 27DD0604 ASL 00000061) ACPI: DSDT 0xdf454c00 05E58 (v02 INT430 SYSFexxx 00001001 INTL 20050624) ACPI: FACS 0xdf463400 00040 ACPI: HPET 0xdf454700 00038 (v01 DELL M09 00000001 ASL 00000061) ACPI: ____ 0xdf462c00 00030 (v01 DELL M09 27DD0604 ASL 00000061) ACPI: APIC 0xdf454800 00078 (v01 DELL M09 27DD0604 ASL 00000047) ACPI: ASF! 0xdf454400 0006A (v32 DELL M09 27DD0604 ASL 00000061) ACPI: MCFG 0xdf4547c0 0003C (v16 DELL M09 27DD0604 ASL 00000061) ACPI: TCPA 0xdf454b00 00032 (v01 00000000 ASL 00000000) ACPI: SLIC 0xdf45489c 00176 (v01 DELL M09 27DD0604 ASL 00000061) ACPI: SSDT 0xdf452aeb 0066C (v01 PmRef CpuPm 00003000 INTL 20050624) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 wlan: <802.11 Link Layer> snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [10= 24] feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 feeder_ra= te_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 firmware: 'iwn5000fw' version 0: 340696 bytes loaded at 0xc19ed488 Hardware, Intel Secure Key RNG: RDRAND is not present Hardware, VIA Nehemiah Padlock RNG: VIA Padlock RNG not present kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled nfslock: pseudo-device null: Falling back to random adaptor random: initialized VESA: INT 0x10 vector 0xc000:0x1bac VESA: information block 0000 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 0010 00 01 e0 00 94 62 07 01 00 01 1a 01 00 01 2f 01 0020 00 01 00 01 01 01 02 01 03 01 04 01 05 01 06 01 0030 07 01 0e 01 0f 01 11 01 12 01 14 01 15 01 17 01 0040 18 01 1a 01 1b 01 30 01 31 01 32 01 33 01 34 01 0050 35 01 36 01 3d 01 3e 01 45 01 46 01 4a 01 60 01 0060 61 01 62 01 66 01 67 01 70 01 7b 01 7c 01 7d 01 0070 ff ff 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 4e 56 49 44 49 41 00 4e 56 49 44 49 41 20 43 6f 0110 72 70 6f 72 61 74 69 6f 6e 00 47 39 36 20 42 6f 0120 61 72 64 20 2d 20 61 76 69 61 20 20 20 20 00 43 0130 68 69 70 20 52 65 76 20 20 20 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: 39 mode(s) found VESA: v3.0, 14336k memory, flags:0x1, mode table:0xe8e8a022 (1000022) VESA: NVIDIA VESA: NVIDIA Corporation G96 Board - avia Chip Rev =20 VMBUS: load io: hptnr: R750/DC7280 controller driver v1.0 hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard ACPI: All ACPI Tables successfully acquired PCIe: Memory Mapped configuration base @ 0xf8000000 pcibios: BIOS version 2.10 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: wakeup code va 0xe8ec7000 pa 0x9c000 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 4 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic hpet0: t1: irqs 0x00f00000 (0) hpet0: t2: irqs 0x00f00800 (0) hpet0: t3: irqs 0x00f01000 (0) Timecounter "HPET" frequency 14318180 Hz quality 950 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 49 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 100000, df351c00 (3) failed cpu0: Processor \134_PR_.CPU0 (ACPI ID 0) -> APIC ID 0 cpu0: on acpi0 ACPI: SSDT 0xdf453157 002C3 (v01 PmRef BspIst 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 002C3 (v01 PmRef BspIst 00003000 INTL 20050624) ACPI: SSDT 0xdf4535f1 005C6 (v01 PmRef BspCst 00003001 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005C6 (v01 PmRef BspCst 00003001 INTL 20050624) cpu1: Processor \134_PR_.CPU1 (ACPI ID 1) -> APIC ID 1 cpu1: on acpi0 ACPI: SSDT 0xdf45341a 001D7 (v01 PmRef ApIst 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 001D7 (v01 PmRef ApIst 00003000 INTL 20050624) ACPI: SSDT 0xdf453bb7 0008D (v01 PmRef ApCst 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0008D (v01 PmRef ApCst 00003000 INTL 20050624) ACPI: Processor \134_PR_.CPU2 (ACPI ID 2) ignored ACPI: Processor \134_PR_.CPU3 (ACPI ID 3) ignored atrtc0: port 0x70-0x71,0x72-0x77 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 attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 51 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/1 1/1 1/1 1/2 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x930,0x934 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 10 11 Validation 0 11 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 7 Validation 0 5 N 0 5 7 After Disable 0 255 N 0 5 7 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 10 11 Validation 0 11 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 10 11 Validation 0 10 N 0 5 7 10 11 After Disable 0 255 N 0 5 7 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 5 range 0-0xff pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xd0000-0xdffff pcib0: decoding 3 range 0xe0000000-0xf7ffffff pcib0: decoding 3 range 0xfc000000-0xfebfffff pcib0: decoding 3 range 0xfec10000-0xfecfffff pcib0: decoding 3 range 0xfed1c000-0xfed1ffff pcib0: decoding 3 range 0xfed90000-0xfed9ffff pcib0: decoding 3 range 0xfed40000-0xfed44fff pcib0: decoding 3 range 0xfeda7000-0xfedfffff pcib0: decoding 3 range 0xfee10000-0xff9fffff pcib0: decoding 3 range 0xffc00000-0xffdfffff pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x8086, dev=3D0x2a40, revid=3D0x07 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x2090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x2a41, revid=3D0x07 domain=3D0, bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x1a (6500 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D255 powerspec 3 supports D0 D3 current D0 MSI supports 1 message secbus=3D1, subbus=3D1 found-> vendor=3D0x8086, dev=3D0x2a44, revid=3D0x07 domain=3D0, bus=3D0, slot=3D3, func=3D0 class=3D07-80-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0006, statreg=3D0x0018, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf6fd9ef0, size 4, enabled pcib0: allocated type 3 (0xf6fd9ef0-0xf6fd9eff) for rid 10 of pci0:0:3:0 pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x2a46, revid=3D0x07 domain=3D0, bus=3D0, slot=3D3, func=3D2 class=3D01-01-85, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type I/O Port, range 32, base 0xef78, size 3, enabled pcib0: allocated type 4 (0xef78-0xef7f) for rid 10 of pci0:0:3:2 map[14]: type I/O Port, range 32, base 0xef70, size 2, enabled pcib0: allocated type 4 (0xef70-0xef73) for rid 14 of pci0:0:3:2 map[18]: type I/O Port, range 32, base 0xef80, size 3, enabled pcib0: allocated type 4 (0xef80-0xef87) for rid 18 of pci0:0:3:2 map[1c]: type I/O Port, range 32, base 0xef74, size 2, enabled pcib0: allocated type 4 (0xef74-0xef77) for rid 1c of pci0:0:3:2 map[20]: type I/O Port, range 32, base 0xef90, size 4, enabled pcib0: allocated type 4 (0xef90-0xef9f) for rid 20 of pci0:0:3:2 pcib0: matched entry for 0.3.INTC pcib0: slot 3 INTC hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x2a47, revid=3D0x07 domain=3D0, bus=3D0, slot=3D3, func=3D3 class=3D07-00-02, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type I/O Port, range 32, base 0xef88, size 3, enabled pcib0: allocated type 4 (0xef88-0xef8f) for rid 10 of pci0:0:3:3 map[14]: type Memory, range 32, base 0xf6fda000, size 12, enabled pcib0: allocated type 3 (0xf6fda000-0xf6fdafff) for rid 14 of pci0:0:3:3 pcib0: matched entry for 0.3.INTB pcib0: slot 3 INTB hardwired to IRQ 17 found-> vendor=3D0x8086, dev=3D0x10f5, revid=3D0x03 domain=3D0, bus=3D0, slot=3D25, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf6fe0000, size 17, enabled pcib0: allocated type 3 (0xf6fe0000-0xf6ffffff) for rid 10 of pci0:0:25:0 map[14]: type Memory, range 32, base 0xf6fdb000, size 12, enabled pcib0: allocated type 3 (0xf6fdb000-0xf6fdbfff) for rid 14 of pci0:0:25:0 map[18]: type I/O Port, range 32, base 0xefe0, size 5, enabled pcib0: allocated type 4 (0xefe0-0xefff) for rid 18 of pci0:0:25:0 pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 22 found-> vendor=3D0x8086, dev=3D0x2937, revid=3D0x03 domain=3D0, bus=3D0, slot=3D26, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D3 map[20]: type I/O Port, range 32, base 0x6f60, size 5, enabled pcib0: allocated type 4 (0x6f60-0x6f7f) for rid 20 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 20 found-> vendor=3D0x8086, dev=3D0x2938, revid=3D0x03 domain=3D0, bus=3D0, slot=3D26, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[20]: type I/O Port, range 32, base 0x6f80, size 5, enabled pcib0: allocated type 4 (0x6f80-0x6f9f) for rid 20 of pci0:0:26:1 pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=3D0x8086, dev=3D0x2939, revid=3D0x03 domain=3D0, bus=3D0, slot=3D26, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D10 map[20]: type I/O Port, range 32, base 0x6fa0, size 5, enabled pcib0: allocated type 4 (0x6fa0-0x6fbf) for rid 20 of pci0:0:26:2 pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 22 found-> vendor=3D0x8086, dev=3D0x293c, revid=3D0x03 domain=3D0, bus=3D0, slot=3D26, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfed1c400, size 10, enabled pcib0: allocated type 3 (0xfed1c400-0xfed1c7ff) for rid 10 of pci0:0:26:7 pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 22 found-> vendor=3D0x8086, dev=3D0x293e, revid=3D0x03 domain=3D0, bus=3D0, slot=3D27, func=3D0 class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf6fdc000, size 14, enabled pcib0: allocated type 3 (0xf6fdc000-0xf6fdffff) for rid 10 of pci0:0:27:0 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=3D0x8086, dev=3D0x2940, revid=3D0x03 domain=3D0, bus=3D0, slot=3D28, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message secbus=3D11, subbus=3D11 found-> vendor=3D0x8086, dev=3D0x2942, revid=3D0x03 domain=3D0, bus=3D0, slot=3D28, func=3D1 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message secbus=3D12, subbus=3D12 found-> vendor=3D0x8086, dev=3D0x2944, revid=3D0x03 domain=3D0, bus=3D0, slot=3D28, func=3D2 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message secbus=3D13, subbus=3D13 found-> vendor=3D0x8086, dev=3D0x2946, revid=3D0x03 domain=3D0, bus=3D0, slot=3D28, func=3D3 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x00 (0 ns) intpin=3Dd, irq=3D255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message secbus=3D14, subbus=3D15 found-> vendor=3D0x8086, dev=3D0x2934, revid=3D0x03 domain=3D0, bus=3D0, slot=3D29, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D3 map[20]: type I/O Port, range 32, base 0x6f00, size 5, enabled pcib0: allocated type 4 (0x6f00-0x6f1f) for rid 20 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 20 found-> vendor=3D0x8086, dev=3D0x2935, revid=3D0x03 domain=3D0, bus=3D0, slot=3D29, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[20]: type I/O Port, range 32, base 0x6f20, size 5, enabled pcib0: allocated type 4 (0x6f20-0x6f3f) for rid 20 of pci0:0:29:1 pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 21 found-> vendor=3D0x8086, dev=3D0x2936, revid=3D0x03 domain=3D0, bus=3D0, slot=3D29, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D10 map[20]: type I/O Port, range 32, base 0x6f40, size 5, enabled pcib0: allocated type 4 (0x6f40-0x6f5f) for rid 20 of pci0:0:29:2 pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 22 found-> vendor=3D0x8086, dev=3D0x293a, revid=3D0x03 domain=3D0, bus=3D0, slot=3D29, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfed1c000, size 10, enabled pcib0: allocated type 3 (0xfed1c000-0xfed1c3ff) for rid 10 of pci0:0:29:7 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 20 found-> vendor=3D0x8086, dev=3D0x2448, revid=3D0x93 domain=3D0, bus=3D0, slot=3D30, func=3D0 class=3D06-04-01, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x00 (0 ns) secbus=3D3, subbus=3D4 found-> vendor=3D0x8086, dev=3D0x2917, revid=3D0x03 domain=3D0, bus=3D0, slot=3D31, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x2929, revid=3D0x03 domain=3D0, bus=3D0, slot=3D31, func=3D2 class=3D01-06-01, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dd, irq=3D10 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0x6e70, size 3, enabled pcib0: allocated type 4 (0x6e70-0x6e77) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x6e78, size 2, enabled pcib0: allocated type 4 (0x6e78-0x6e7b) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x6e80, size 3, enabled pcib0: allocated type 4 (0x6e80-0x6e87) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x6e88, size 2, enabled pcib0: allocated type 4 (0x6e88-0x6e8b) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x6ea0, size 5, enabled pcib0: allocated type 4 (0x6ea0-0x6ebf) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xfed1c800, size 11, enabled pcib0: allocated type 3 (0xfed1c800-0xfed1cfff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTD pcib0: slot 31 INTD hardwired to IRQ 19 found-> vendor=3D0x8086, dev=3D0x2930, revid=3D0x03 domain=3D0, bus=3D0, slot=3D31, func=3D3 class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0103, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D5 map[10]: type Memory, range 64, base 0xf6fd9f00, size 8, enabled pcib0: allocated type 3 (0xf6fd9f00-0xf6fd9fff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0x1100, size 5, enabled pcib0: allocated type 4 (0x1100-0x111f) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: at device 1.0 on pci0 pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib1 pcib0: allocated type 3 (0xf2000000-0xf6efffff) for rid 20 of pcib1 pcib0: allocated type 3 (0xe0000000-0xefffffff) for rid 24 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xf2000000-0xf6efffff pcib1: prefetched decode 0xe0000000-0xefffffff pcib1: special decode VGA pci1: on pcib1 pcib1: allocated bus range (1-1) for rid 0 of pci1 pci1: domain=3D0, physical bus=3D1 found-> vendor=3D0x10de, dev=3D0x065c, revid=3D0xa1 domain=3D0, bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf5000000, size 24, enabled pcib1: allocated memory range (0xf5000000-0xf5ffffff) for rid 10 of pci0:1:= 0:0 map[14]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, ena= bled pcib1: allocated prefetch range (0xe0000000-0xefffffff) for rid 14 of pci0:= 1:0:0 map[1c]: type Memory, range 64, base 0xf2000000, size 25, enabled pcib1: allocated memory range (0xf2000000-0xf3ffffff) for rid 1c of pci0:1:= 0:0 map[24]: type I/O Port, range 32, base 0xdf00, size 7, enabled pcib1: allocated I/O port range (0xdf00-0xdf7f) for rid 24 of pci0:1:0:0 pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 vgapci0: port 0xdf00-0xdf7f mem 0xf5000000-0xf5fff= fff,0xe0000000-0xefffffff,0xf2000000-0xf3ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 52 vgapci0: using IRQ 256 for MSI vgapci0: child nvidia0 requested pci_enable_io vgapci0: Boot video device pci0: at device 3.0 (no driver attached) atapci0: port 0xef78-0xef7f,0xef70-0xef73,0xef80-0xe= f87,0xef74-0xef77,0xef90-0xef9f irq 18 at device 3.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 53 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 pci0: at device 3.3 (no driver attached) em0: port 0xefe0-0xefff mem 0x= f6fe0000-0xf6ffffff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 on pci0 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 54 em0: using IRQ 257 for MSI em0: Using an MSI interrupt em0: bpf attached em0: Ethernet address: 00:26:b9:aa:25:f7 uhci0: port 0x6f60-0x6f7f irq 20 at de= vice 26.0 on pci0 uhci0: LegSup =3D 0x2f00 usbus0 on uhci0 uhci0: usbpf: Attached uhci1: port 0x6f80-0x6f9f irq 21 at de= vice 26.1 on pci0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 55 uhci1: LegSup =3D 0x2f00 usbus1 on uhci1 uhci1: usbpf: Attached uhci2: port 0x6fa0-0x6fbf irq 22 at de= vice 26.2 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 56 uhci2: LegSup =3D 0x2f00 usbus2 on uhci2 uhci2: usbpf: Attached ehci0: mem 0xfed1c400-0xfed1c7ff i= rq 22 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 ehci0: usbpf: Attached hdac0: mem 0xf6fdc000-0xf6fdffff irq 21 at de= vice 27.0 on pci0 hdac0: PCI card vendor: 0x1028, device: 0x0250 hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=3D0x00000000 off=3D0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 258 to local APIC 0 vector 57 hdac0: using IRQ 258 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib2: at device 28.0 on pci0 pcib2: domain 0 pcib2: secondary bus 11 pcib2: subordinate bus 11 pci11: on pcib2 pcib2: allocated bus range (11-11) for rid 0 of pci11 pci11: domain=3D0, physical bus=3D11 pcib3: at device 28.1 on pci0 pcib0: allocated type 3 (0xf1f00000-0xf1ffffff) for rid 20 of pcib3 pcib3: domain 0 pcib3: secondary bus 12 pcib3: subordinate bus 12 pcib3: memory decode 0xf1f00000-0xf1ffffff pci12: on pcib3 pcib3: allocated bus range (12-12) for rid 0 of pci12 pci12: domain=3D0, physical bus=3D12 found-> vendor=3D0x8086, dev=3D0x4232, revid=3D0x00 domain=3D0, bus=3D12, slot=3D0, func=3D0 class=3D02-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf1ffe000, size 13, enabled pcib3: allocated memory range (0xf1ffe000-0xf1ffffff) for rid 10 of pci0:12= :0:0 pcib3: matched entry for 12.0.INTA pcib3: slot 0 INTA hardwired to IRQ 17 iwn0: mem 0xf1ffe000-0xf1ffffff irq 17 at device 0.0= on pci12 iwn0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 259 to local APIC 0 vector 58 iwn0: using IRQ 259 for MSI iwn0: MIMO 1T2R, MoW, address 00:24:d6:7a:03:ce iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbp= s 36Mbps 48Mbps 54Mbps iwn0: 1T2R iwn0: 11na MCS 20MHz iwn0: MCS 0-7: 6.5Mbps - 65Mbps iwn0: 11na MCS 20MHz SGI iwn0: MCS 0-7: 7Mbps - 72Mbps iwn0: 11na MCS 40MHz: iwn0: MCS 0-7: 13.5Mbps - 135Mbps iwn0: 11na MCS 40MHz SGI: iwn0: MCS 0-7: 15Mbps - 150Mbps iwn0: 11ng MCS 20MHz iwn0: MCS 0-7: 6.5Mbps - 65Mbps iwn0: 11ng MCS 20MHz SGI iwn0: MCS 0-7: 7Mbps - 72Mbps iwn0: 11ng MCS 40MHz: iwn0: MCS 0-7: 13.5Mbps - 135Mbps iwn0: 11ng MCS 40MHz SGI: iwn0: MCS 0-7: 15Mbps - 150Mbps pcib4: at device 28.2 on pci0 pcib4: domain 0 pcib4: secondary bus 13 pcib4: subordinate bus 13 pci13: on pcib4 pcib4: allocated bus range (13-13) for rid 0 of pci13 pci13: domain=3D0, physical bus=3D13 pcib5: at device 28.3 on pci0 pcib0: allocated type 4 (0xc000-0xcfff) for rid 1c of pcib5 pcib0: allocated type 3 (0xf1c00000-0xf1efffff) for rid 20 of pcib5 pcib0: allocated type 3 (0xf0000000-0xf01fffff) for rid 24 of pcib5 pcib5: domain 0 pcib5: secondary bus 14 pcib5: subordinate bus 15 pcib5: I/O decode 0xc000-0xcfff pcib5: memory decode 0xf1c00000-0xf1efffff pcib5: prefetched decode 0xf0000000-0xf01fffff pci14: on pcib5 pcib5: allocated bus range (14-14) for rid 0 of pci14 pci14: domain=3D0, physical bus=3D14 uhci3: port 0x6f00-0x6f1f irq 20 at de= vice 29.0 on pci0 uhci3: LegSup =3D 0x2f00 usbus4 on uhci3 uhci3: usbpf: Attached uhci4: port 0x6f20-0x6f3f irq 21 at de= vice 29.1 on pci0 uhci4: LegSup =3D 0x2f00 usbus5 on uhci4 uhci4: usbpf: Attached uhci5: port 0x6f40-0x6f5f irq 22 at de= vice 29.2 on pci0 uhci5: LegSup =3D 0x2f00 usbus6 on uhci5 uhci5: usbpf: Attached ehci1: mem 0xfed1c000-0xfed1c3ff i= rq 20 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 ehci1: usbpf: Attached pcib6: at device 30.0 on pci0 pcib0: allocated type 3 (0xf1b00000-0xf1bfffff) for rid 20 of pcib6 pcib6: domain 0 pcib6: secondary bus 3 pcib6: subordinate bus 4 pcib6: memory decode 0xf1b00000-0xf1bfffff pcib6: special decode subtractive pci3: on pcib6 pcib6: allocated bus range (3-3) for rid 0 of pci3 pci3: domain=3D0, physical bus=3D3 found-> vendor=3D0x1180, dev=3D0x0476, revid=3D0xba domain=3D0, bus=3D3, slot=3D1, func=3D0 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0210, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x07 (1750 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, enabled pcib6: matched entry for 3.1.INTA pcib6: slot 1 INTA hardwired to IRQ 19 secbus=3D4, subbus=3D4 pcib6: allocated bus range (4-4) for rid 0 of pci0:3:1:0 found-> vendor=3D0x1180, dev=3D0x0832, revid=3D0x04 domain=3D0, bus=3D3, slot=3D1, func=3D1 class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0106, statreg=3D0x0210, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x04 (1000 ns) intpin=3Db, irq=3D5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf1bff800, size 11, enabled pcib6: allocated memory range (0xf1bff800-0xf1bfffff) for rid 10 of pci0:3:= 1:1 pcib6: matched entry for 3.1.INTB pcib6: slot 1 INTB hardwired to IRQ 17 found-> vendor=3D0x1180, dev=3D0x0822, revid=3D0x21 domain=3D0, bus=3D3, slot=3D1, func=3D2 class=3D08-05-01, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0106, statreg=3D0x0210, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf1bff600, size 8, enabled pcib6: allocated memory range (0xf1bff600-0xf1bff6ff) for rid 10 of pci0:3:= 1:2 pcib6: matched entry for 3.1.INTC pcib6: slot 1 INTC hardwired to IRQ 18 found-> vendor=3D0x1180, dev=3D0x0843, revid=3D0x11 domain=3D0, bus=3D3, slot=3D1, func=3D3 class=3D08-80-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0106, statreg=3D0x0210, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf1bff700, size 8, enabled pcib6: allocated memory range (0xf1bff700-0xf1bff7ff) for rid 10 of pci0:3:= 1:3 pcib6: matched entry for 3.1.INTC pcib6: slot 1 INTC hardwired to IRQ 18 cbb0: irq 19 at device 1.0 on pci3 pcib6: allocated memory range (0xf1b00000-0xf1b00fff) for rid 10 of cbb0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xf1b00000 cardbus0: on cbb0 cbb0: allocated bus range (4-4) for rid 0 of cardbus0 pccard0: <16-bit PCCard bus> on cbb0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 59 cbb0: PCI Configuration space: 0x00: 0x04761180 0x02100107 0x060700ba 0x00824010=20 0x10: 0xf1b00000 0x020000dc 0x20040403 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc=20 0x30: 0x00000000 0xfffffffc 0x00000000 0x07000113=20 0x40: 0x02501028 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x30a00001 0x00000000 0x04630463 0x00000000=20 0x90: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xa0: 0x00000008 0x08000000 0x00000000 0x00000000=20 0xb0: 0x00000000 0xb0000000 0x00003000 0x00000000=20 0xc0: 0x02501028 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0xfe0a0001=20 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 pci3: at device 1.1 (no driver attached) sdhci_pci0: mem 0xf1bff600-0xf1bff6ff irq 18 at device 1.= 2 on pci3 sdhci_pci0-slot0: 33MHz HS 4bits 3.3V DMA sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUMP = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x00000400 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x01f20000 | Host ctl: 0x00000000 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000000 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x00000000 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x01e021a1 | Max curr: 0x00000040 sdhci_pci0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_pci0: 1 slot(s) allocated pci3: at device 1.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x6e70-0x6e77,0x6e78-0x6e7b,= 0x6e80-0x6e87,0x6e88-0x6e8b,0x6ea0-0x6ebf mem 0xfed1c800-0xfed1cfff irq 19 = at device 31.2 on pci0 ahci0: attempting to allocate 16 MSI vectors (16 supported) msi: routing MSI IRQ 260 to local APIC 0 vector 64 msi: routing MSI IRQ 261 to local APIC 0 vector 65 msi: routing MSI IRQ 262 to local APIC 0 vector 66 msi: routing MSI IRQ 263 to local APIC 0 vector 67 msi: routing MSI IRQ 264 to local APIC 0 vector 68 msi: routing MSI IRQ 265 to local APIC 0 vector 69 msi: routing MSI IRQ 266 to local APIC 0 vector 70 msi: routing MSI IRQ 267 to local APIC 0 vector 71 msi: routing MSI IRQ 268 to local APIC 0 vector 72 msi: routing MSI IRQ 269 to local APIC 0 vector 73 msi: routing MSI IRQ 270 to local APIC 0 vector 74 msi: routing MSI IRQ 271 to local APIC 0 vector 75 msi: routing MSI IRQ 272 to local APIC 0 vector 76 msi: routing MSI IRQ 273 to local APIC 0 vector 77 msi: routing MSI IRQ 274 to local APIC 0 vector 78 msi: routing MSI IRQ 275 to local APIC 0 vector 79 ahci0: using IRQs 260-275 for MSI ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd CCC EM= eSATA 4ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: at channel 1 on ahci0 ahcich1: Caps: HPCP ESP ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: at channel 4 on ahci0 ahcich4: Caps: HPCP ESP ahcich5: at channel 5 on ahci0 ahcich5: Caps: HPCP ESP ahciem0: on ahci0 ahciem0: Caps: ALHD XMT SMB LED ichsmb0: port 0x1100-0x111f mem 0xf6= fd9f00-0xf6fd9fff irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on ac= pi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 60 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 61 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00004000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ACPI: Enabled 2 GPEs in block 00 to 3F 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 ex_isa_identify() pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete 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 pcib0: allocated type 3 (0xd0000-0xd07ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd0800-0xd0fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd1000-0xd17ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 2 of orm0 pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 2 of orm0 pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 2 of orm0 pcib0: allocated type 3 (0xda000-0xda7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xda800-0xdafff) for rid 2 of orm0 pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 2 of orm0 pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 2 of orm0 pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xdd800-0xddfff) for rid 2 of orm0 pcib0: allocated type 3 (0xde000-0xde7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xde800-0xdefff) for rid 2 of orm0 pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 2 of orm0 pcib0: allocated type 3 (0xdf800-0xdffff) for rid 2 of orm0 isa_probe_children: disabling PnP devices pmtimer0 on isa0 atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xce7ff,0xce800-0xcffff pnpid ORM0= 000 on isa0 pcf0 failed to probe on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> 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 pcib0: allocated type 4 (0x1f0-0x1f7) for rid 0 of ata0 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 1 of ata0 pcib0: allocated type 4 (0x1f0-0x1f7) for rid 0 of ata0 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 1 of ata0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 pcib0: allocated type 4 (0x1f0-0x1f7) for rid 0 of ata0 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 1 of ata0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 62 pcib0: allocated type 4 (0x170-0x177) for rid 0 of ata1 pcib0: allocated type 4 (0x376-0x376) for rid 1 of ata1 pcib0: allocated type 4 (0x170-0x177) for rid 0 of ata1 pcib0: allocated type 4 (0x376-0x376) for rid 1 of ata1 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 pcib0: allocated type 4 (0x170-0x177) for rid 0 of ata1 pcib0: allocated type 4 (0x376-0x376) for rid 1 of ata1 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 63 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: parallel port not found. ppc0 failed to probe at irq 7 on isa0 pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 uart0 failed to probe at port 0x3f8-0x3ff irq 4 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 coretemp0: on cpu0 coretemp0: Setting TjMax=3D100 est0: on cpu0 coretemp1: on cpu1 coretemp1: Setting TjMax=3D100 est1: on cpu1 Device configuration finished. procfs registered Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining Linux ELF exec handler installed tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768 ipfw2 (+ipv6) initialized, divert enabled, nat loadable, default to deny, l= ogging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded lo0: bpf attached load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded hptnr: no controller detected. hptrr: no controller detected. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x10280250 hdaa0: NumGPIO=3D8 NumGPO=3D0 NumGPI=3D0 GPIWake=3D1 GPIUnsol=3D1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: GPIO2: disabled hdaa0: GPIO3: disabled hdaa0: GPIO4: disabled hdaa0: GPIO5: disabled hdaa0: GPIO6: disabled hdaa0: GPIO7: disabled hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 10 0421101f 1 15 Headphones Jack 1/8 Right Black 0 hdaa0: 11 04a11021 2 1 Mic Jack 1/8 Right Black 0 hdaa0: 12 40f000f0 15 0 Other None Unknown 0x00 Unknown 0 hdaa0: 13 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 14 23a1102e 2 14 Mic Jack 1/8 Ext-Left Black 0 hdaa0: 15 23011050 5 0 Line-out Jack 1/8 Ext-Left Black 0 hdaa0: 20 40f000f2 15 2 Other None Unknown 0x00 Unknown 0 hdaa0: 24 90a601a0 10 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 25 40f000f4 15 4 Other None Unknown 0x00 Unknown 0 hdaa0: 30 014613b0 11 0 SPDIF-out Jack Digital Rear Black 3 hdaa0: 31 40f000f6 15 6 Other None Unknown 0x00 Unknown 0 hdaa0: 32 40f000f7 15 7 Other None Unknown 0x00 Unknown 0 hdaa0: 39 40f000f0 15 0 Other None Unknown 0x00 Unknown 0 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 10 0421101f 1 15 Headphones Jack 1/8 Right Black 0 hdaa0: 11 04a11021 2 1 Mic Jack 1/8 Right Black 0 hdaa0: 12 40f000f0 15 0 Other None Unknown 0x00 Unknown 0 D= ISA hdaa0: 13 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 14 23a1102e 2 14 Mic Jack 1/8 Ext-Left Black 0 hdaa0: 15 23011050 5 0 Line-out Jack 1/8 Ext-Left Black 0 hdaa0: 20 40f000f2 15 2 Other None Unknown 0x00 Unknown 0 D= ISA hdaa0: 24 90a601a0 10 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 25 40f000f4 15 4 Other None Unknown 0x00 Unknown 0 D= ISA hdaa0: 30 014613b0 11 0 SPDIF-out Jack Digital Rear Black 3 hdaa0: 31 40f000f6 15 6 Other None Unknown 0x00 Unknown 0 D= ISA hdaa0: 32 40f000f7 15 7 Other None Unknown 0x00 Unknown 0 D= ISA hdaa0: 39 40f000f0 15 0 Other None Unknown 0x00 Unknown 0 D= ISA hdaa0: 5 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=3D13 seq=3D0 hdaa0: Pin nid=3D10 seq=3D15 hdaa0: Association 1 (2) in: hdaa0: Pin nid=3D11 seq=3D1 hdaa0: Pin nid=3D14 seq=3D14 hdaa0: Association 2 (5) out: hdaa0: Pin nid=3D15 seq=3D0 hdaa0: Association 3 (10) in: hdaa0: Pin nid=3D24 seq=3D0 hdaa0: Association 4 (11) out: hdaa0: Pin nid=3D30 seq=3D0 hdaa0: Tracing association 0 (1) hdaa0: Pin 13 traced to DAC 16 hdaa0: Pin 10 traced to DAC 16 and hpredir 0 hdaa0: Association 0 (1) trace succeeded hdaa0: Tracing association 1 (2) hdaa0: Pin 11 traced to ADC 18 hdaa0: Pin 14 traced to ADC 18 hdaa0: Association 1 (2) trace succeeded hdaa0: Tracing association 2 (5) hdaa0: Pin 15 traced to DAC 17 hdaa0: Association 2 (5) trace succeeded hdaa0: Tracing association 3 (10) hdaa0: Pin 24 traced to ADC 19 hdaa0: Association 3 (10) trace succeeded hdaa0: Tracing association 4 (11) hdaa0: Pin 30 traced to DAC 33 hdaa0: Association 4 (11) trace succeeded hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Looking for additional ADC for association 1 (2) hdaa0: Looking for additional DAC for association 2 (5) hdaa0: Looking for additional ADC for association 3 (10) hdaa0: Looking for additional DAC for association 4 (11) hdaa0: Tracing input monitor hdaa0: Tracing nid 23 to out hdaa0: nid 23 is input monitor hdaa0: Tracing other input monitors hdaa0: Tracing nid 11 to out hdaa0: Tracing nid 14 to out hdaa0: Tracing nid 24 to out hdaa0: Tracing beeper hdaa0: Headphones redirection for association 0 nid=3D10 using unsolicited = responses. hdaa0: Redirect output to: main hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 13,10 and 11,14 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e07e0 16 20 24 bits, 44 48 88 96 176 192 KHz pcm0: DAC: 16 pcm0:=20 pcm0: nid=3D13 [pin: Speaker (Fixed)] pcm0: + <- nid=3D16 [audio output] [src: pcm] pcm0:=20 pcm0: nid=3D10 [pin: Headphones (Black Jack)] pcm0: + <- nid=3D16 [audio output] [src: pcm] pcm0:=20 pcm0: Record: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e07e0 16 20 24 bits, 44 48 88 96 176 192 KHz pcm0: ADC: 18 pcm0:=20 pcm0: nid=3D18 [audio input] pcm0: + <- nid=3D28 [audio selector] [src: line, mic, mix] pcm0: + <- nid=3D26 [audio selector] [src: line, mic] pcm0: + <- nid=3D11 [pin: Mic (Black Jack)] [src: mic] pcm0: + <- nid=3D14 [pin: Mic (Black Jack)] [src: line] pcm0: + <- nid=3D23 [audio mixer] [src: mix] pcm0:=20 pcm0: Input Mix: pcm0:=20 pcm0: nid=3D23 [audio mixer] pcm0: + <- nid=3D26 [audio selector] [src: line, mic] pcm0: + <- nid=3D11 [pin: Mic (Black Jack)] [src: mic] pcm0: + <- nid=3D14 [pin: Mic (Black Jack)] [src: line] pcm0: + <- nid=3D27 [audio selector] [src: line, mic] pcm0: + <- nid=3D11 [pin: Mic (Black Jack)] [src: mic] pcm0: + <- nid=3D14 [pin: Mic (Black Jack)] [src: line] pcm0:=20 pcm0: Master Volume (OSS: vol): -95/0dB pcm0: +- ctl 1 (nid 16 out): -95/0dB (128 steps) + mute pcm0:=20 pcm0: PCM Volume (OSS: pcm): -95/0dB pcm0: +- ctl 1 (nid 16 out): -95/0dB (128 steps) + mute pcm0:=20 pcm0: Microphone Volume (OSS: mic): 0/30dB pcm0: +- ctl 6 (nid 23 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 7 (nid 23 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 10 (nid 26 out): 0/30dB (4 steps) pcm0: +- ctl 11 (nid 27 out): 0/30dB (4 steps) pcm0: +- ctl 12 (nid 28 out): 0/22dB (16 steps) + mute pcm0:=20 pcm0: Line-in Volume (OSS: line): 0/30dB pcm0: +- ctl 6 (nid 23 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 7 (nid 23 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 10 (nid 26 out): 0/30dB (4 steps) pcm0: +- ctl 11 (nid 27 out): 0/30dB (4 steps) pcm0: +- ctl 12 (nid 28 out): 0/22dB (16 steps) + mute pcm0:=20 pcm0: Speaker/Beep Volume (OSS: speaker): -18/0dB pcm0: +- ctl 14 (nid 38 out): -18/0dB (4 steps) + mute pcm0:=20 pcm0: Recording Level (OSS: rec): 0/22dB pcm0: +- ctl 6 (nid 23 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 7 (nid 23 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 11 (nid 27 out): 0/30dB (4 steps) pcm0: +- ctl 12 (nid 28 out): 0/22dB (16 steps) + mute pcm0:=20 pcm0: Input Mix Level (OSS: mix): 0/22dB pcm0: +- ctl 12 (nid 28 out): 0/22dB (16 steps) + mute pcm0:=20 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Playback channel set is: Front Left, Front Right,=20 pcm0: Playback channel matrix is: 2.0 (unknown) pcm0: Recording channel set is: Front Left, Front Right,=20 pcm0: Recording channel matrix is: 2.0 (disconnected) pcm1: at nid 15 and 24 on hdaa0 pcm1: Playback: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e07e0 16 20 24 bits, 44 48 88 96 176 192 KHz pcm1: DAC: 17 pcm1:=20 pcm1: nid=3D15 [pin: Line-out (Black Jack)] pcm1: + <- nid=3D17 [audio output] [src: pcm] pcm1:=20 pcm1: Record: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e07e0 16 20 24 bits, 44 48 88 96 176 192 KHz pcm1: ADC: 19 pcm1:=20 pcm1: nid=3D19 [audio input] pcm1: + <- nid=3D29 [audio selector] [src: monitor] pcm1: + <- nid=3D24 [pin: Mic (Fixed)] [src: monitor] pcm1:=20 pcm1: Master Volume (OSS: vol): -95/0dB pcm1: +- ctl 2 (nid 17 out): -95/0dB (128 steps) + mute pcm1:=20 pcm1: PCM Volume (OSS: pcm): -95/0dB pcm1: +- ctl 2 (nid 17 out): -95/0dB (128 steps) + mute pcm1:=20 pcm1: Microphone2 Volume (OSS: monitor): 0/22dB pcm1: +- ctl 13 (nid 29 out): 0/22dB (16 steps) + mute pcm1:=20 pcm1: Recording Level (OSS: rec): 0/22dB pcm1: +- ctl 13 (nid 29 out): 0/22dB (16 steps) + mute pcm1:=20 pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "rec": pcm1: Mixer "monitor": pcm1: Playback channel set is: Front Left, Front Right,=20 pcm1: Playback channel matrix is: 2.0 (disconnected) pcm1: Automatically set rec source to: monitor pcm1: Recording channel set is: Front Left, Front Right,=20 pcm1: Recording channel matrix is: 2.0 (unknown) pcm2: at nid 30 on hdaa0 pcm2: Playback: pcm2: Stream cap: 0x00000005 AC3 PCM pcm2: PCM cap: 0x000e07e0 16 20 24 bits, 44 48 88 96 176 192 KHz pcm2: DAC: 33 pcm2:=20 pcm2: nid=3D30 [pin: SPDIF-out (Black Jack)] pcm2: + <- nid=3D36 [audio selector] [src: pcm] pcm2: + <- nid=3D33 [audio output] [src: pcm] pcm2:=20 pcm2: Mixer "vol" -> "none": child=3D0x00000010 pcm2: Mixer "pcm": parent=3D"vol" pcm2: Soft PCM mixer ENABLED pcm2: Playback channel set is: Front Left, Front Right,=20 pcm2: Playback channel matrix is: 2.0 (unknown) hdacc1: at cad 1 on hdac0 unknown: at nid 2 on hda= cc1 (no driver attached) hdacc1: Subsystem ID: 0xc2820b4c random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ata2: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f ugen0.1: at usbus0 uhub0: on usbus0 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen5.1: at usbus5 uhub3: on usbus5 ugen4.1: at usbus4 uhub4: on usbus4 ugen3.1: at usbus3 uhub5: on usbus3 ugen7.1: at usbus7 uhub6: on usbus7 ugen6.1: at usbus6 uhub7: on usbus6 ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub7: 2 ports with 2 removable, self powered ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat1=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 ata3: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat1=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 ahcich0: AHCI reset... ahcich0: SATA connect time=3D100us status=3D00000123 ahcich0: AHCI reset: device found ahcich1: AHCI reset... ahcich1: SATA connect timeout time=3D10000us status=3D00000000 ahcich1: AHCI reset: device not found ahcich4: AHCI reset... ahcich4: SATA connect timeout time=3D10000us status=3D00000000 ahcich4: AHCI reset: device not found ahcich5: AHCI reset... ahcich5: SATA connect timeout time=3D10000us status=3D00000000 ahcich5: AHCI reset: device not found ata0: reset tp1 mask=3D00 ostat0=3Dff ostat1=3Dff ata1: reset tp1 mask=3D00 ostat0=3Dff ostat1=3Dff acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery1: battery initialization start ahcich0: AHCI reset: device ready after 100ms Expensive timeout(9) function: 0xc056c0e0(0xcfd9b980) 0.005292921 s ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0: ATA-8 SATA 2.x device GEOM: new disk ada0 ada0: Serial Number 5YX1PYEL ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad8 pass0 at ahcich0 bus 0 scbus2 target 0 lun 0 pass0: ATA-8 SATA 2.x device pass0: Serial Number 5YX1PYEL pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahciem0 bus 0 scbus6 target 0 lun 0 pass1: SEMB S-E-S 2.00 device ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ses0: Generation Code 0x0 has 1 SubEnclosures ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, offse= t 8 ses0: WWN: 0 ses0: Type Desc[0]: Type 0x17, MaxElt 6, In Subenc 0, Text Length 0:=20 battery0: battery initialization done, tried 1 times Netvsc initializing... done! SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 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 1 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 1 vector 49 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 50 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 51 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 52 msi: Assigning MSI IRQ 257 to local APIC 1 vector 53 msi: Assigning MSI IRQ 259 to local APIC 1 vector 54 TSC timecounter disabled: C3 enabled. Timecounter "TSC" frequency 3059068114 Hz quality -1000 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. uhub5: 6 ports with 6 removable, self powered uhub6: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 Trying to mount root from ufs:/dev/ada0s4a [rw]... start_init: trying /sbin/init linprocfs registered lock order reversal: 1st 0xd05376dc ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2137 2nd 0xeb5f4878 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xd0d6b6dc ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2137 KDB: stack backtrace: db_trace_self_wrapper(c10bfca4,a,fa4d42a0,cf28704c,d0418cd0,...) at 0xc0526= 8cd =3D db_trace_self_wrapper+0x2d/frame 0xfa4d4260 kdb_backtrace(c10c3a16,d0d6b6dc,c10aa832,cf423c00,c10cd0fc,...) at 0xc0b078= 70 =3D kdb_backtrace+0x30/frame 0xfa4d42c4 witness_checkorder(d0d6b6dc,9,c10cd0fc,859,d0d6b6fc,...) at 0xc0b241f4 =3D = witness_checkorder+0xd04/frame 0xfa4d4310 __lockmgr_args(d0d6b6dc,80100,d0d6b6fc,0,0,...) at 0xc0aaea03 =3D __lockmgr= _args+0x8f3/frame 0xfa4d43f0 ffs_lock(fa4d4470,c10ca161,cf41b110,cf4219e0,cf41b110,...) at 0xc0d78c87 = =3D ffs_lock+0x87/frame 0xfa4d442c VOP_LOCK1_APV(c13555ec,fa4d4470,233,3f6,c1368f90,...) at 0xc0f8061a =3D VOP= _LOCK1_APV+0x10a/frame 0xfa4d4458 _vn_lock(d0d6b6a8,80100,c10cd0fc,859,c10cc345,...) at 0xc0b8f546 =3D _vn_lo= ck+0xa6/frame 0xfa4d4498 vget(d0d6b6a8,80100,d0535000,57,0,...) at 0xc0b7d624 =3D vget+0x74/frame 0x= fa4d44d0 vfs_hash_get(d046cd20,13990,80000,d0535000,fa4d45d0,...) at 0xc0b7103c =3D = vfs_hash_get+0xfc/frame 0xfa4d44fc ffs_vgetf(d046cd20,13990,80000,fa4d45d0,1,...) at 0xc0d73894 =3D ffs_vgetf+= 0x44/frame 0xfa4d4558 softdep_sync_buf(d05376a8,eb5f4820,1,0,0,...) at 0xc0d6adbf =3D softdep_syn= c_buf+0xbdf/frame 0xfa4d45e8 ffs_syncvnode(d05376a8,1,0,c132e258,0,...) at 0xc0d79b4d =3D ffs_syncvnode+= 0x2dd/frame 0xfa4d4640 ffs_truncate(d05376a8,200,0,880,d03e6880,...) at 0xc0d4df5b =3D ffs_truncat= e+0x6eb/frame 0xfa4d47f0 ufs_direnter(d05376a8,d0d6b6a8,fa4d48b8,fa4d4bcc,0,...) at 0xc0d8166e =3D u= fs_direnter+0x79e/frame 0xfa4d4870 ufs_makeinode(fa4d4bb8,fa4d4bcc) at 0xc0d8b1d4 =3D ufs_makeinode+0x534/fram= e 0xfa4d49f0 ufs_create(fa4d4ad8,669,d046cd30,2,d046cd74,...) at 0xc0d86e2f =3D ufs_crea= te+0x2f/frame 0xfa4d4a04 VOP_CREATE_APV(c13555ec,fa4d4ad8,fa4d4bcc,fa4d4a68,fa4d4a78,...) at 0xc0f7d= c9e =3D VOP_CREATE_APV+0xfe/frame 0xfa4d4a30 vn_open_cred(fa4d4b70,fa4d4bfc,1a4,0,d03e6880,d04d03b8) at 0xc0b8ec8e =3D v= n_open_cred+0x2ee/frame 0xfa4d4b00 vn_open(fa4d4b70,fa4d4bfc,1a4,d04d03b8,2882a5a8,...) at 0xc0b8e98d =3D vn_o= pen+0x3d/frame 0xfa4d4b28 kern_openat(d0535000,ffffff9c,2882a5a8,0,601,1b6) at 0xc0b87030 =3D kern_op= enat+0x310/frame 0xfa4d4c1c sys_open(d0535000,fa4d4cc8,c12806f2,e8,eb7dfc80,...) at 0xc0b86c89 =3D sys_= open+0x39/frame 0xfa4d4c40 syscall(fa4d4d08) at 0xc0f57eeb =3D syscall+0x31b/frame 0xfa4d4cfc Xint0x80_syscall() at 0xc0f3fd31 =3D Xint0x80_syscall+0x21/frame 0xfa4d4cfc --- syscall (5, FreeBSD ELF32, sys_open), eip =3D 0x2820dff3, esp =3D 0xbfb= fddf4, ebp =3D 0xbfbfdea8 --- ahcich4: CONNECT requested ahcich4: AHCI reset... ahcich4: SATA connect timeout time=3D10000us status=3D00000000 ahcich4: AHCI reset: device not found ahcich4: CONNECT requested ahcich4: AHCI reset... ahcich4: SATA connect timeout time=3D10000us status=3D00000000 ahcich4: AHCI reset: device not found ahcich4: CONNECT requested ahcich4: AHCI reset... ahcich4: SATA connect timeout time=3D10000us status=3D00000000 ahcich4: AHCI reset: device not found wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: 00:24:d6:7a:03:ce ahcich4: CONNECT requested ahcich4: AHCI reset... ahcich4: SATA connect timeout time=3D10000us status=3D00000000 ahcich4: AHCI reset: device not found ahcich4: CONNECT requested ahcich4: AHCI reset... ahcich4: SATA connect timeout time=3D10000us status=3D00000000 ahcich4: AHCI reset: device not found --EVQB43uFympFEer4-- --lGa3FpvTyf1CgKg0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT4ToQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7GcUP+wYl6GuwWG1rXyAqYrsaMkXb YnNqdV+3rbpGdCbyr+AU2uKmtvb8hPQfB0iffZv2EU9Q7F69O2oL6t+tr+EARikV 2eKPthHWmmGMGNsitYXTqP3AzbhiB3LOqWGtr/z3MpttYsWXGthhEnxb2Ev8f2M3 TUQkUEqBLAlGY0ab8fLlZokequRTp5gQR8RTQI1iZjgYDovSun7yqvPyIwg5M2b3 PkQ5OizZqx7O3dol3Mb5nMJbdJ5nNM9q0obGZ0HcmN2mOU99zXeYrTah5wN7D9rB UGhD083zlgRR/QwvgCjDK9yK/EUoyFDKiv1Qw801sDGgkluRaoiZTtGLxzBk40uc hR3LLtwWgWSUNPwgCSh28RyNK2DkRkCLL5DQrGvosjX2KdVAW0Z8MAdtEFn/IOko yJhBiGCdHpu2o8IthqFpCCYQZr6lKYvtFXnISXLtshNr6jp/ZhXLBXyOj6dCrsXY x1JZTjNHBgIs1DwYQY7zVUoGA878ZVuy1HWrS3mrCaTYEXJMTURI9wePW7ZLz4Uo 9AWGWSU2UD2Or/QEy0n/SE5aw/2ONZiEIqAs74/yBqa7Q0hGmJAWdMLciqW05xSe BQlfREXulOvh0H35Q8lfiG7IRqM8514dNGIrR/ufWxurfojYn/TbDpppXyHFdzKa qKx4PxzEx75rrSnZMrjc =UkZP -----END PGP SIGNATURE----- --lGa3FpvTyf1CgKg0-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 5 20:26:05 2014 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 ESMTPS id B0728DAC; Tue, 5 Aug 2014 20:26:05 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7137B21D8; Tue, 5 Aug 2014 20:26:05 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 4928258; Tue, 5 Aug 2014 16:25:56 -0400 (EDT) Message-ID: <53E13DD2.2020109@protected-networks.net> Date: Tue, 05 Aug 2014 16:25:54 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: John Baldwin , David Wolfskill Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 05 Aug 2014 20:26:05 -0000 On 08/05/14 16:02, John Baldwin wrote: >> Given that my build machine did not exhibit the symptoms, and given the >> references to atpic, it may be relevant to point out that the machine >> where I see the panic is a Dell Precision M4400 laptop. > > My guess is that the recent Xen changes tickled something. However, can you capture a verbose dmesg from your working kernel? I have the same (or similar) symptom on an old core-duo Toshiba. It seems to occur just before hwpmc would normally show in the log: kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 kernel: ada0: ATA-8 SATA 2.x device kernel: ada0: Serial Number 101105PCK404VLKU1WXJ kernel: ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) kernel: uhub2: 2 ports with 2 removable, self powered kernel: uhub3: 2 ports with 2 removable, self powered kernel: ada0: Command Queueing enabled kernel: ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) kernel: ada0: Previously was known as ad4 kernel: SMP: AP CPU #1 Launched! ** non working kernel panics here ** kernel: hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/2/40/0x3ff kernel: Timecounter "TSC" frequency 1662542340 Hz quality 1000 kernel: Root mount waiting for: usbus4 On another machine, which has 4 drives in two geom mirrors, it refuses to find ada0 or ada1. It reports a CAM timeout on the ATA-IDENTIFY phase with an apparently non-functioning interrupt problem. Reverting to a kernel built on July 27th restores normal behaviour, imb From owner-freebsd-current@FreeBSD.ORG Tue Aug 5 20:56:47 2014 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 ESMTPS id 94C95373; Tue, 5 Aug 2014 20:56:47 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5502B2578; Tue, 5 Aug 2014 20:56:47 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id E2A1558; Tue, 5 Aug 2014 16:56:45 -0400 (EDT) Message-ID: <53E1450D.5090708@protected-networks.net> Date: Tue, 05 Aug 2014 16:56:45 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: John Baldwin , David Wolfskill Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> In-Reply-To: OpenPGP: id=0442D492 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 05 Aug 2014 20:56:47 -0000 On 08/05/14 16:02, John Baldwin wrote: > My guess is that the recent Xen changes tickled something. I can confirm this on a kernel which is otherwise up to date .. FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 I backed out all of SVN r269507 through r269515. Now working .. ada0: ATA-8 SATA 2.x device ada0: Serial Number 101105PCK404VLKU1WXJ ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010200 err: 0x000000f0 pmc: 0x00010400 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 1 vector 49 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 1 vector 50 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 51 msi: Assigning MSI IRQ 256 to local APIC 1 vector 52 hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/2/40/0x3ff SMP: passed TSC synchronization test Timecounter "TSC" frequency 1662536220 Hz quality 1000 Root mount waiting for: usbus4 Now to see if it's related to the other machine's disk woes (it's a single-core device), imb From owner-freebsd-current@FreeBSD.ORG Tue Aug 5 21:29:58 2014 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 ESMTPS id 4E56DD6A; Tue, 5 Aug 2014 21:29:58 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [202.12.127.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 162BE289C; Tue, 5 Aug 2014 21:29:57 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id BFD0F58; Tue, 5 Aug 2014 17:29:54 -0400 (EDT) Message-ID: <53E14CD1.20308@protected-networks.net> Date: Tue, 05 Aug 2014 17:29:53 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: John Baldwin , David Wolfskill Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <53E1450D.5090708@protected-networks.net> In-Reply-To: <53E1450D.5090708@protected-networks.net> OpenPGP: id=0442D492 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 05 Aug 2014 21:29:58 -0000 On 08/05/14 16:56, Michael Butler wrote: > On 08/05/14 16:02, John Baldwin wrote: > >> My guess is that the recent Xen changes tickled something. > > I can confirm this on a kernel which is otherwise up to date .. > > FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD > 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 > > I backed out all of SVN r269507 through r269515. > > Now working .. [ .. snip .. ] > Now to see if it's related to the other machine's disk woes (it's a > single-core device), And it fixes the inability to probe disks on my single-core machine :-) imb From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 00:37:18 2014 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 ESMTPS id C0D93CD5; Wed, 6 Aug 2014 00:37:18 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F7852F78; Wed, 6 Aug 2014 00:37:18 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s760bGj1015168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Aug 2014 17:37:16 -0700 Message-ID: <53E178BC.4040201@freebsd.org> Date: Tue, 05 Aug 2014 17:37:16 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org, royger@freebsd.org, freebsd-x11@freebsd.org Subject: r259580 breaks radeonkms Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZUhfb3GqVphWsccc3Qiq9d0wHza/ubLLDAWmaKvsQmIggEBNXzg6NuSDLoBd9yon09+8R3uUtEQdlCr0ODH8UJCucHJGuckWM= X-Sonic-ID: C;5K3K0AEd5BGMXE8doK8kYw== M;/iEj0QEd5BGMXE8doK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 00:37:18 -0000 Kernels with r269580 will panic when loading the radeonkms driver in pmap_page_set_memattr(). This probably indicates a bug in radeonkms, but the system is unusable in the meantime. -Nathan From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 02:48:05 2014 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 ESMTPS id EDED896A for ; Wed, 6 Aug 2014 02:48:05 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C03702D37 for ; Wed, 6 Aug 2014 02:48:05 +0000 (UTC) Received: from bdrewery (uid 1298) (envelope-from bdrewery@freebsd.org) id cf0 by freefall.freebsd.org (DragonFly Mail Agent v0.9+); Wed, 06 Aug 2014 02:48:05 +0000 Received: (qmail 45620 invoked from network); 5 Aug 2014 21:48:04 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 5 Aug 2014 21:48:04 -0500 Message-ID: <53E1975D.4010703@FreeBSD.org> Date: Tue, 05 Aug 2014 21:47:57 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: current@FreeBSD.org Subject: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 02:48:06 -0000 Has anyone else encountered this? Got it while running poudriere. > NULL mp in getnewvnode() > [...] > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247d8e540 > vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247d8e590 > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247d8e7c0 > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xfffffe1247d8e840 > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame 0xfffffe1247d8e900 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame 0xfffffe1247d8e940 > sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247d8e990 > userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247d8ea30 > sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247d8eae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d8ebf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d8ebf0 Unfortunately I have no dump as the kmem was too large compared to my swap, and I didn't get to the console before some of the text was overwritten. Perhaps it will hit it again soon after reboot and I'll get a core. -- Regards, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 03:02:13 2014 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 ESMTPS id 6057CC6E for ; Wed, 6 Aug 2014 03:02:13 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34BD8204C for ; Wed, 6 Aug 2014 03:02:13 +0000 (UTC) Received: from bdrewery (uid 1298) (envelope-from bdrewery@freebsd.org) id cfa by freefall.freebsd.org (DragonFly Mail Agent v0.9+); Wed, 06 Aug 2014 03:02:13 +0000 Received: (qmail 14940 invoked from network); 5 Aug 2014 22:02:11 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 5 Aug 2014 22:02:11 -0500 Message-ID: <53E19AAC.8050204@FreeBSD.org> Date: Tue, 05 Aug 2014 22:02:04 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: current@FreeBSD.org Subject: Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() References: <53E1975D.4010703@FreeBSD.org> In-Reply-To: <53E1975D.4010703@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 03:02:13 -0000 On 8/5/2014 9:47 PM, Bryan Drewery wrote: > Has anyone else encountered this? Got it while running poudriere. > >> NULL mp in getnewvnode() >> [...] >> vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247d8e540 >> vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247d8e590 >> export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247d8e7c0 >> kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame >> 0xfffffe1247d8e840 >> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame >> 0xfffffe1247d8e900 >> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame >> 0xfffffe1247d8e940 >> sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247d8e990 >> userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247d8ea30 >> sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247d8eae0 >> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d8ebf0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d8ebf0 > > Unfortunately I have no dump as the kmem was too large compared to my > swap, and I didn't get to the console before some of the text was > overwritten. Perhaps it will hit it again soon after reboot and I'll get > a core. > It's quite possible that something was unmounting or even mounting during this call resulting in a race. I was doing 2 separate builds at once. -- Regards, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 03:19:39 2014 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 ESMTPS id 5AD86EEF; Wed, 6 Aug 2014 03:19:39 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0A0B2182; Wed, 6 Aug 2014 03:19:38 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s763JWb8038885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2014 06:19:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s763JWb8038885 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s763JW56038884; Wed, 6 Aug 2014 06:19:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 6 Aug 2014 06:19:32 +0300 From: Konstantin Belousov To: Bryan Drewery Subject: Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() Message-ID: <20140806031932.GE93733@kib.kiev.ua> References: <53E1975D.4010703@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bG3OVe1RvEtjCM5X" Content-Disposition: inline In-Reply-To: <53E1975D.4010703@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 03:19:39 -0000 --bG3OVe1RvEtjCM5X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: > Has anyone else encountered this? Got it while running poudriere. >=20 > > NULL mp in getnewvnode() > > [...] > > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247d8e540 > > vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247d8e590 > > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247d8e7c0 > > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xfffffe= 1247d8e840 > > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame 0xf= ffffe1247d8e900 > > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame 0= xfffffe1247d8e940 > > sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247d8e990 > > userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247d8ea30 > > sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247d8eae0 > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d8ebf0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d8ebf0 >=20 > Unfortunately I have no dump as the kmem was too large compared to my=20 > swap, and I didn't get to the console before some of the text was=20 > overwritten. Perhaps it will hit it again soon after reboot and I'll get= =20 > a core. "NULL mp in getnewvnode()" is only the printf(), it is not a panic or KASSERT. The event does not stop the machine, nor it prints the backtrace. You mentioned that you was unable to dump, so did the system paniced ? Without full log of the panic messages and backtrace, it is impossible to start guessing what the problem is. That said, the printf seemingly outlived its usefulness. --bG3OVe1RvEtjCM5X Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT4Z7DAAoJEJDCuSvBvK1BkcwP/A4MKPktAe1B3Md2nxOjSjjA X8FxCRdOsbhdLiiFsmn2GuV2bm8DZHZUH+fzM/m4pDkF09OJ3OKLzmdKE8fp6ZVG ss4CuxklBaC8O+UYZ7oy/cfwIosXlm+iaDwGDp39Uh1XMB5FhGx23x5oABxG7DTW FLbh0LAw9uLAvJv82m1Bi3LDj3EzQCo5m8s/MfbvPj+6PpEVNNUsxc8OZYZ6awUl HsG27dZPBu+XqutKxcJAzpc5CW8owQfnFV8tmXn4rcBgKT5RglJ/JT+L0SbdrOfd 0zgPVFn9pyKcn0QGU6W47GBGTk6i93OfPHyBIB7f0AOqd0w4W1ibyPagy3snwd4g dBAsMEtWxuBidQ5dbCnUGb6SrqhQqHGF6jcUQjEB1Adqt/yR51kHGN4HlvLITfdD f61B68qxRwxikk4pBjpKv3cCem4LdlMQBq6nztblHY0ZbCPym/O3/R9hA/YteBwR 76s5my79ioxj+2p9pk1LLmdIHUQQWaU6K2OJslAM0neGDj4T+1JBNgwmyRozHoxB 9Fwe5ZBNpR4JyN4KekWd0wsC/Hw8X+HQeUpe8WO3vqyr3WdKimsiFtxFY0ZEdjdb 4Qpvp6sU8In2sFODnoJvWeCt5znafX29Eh6stwvhnntjClNF899yatdMYnVUBr9m GrBndcWbZLNDP7RRHSsn =vL2Z -----END PGP SIGNATURE----- --bG3OVe1RvEtjCM5X-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 03:49:56 2014 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 ESMTPS id 6364C3FD; Wed, 6 Aug 2014 03:49:56 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3989424E3; Wed, 6 Aug 2014 03:49:56 +0000 (UTC) Received: from [192.168.1.75] (75-48-77-17.lightspeed.cncrca.sbcglobal.net [75.48.77.17]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A9130B913; Tue, 5 Aug 2014 23:49:51 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] From: John Baldwin In-Reply-To: <53E14CD1.20308@protected-networks.net> Date: Tue, 5 Aug 2014 20:49:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8B832384-C1CC-4622-BA67-7447ECE317C9@FreeBSD.org> References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <53E1450D.5090708@protected-networks.net> <53E14CD1.20308@protected-networks.net> To: Michael Butler X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 05 Aug 2014 23:49:53 -0400 (EDT) Cc: royger@FreeBSD.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 03:49:56 -0000 On Aug 5, 2014, at 2:29 PM, Michael Butler = wrote: > On 08/05/14 16:56, Michael Butler wrote: >> On 08/05/14 16:02, John Baldwin wrote: >>=20 >>> My guess is that the recent Xen changes tickled something. >>=20 >> I can confirm this on a kernel which is otherwise up to date .. >>=20 >> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD >> 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 >>=20 >> I backed out all of SVN r269507 through r269515. >>=20 >> Now working .. >=20 > [ .. snip .. ] >=20 >> Now to see if it's related to the other machine's disk woes (it's a >> single-core device), >=20 > And it fixes the inability to probe disks on my single-core machine = :-) It looks like the MADT code to probe the I/O APICs isn't working so it's = trying to fall back to using the ATPIC while using SMP (which doesn't = work). I know it's a pain on a laptop, but if it is at all possible to = capture either a verbose or non-verbose dmesg that would really help = narrow it down. Also, if anyone can try reverting just the MADT-related changes in the = recent Xen changes to see if you can narrow down which exact one = triggers the panic that would be really helpful. --=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 03:56:38 2014 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 ESMTPS id A3A2F5D3 for ; Wed, 6 Aug 2014 03:56:38 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 75DE3259E for ; Wed, 6 Aug 2014 03:56:38 +0000 (UTC) Received: from bdrewery (uid 1298) (envelope-from bdrewery@freebsd.org) id d0e by freefall.freebsd.org (DragonFly Mail Agent v0.9+); Wed, 06 Aug 2014 03:56:38 +0000 Received: (qmail 19330 invoked from network); 5 Aug 2014 22:56:33 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 5 Aug 2014 22:56:33 -0500 Message-ID: <53E1A76A.1070400@FreeBSD.org> Date: Tue, 05 Aug 2014 22:56:26 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: current@FreeBSD.org Subject: Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() References: <53E1975D.4010703@FreeBSD.org> <20140806031932.GE93733@kib.kiev.ua> In-Reply-To: <20140806031932.GE93733@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 03:56:38 -0000 On 8/5/2014 10:19 PM, Konstantin Belousov wrote: > On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: >> Has anyone else encountered this? Got it while running poudriere. >> >>> NULL mp in getnewvnode() >>> [...] >>> vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247d8e540 >>> vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247d8e590 >>> export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247d8e7c0 >>> kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xfffffe1247d8e840 >>> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame 0xfffffe1247d8e900 >>> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame 0xfffffe1247d8e940 >>> sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247d8e990 >>> userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247d8ea30 >>> sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247d8eae0 >>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d8ebf0 >>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d8ebf0 >> >> Unfortunately I have no dump as the kmem was too large compared to my >> swap, and I didn't get to the console before some of the text was >> overwritten. Perhaps it will hit it again soon after reboot and I'll get >> a core. > > "NULL mp in getnewvnode()" is only the printf(), it is not a panic or > KASSERT. The event does not stop the machine, nor it prints the > backtrace. > > You mentioned that you was unable to dump, so did the system paniced ? > Without full log of the panic messages and backtrace, it is impossible > to start guessing what the problem is. > > That said, the printf seemingly outlived its usefulness. > Got it. I've set debug.debugger_on_panic=1 to not auto reboot on panic next time this happens. I had it at 0 which was causing the lack of information in these. Off-topic, this system has 72gb of ram, 16gb swap. I suspect ZFS ARC is typically filling up kmem too much to create a dump. I've limited it to 50gb but am not fond of limiting it, or kmem, to under 16gb. I see that if a page is allocated with VM_ALLOC_NODUMP -> PG_NODUMP then it will be excluded from minidumps. It looks like ZFS allocates all of its kmem via malloc(9) (zfs_kmem_alloc) though which has no means to pass these flags down to the vm system. I am guessing ZFS would need dedicated vm pages for this to even make sense though. I suppose I am stuck in this situation unless I limit kmem or raise my swap size. -- Regards, Bryan Drewery From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 09:35:41 2014 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 ESMTPS id 36C79EB3; Wed, 6 Aug 2014 09:35:41 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A4182BB5; Wed, 6 Aug 2014 09:35:40 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so2276402wgh.11 for ; Wed, 06 Aug 2014 02:35:38 -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:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gWo3ajltkaTDuNJP3TXc2SFw6eJVQ88VLk5S/GEOHMs=; b=EXLOaUJL0bV3j+KEwYsFIPcO0QmFXabX7nMTMtbJMrnyXHAIAgBTXu334cMV+xhlsp u4yvPbc3xAzt336SB1oHA9Lw9WJYGakC7ecIwoqDielTjlTVK+48Srh5lT1MNH1w/loL yRQwyzGftQDSUn9HanDblQ5id1oH55TD605jc6PIWwwN1esmcOK/HrLQMBXGy0N+v7Pi OtwO6h8/y09hFUjtWTv9OG6rdyGc1byFVmDAeb6shdIYO1G7E2ZoNPPJaQwPGlybupit A4gDGZzRaFce/rO3P0ZRcmrwfZuEILj5Sj0i+Lo1uIi3RThL2+sadXJvD+kfJC9D+IhH TV2A== X-Received: by 10.180.10.165 with SMTP id j5mr14575041wib.10.1407317738775; Wed, 06 Aug 2014 02:35:38 -0700 (PDT) Received: from [172.16.1.30] (39.Red-2-136-52.dynamicIP.rima-tde.net. [2.136.52.39]) by mx.google.com with ESMTPSA id j6sm1125906wje.29.2014.08.06.02.35.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 02:35:37 -0700 (PDT) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: <53E1F6E3.1040304@FreeBSD.org> Date: Wed, 06 Aug 2014 11:35:31 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nathan Whitehorn , freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: r259580 breaks radeonkms References: <53E178BC.4040201@freebsd.org> In-Reply-To: <53E178BC.4040201@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 09:35:41 -0000 On 06/08/14 02:37, Nathan Whitehorn wrote: > Kernels with r269580 will panic when loading the radeonkms driver in > pmap_page_set_memattr(). This probably indicates a bug in radeonkms, but > the system is unusable in the meantime. > -Nathan I seem to be able to load radeonkms just fine after r269580: # kldload radeonkms info: [drm] Initialized drm 1.1.0 20060810 drmn0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 276 to local APIC 0 vector 48 vgapci0: using IRQ 276 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] RADEON_IS_PCIE info: [drm] initializing kernel modesetting (RV620 0x1002:0x95CF 0x1002:0x2143). info: [drm] register mmio base: 0xF7DF0000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:2:0:0, vendor=1002, device=95cf info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xe0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800e0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x200F info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) info: [drm] ATOM BIOS: 113 drmn0: info: VRAM: 256M 0x0000000000000000 - 0x000000000FFFFFFF (256M used) drmn0: info: GTT: 512M 0x0000000010000000 - 0x000000002FFFFFFF info: [drm] Detected VRAM RAM=256M, BAR=256M info: [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 3129302 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 256M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] probing gen 2 caps for device 8086:340a = 2/0 info: [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 info: [drm] Loading RV620 Microcode firmware: 'radeonkmsfw_RV620_pfp' version 0: 2304 bytes loaded at 0xffffffff8214b0d0 firmware: 'radeonkmsfw_RV620_me' version 0: 21504 bytes loaded at 0xffffffff8214d0d0 firmware: 'radeonkmsfw_R600_rlc' version 0: 3072 bytes loaded at 0xffffffff821530d0 info: [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). drmn0: info: WB enabled drmn0: info: fence driver on ring 0 use gpu addr 0x0000000010000c00 and cpu addr 0x0xfffff80058ab6c00 drmn0: info: fence driver on ring 3 use gpu addr 0x0000000010000c0c and cpu addr 0x0xfffff80058ab6c0c info: [drm] ring test on 0 succeeded in 0 usecs info: [drm] ring test on 3 succeeded in 1 usecs info: [drm] ib test on ring 0 succeeded in 0 usecs info: [drm] ib test on ring 3 succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xe0000000-0xf0000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0x0 iic1: on iicbus1 iicbus2: on iicbb2 addr 0x0 iic2: on iicbus2 iicbus3: on iicbb3 addr 0x0 iic3: on iicbus3 iicbus4: on iicbb4 addr 0x0 iic4: on iicbus4 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] DP-1 info: [drm] HPD2 info: [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c info: [drm] Encoders: info: [drm] DFP1: INTERNAL_UNIPHY info: [drm] Connector 1: info: [drm] DP-2 info: [drm] HPD4 info: [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c info: [drm] Encoders: info: [drm] DFP2: INTERNAL_UNIPHY info: [drm] Internal thermal controller with fan control info: [drm] radeon: power management initialized info: [drm] fb mappable at 0xE0142000 info: [drm] vram apper at 0xE0000000 info: [drm] size 7299072 info: [drm] fb depth is 24 info: [drm] pitch is 6912 fbd0 on drmn0 info: [drm] Initialized radeon 2.29.0 20080528 Although this is a headless server and still using sc. Can you post the output when loading the module? Roger. From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 10:20:15 2014 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 ESMTPS id BF763AD6; Wed, 6 Aug 2014 10:20:15 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4100F21C7; Wed, 6 Aug 2014 10:20:14 +0000 (UTC) Received: from [192.168.10.5] ([62.246.110.10]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MF4eJ-1XCYjc0i6N-00GJVl; Wed, 06 Aug 2014 12:14:55 +0200 Message-ID: <53E20020.3020406@gmx.net> Date: Wed, 06 Aug 2014 12:14:56 +0200 From: Michael Schmiedgen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Nathan Whitehorn , freebsd-current@freebsd.org, royger@freebsd.org, freebsd-x11@freebsd.org Subject: Re: r259580 breaks radeonkms References: <53E178BC.4040201@freebsd.org> In-Reply-To: <53E178BC.4040201@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:NaaK1fjBDBEzRkGtXPYfyUZXqczoG1+9rqK2ZiTwADfOVas1yHf TAMtvXuOIhsILPwhsWsKPOeCHQew0WhtrxjK8WX2wACJPh9FMhK9vKmSGJLC+gIIhLNwses bsvEPhzsJbpvyUOZQsS/oojxOBmddv6wTMsbmg9c/hoDhSRZvsMqvQLSPjGXipgeao3/+sy Su3Oq3YJCQ1MUQEolHQgQ== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 10:20:15 -0000 Something is wrong with Intel hardware too on CURRENT from yesterday. I have not looked deeper into it. Michael From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 14:35:58 2014 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 ESMTPS id A5825B06 for ; Wed, 6 Aug 2014 14:35:58 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C8E2247E for ; Wed, 6 Aug 2014 14:35:58 +0000 (UTC) Received: from webmail.sonic.net (webmail.b.apps.sonic.net [64.142.122.9]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s76EZupT026104 for ; Wed, 6 Aug 2014 07:35:56 -0700 Received: from polaris.tachypleus.net ([75.101.50.44]) by webmail.sonic.net with HTTP (HTTP/1.1 POST); Wed, 06 Aug 2014 07:35:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 06 Aug 2014 07:35:56 -0700 From: Nathan Whitehorn To: freebsd-current@freebsd.org Subject: Re: r259580 breaks radeonkms In-Reply-To: <53E1F6E3.1040304@FreeBSD.org> References: <53E178BC.4040201@freebsd.org> <53E1F6E3.1040304@FreeBSD.org> Message-ID: <5850878054da9ac1898035b6c5d010e5@sonic.net> User-Agent: Roundcube Webmail/0.9.5 X-Sonic-Auth: D2DeU1G24b/ryReBPsjM3CPMQiVpanGrIoNyO6yDMLg7pAaqx+Io/vZ8aRg5Q7rDK8TGftfT5d7L1P1XyI4rVOln+5hEIelxnleXmIKaGBg= X-Sender: (nwhitehorn@sonic.net) X-Sonic-CAuth: UmFuZG9tSVYxxsmid7jYoyrHE5I0EFJKsuNdYp7egPAUL1kq3Zw0WNhvA02vzgoWeG4MFxzEvd1uTUX0BvOqXikglLRTBDGWbivRjpu9juM= X-Sonic-ID: C;VAa++XYd5BGb2E8doK8kYw== M;MEfJ+XYd5BGb2E8doK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: -3.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 14:35:58 -0000 On 2014-08-06 02:35, Roger Pau Monné wrote: > On 06/08/14 02:37, Nathan Whitehorn wrote: >> Kernels with r269580 will panic when loading the radeonkms driver in >> pmap_page_set_memattr(). This probably indicates a bug in radeonkms, >> but >> the system is unusable in the meantime. >> -Nathan > > I seem to be able to load radeonkms just fine after r269580: It's possible that it is related to actually using it, rather than loading the module. I was only testing them together. I'm using vt and the panic (page fault in kernel mode) occurs when TTM tries to set memory attributes on some page while starting X. Before the panic, I see all the normal Radeon module messages as you do, so the module seems to have actually loaded correctly. The KMS console also seems to be functional enough to display the panic message, so I suspect it's X that triggers it. -Nathan > # kldload radeonkms > info: [drm] Initialized drm 1.1.0 20060810 > drmn0: on vgapci0 > vgapci0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 276 to local APIC 0 vector 48 > vgapci0: using IRQ 276 for MSI > info: [drm] MSI enabled 1 message(s) > info: [drm] RADEON_IS_PCIE > info: [drm] initializing kernel modesetting (RV620 0x1002:0x95CF > 0x1002:0x2143). > info: [drm] register mmio base: 0xF7DF0000 > info: [drm] register mmio size: 65536 > info: [drm] radeon_atrm_get_bios: ===> Try ATRM... > info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:2:0:0, > vendor=1002, device=95cf > info: [drm] radeon_atrm_get_bios: Get ACPI device handle > info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... > info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table > info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: > AE_NOT_FOUND > info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... > info: [drm] igp_read_bios_from_vram: VRAM base address: 0xe0000000 > info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800e0000000 > (262144 bytes) > info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x200F > info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... > info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 > bytes) > info: [drm] ATOM BIOS: 113 > drmn0: info: VRAM: 256M 0x0000000000000000 - 0x000000000FFFFFFF (256M > used) > drmn0: info: GTT: 512M 0x0000000010000000 - 0x000000002FFFFFFF > info: [drm] Detected VRAM RAM=256M, BAR=256M > info: [drm] RAM width 64bits DDR > [TTM] Zone kernel: Available graphics memory: 3129302 kiB > [TTM] Zone dma32: Available graphics memory: 2097152 kiB > [TTM] Initializing pool allocator > info: [drm] radeon: 256M of VRAM memory ready > info: [drm] radeon: 512M of GTT memory ready. > info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > info: [drm] Driver supports precise vblank timestamp query. > info: [drm] radeon: irq initialized. > info: [drm] GART: num cpu pages 131072, num gpu pages 131072 > info: [drm] probing gen 2 caps for device 8086:340a = 2/0 > info: [drm] enabling PCIE gen 2 link speeds, disable with > radeon.pcie_gen2=0 > info: [drm] Loading RV620 Microcode > firmware: 'radeonkmsfw_RV620_pfp' version 0: 2304 bytes loaded at > 0xffffffff8214b0d0 > firmware: 'radeonkmsfw_RV620_me' version 0: 21504 bytes loaded at > 0xffffffff8214d0d0 > firmware: 'radeonkmsfw_R600_rlc' version 0: 3072 bytes loaded at > 0xffffffff821530d0 > info: [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). > drmn0: info: WB enabled > drmn0: info: fence driver on ring 0 use gpu addr 0x0000000010000c00 > and cpu addr 0x0xfffff80058ab6c00 > drmn0: info: fence driver on ring 3 use gpu addr 0x0000000010000c0c > and cpu addr 0x0xfffff80058ab6c0c > info: [drm] ring test on 0 succeeded in 0 usecs > info: [drm] ring test on 3 succeeded in 1 usecs > info: [drm] ib test on ring 0 succeeded in 0 usecs > info: [drm] ib test on ring 3 succeeded in 0 usecs > info: [drm] radeon_device_init: Taking over the fictitious range > 0xe0000000-0xf0000000 > iicbus0: on iicbb0 addr 0xff > iic0: on iicbus0 > iicbus1: on iicbb1 addr 0x0 > iic1: on iicbus1 > iicbus2: on iicbb2 addr 0x0 > iic2: on iicbus2 > iicbus3: on iicbb3 addr 0x0 > iic3: on iicbus3 > iicbus4: on iicbb4 addr 0x0 > iic4: on iicbus4 > info: [drm] Radeon Display Connectors > info: [drm] Connector 0: > info: [drm] DP-1 > info: [drm] HPD2 > info: [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c > 0x7e6c > info: [drm] Encoders: > info: [drm] DFP1: INTERNAL_UNIPHY > info: [drm] Connector 1: > info: [drm] DP-2 > info: [drm] HPD4 > info: [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c > 0x7e2c > info: [drm] Encoders: > info: [drm] DFP2: INTERNAL_UNIPHY > info: [drm] Internal thermal controller with fan control > info: [drm] radeon: power management initialized > info: [drm] fb mappable at 0xE0142000 > info: [drm] vram apper at 0xE0000000 > info: [drm] size 7299072 > info: [drm] fb depth is 24 > info: [drm] pitch is 6912 > fbd0 on drmn0 > info: [drm] Initialized radeon 2.29.0 20080528 > > Although this is a headless server and still using sc. Can you post > the output when loading the module? > > Roger. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 16:18:07 2014 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 ESMTPS id AFE737B8 for ; Wed, 6 Aug 2014 16:18:07 +0000 (UTC) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F08921DC for ; Wed, 6 Aug 2014 16:18:07 +0000 (UTC) Received: by mail-oi0-f65.google.com with SMTP id u20so503032oif.0 for ; Wed, 06 Aug 2014 09:18:06 -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=cnoVnO721fBMQeKXIKZr8GqCImcsPESTXisauP9GkD8=; b=0vCWAdCAPxcuvH3aL+u9sc33XP4WFvnTJ71e+kLtfj48VVsVojBjhfvXqNbJObjrrn 9ie3C6ScFYp62/pBHIX4azcf87aGtMNpERzR6KCEVnjQtc3eRIHAMJlwJxfB0VEKpCWf 9gvHwJMCLQuG9ud+0g1SUxVv6+AqRBaSNvb2imr3vx6MlFTIDPYUgQXBe9F185M1z9FS zlIpZYNn0eihaTl6qkOx9QTIJLxGSebL4q5G1mWQgVRvLBo2koooAcRq+P9noFozJXQd 46OLy8OXh1OFBuXThgE/7p5ofKnSobCaEHlpAmt1GiQBs1wbp4rZfjXwPmJRzA5kUovw aQIw== MIME-Version: 1.0 X-Received: by 10.60.51.106 with SMTP id j10mr16427754oeo.77.1407341886775; Wed, 06 Aug 2014 09:18:06 -0700 (PDT) Received: by 10.182.86.105 with HTTP; Wed, 6 Aug 2014 09:18:06 -0700 (PDT) Date: Wed, 6 Aug 2014 17:18:06 +0100 Message-ID: Subject: Xorg failure (segfault after vm_error: pager read error, pid 1562 (Xorg)) on Amd64 From: David Mackay To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 06 Aug 2014 16:31:17 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 16:18:07 -0000 Hello, Today I undertook to update my kernel and world, last built on July the 5th, to the latest -CURRENT sources from svn. Upon starting Xorg, this error emerged: vm_error: pager read error, pid 1562 (Xorg) Segmentation fault at address 0x80081e000 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting I am running on a Lenovo ThinkPad W530 with Intel IvyBridge graphics via KMS. Thanks, David Mackay From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 16:33:38 2014 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 ESMTPS id BB276408 for ; Wed, 6 Aug 2014 16:33:38 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BC1C24C9 for ; Wed, 6 Aug 2014 16:33:38 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id rd3so3721373pab.14 for ; Wed, 06 Aug 2014 09:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tNhrqJlaaCLZsuWRmTTJvRVD+Tcj1S0mHElk9OVTZSs=; b=OKO+n+9bfUdtumtiLSiY4YVqUYPWTWo0VtCHzqE+Q4cBFJxxJZlJXUvPls5NZLbJHI sq9DoI5BAtUaEJaF5SgnYY2FW6cxXw/yY1mYGiM0LLxOBmW2AKHPC/rvKX8NMS3xkiaR yrB0It/7Tvufm0G0psFaxEvkwB/vuIlSG2vz0O0/Asc3ocXEm5GkG8HwniLbyea1/egA dJtpc4oeQOTc2vKxB92OGkym8n+vuHdxBCgPIdIfsYKOn4RwymXYFZiy0458TejIoO1v gw6pSCh5pI/6+ISnVqUsoVtPhPq8qr5w0cMemlWr7mr59L1n9uaJRffYo1DSLukQXNAc SHUA== X-Received: by 10.66.249.71 with SMTP id ys7mr12371740pac.112.1407342818188; Wed, 06 Aug 2014 09:33:38 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:a1b6:3b04:cfef:8b0a? ([2601:8:ab80:7d6:a1b6:3b04:cfef:8b0a]) by mx.google.com with ESMTPSA id do10sm2419668pdb.83.2014.08.06.09.33.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 09:33:37 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FADF722A-372D-45EC-A0CD-A5CB6E350AF6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Xorg failure (segfault after vm_error: pager read error, pid 1562 (Xorg)) on Amd64 From: Garrett Cooper In-Reply-To: Date: Wed, 6 Aug 2014 09:33:36 -0700 Message-Id: References: To: David Mackay X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 16:33:38 -0000 --Apple-Mail=_FADF722A-372D-45EC-A0CD-A5CB6E350AF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 6, 2014, at 9:18 AM, David Mackay wrote: > Hello, >=20 > Today I undertook to update my kernel and world, last built on July > the 5th, to the latest -CURRENT sources from svn. >=20 > Upon starting Xorg, this error emerged: >=20 > vm_error: pager read error, pid 1562 (Xorg) > Segmentation fault at address 0x80081e000 >=20 > Fatal server error: > Caught signal 11 (Segmentation fault). Server aborting >=20 > I am running on a Lenovo ThinkPad W530 with Intel IvyBridge graphics = via KMS. Hi David, Have you read this thread yet: = http://lists.freebsd.org/pipermail/freebsd-current/2014-August/051554.html= ? Cheers! -Garrett --Apple-Mail=_FADF722A-372D-45EC-A0CD-A5CB6E350AF6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT4ljgAAoJEMZr5QU6S73e7BgH/1c/eluTEEnvLqWbI8QopUU9 GFaDXCPSsAWitMBtWaR8/PYmiUtF1LgFJvn54v1xvYWBkvkUWI/5kTYBS1+tyqyK LoNwy73snWSOgUcrhAA/K5DIE9wWw8MXl78lyxXnLq21Bl0Q4D6ZwDQH1GUuG1k3 v62hCQizSj8+D6a37uZY8nscRr+JAOBXa1I80KARpUi1eD7kf64U8b58TMk73LuO ZQnKZx9YY7hE535KrrxRrQaDUpjGEl+Mm6u3lGbggiMYDK4T/I+bjcWb5OVylffx sR9TQRlDsJTqwKDaNOuc5xbc1JkmMvsg0ParAtwjkV0Zi0gK9w9/+6farciXac8= =uMsB -----END PGP SIGNATURE----- --Apple-Mail=_FADF722A-372D-45EC-A0CD-A5CB6E350AF6-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 16:52:19 2014 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 ESMTPS id A68809B9; Wed, 6 Aug 2014 16:52:19 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 160D826C0; Wed, 6 Aug 2014 16:52:18 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id m15so2870844wgh.27 for ; Wed, 06 Aug 2014 09:52:17 -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:subject :references:in-reply-to:content-type; bh=8c+9hpdwy+fwmR54/xRSxNf4XWfIvchBsud5tfl+ZjI=; b=jYLZ6EXu/C+rE6sNstl40XsIizbtOVyqkmg1cJOuG8sV8i++L4RI4gvp8V9vuZ9Cza uMAjppO5+idp+cQhuoJ3tdWyihORGJM13uuVwc+Rhts2fRgSXStu7zad3dlC2iO3hukL N82i9AIF0oke/ACAirleJXUurtQgP5LqH6vrawin2Jys70/IXBLW3gi6zbkTasCXyTQC +Ld1B13phv50yLakMr3aUpjZw6p0R8wwWY4HLGMzc4QAQUHYqTccVpGNV93w6OhiJ/sq YEudkuX6hV/zQIEPsRrIq8RcB+PdKrUUB2gF20gkHzzLBjcymVXWukcDW0PlPHJRpNxX J9ww== X-Received: by 10.180.20.40 with SMTP id k8mr52989332wie.38.1407343937368; Wed, 06 Aug 2014 09:52:17 -0700 (PDT) Received: from [172.16.1.30] (39.Red-2-136-52.dynamicIP.rima-tde.net. [2.136.52.39]) by mx.google.com with ESMTPSA id ub11sm19990704wib.1.2014.08.06.09.52.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 09:52:16 -0700 (PDT) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: <53E25D3E.7000200@FreeBSD.org> Date: Wed, 06 Aug 2014 18:52:14 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: r259580 breaks radeonkms References: <53E178BC.4040201@freebsd.org> <53E1F6E3.1040304@FreeBSD.org> <5850878054da9ac1898035b6c5d010e5@sonic.net> In-Reply-To: <5850878054da9ac1898035b6c5d010e5@sonic.net> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------060302080409010706040505" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 16:52:19 -0000 This is a multi-part message in MIME format. --------------060302080409010706040505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06/08/14 16:35, Nathan Whitehorn wrote: > > > On 2014-08-06 02:35, Roger Pau Monné wrote: >> On 06/08/14 02:37, Nathan Whitehorn wrote: >>> Kernels with r269580 will panic when loading the radeonkms driver in >>> pmap_page_set_memattr(). This probably indicates a bug in radeonkms, but >>> the system is unusable in the meantime. >>> -Nathan >> >> I seem to be able to load radeonkms just fine after r269580: > > It's possible that it is related to actually using it, rather than > loading the module. I was only testing them together. I'm using vt and > the panic (page fault in kernel mode) occurs when TTM tries to set > memory attributes on some page while starting X. Before the panic, I see > all the normal Radeon module messages as you do, so the module seems to > have actually loaded correctly. The KMS console also seems to be > functional enough to display the panic message, so I suspect it's X that > triggers it. > -Nathan Please try the attached patch, it seems to solve the panic for me. It also includes a fix for Intel i915 gem, which I'm not able to test because I don't have the hardware. Roger. --------------060302080409010706040505 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="0001-drm-fix-usage-of-vm_phys_fictitious_to_vm_page.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0001-drm-fix-usage-of-vm_phys_fictitious_to_vm_page.patch" RnJvbSA5ZGQzYTIxZDk5ZmYyZmM3YmYzMjk5MzU5NzUxZDIzOTllZWU5MTJhIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBjaXRy aXguY29tPgpEYXRlOiBXZWQsIDYgQXVnIDIwMTQgMTg6MTY6NTMgKzAyMDAKU3ViamVjdDog W1BBVENIXSBkcm06IGZpeCB1c2FnZSBvZiB2bV9waHlzX2ZpY3RpdGlvdXNfdG9fdm1fcGFn ZQoKdm1fcGh5c19maWN0aXRpb3VzX3RvX3ZtX3BhZ2Ugc2hvdWxkIG5vdCBiZSBjYWxsZWQg ZGlyZWN0bHksIGV2ZW4gd2hlbgpvcGVyYXRpbmcgb24gYSByYW5nZSB0aGF0IGhhcyBiZWVu IHJlZ2lzdGVyZWQgdXNpbmcKdm1fcGh5c19maWN0aXRpb3VzX3JlZ19yYW5nZS4gUEhZU19U T19WTV9QQUdFIHNob3VsZCBiZSB1c2VkIGluc3RlYWQKYmVjYXVzZSBvbiBhcmNoZXMgdGhh dCB1c2UgVk1fUEhZU1NFR19ERU5TRSB0aGUgcGFnZSBtaWdodCBjb21lCmRpcmVjdGx5IGZy b20gdm1fcGFnZV9hcnJheS4KClJlcG9ydGVkIGJ5OiBud2hpdGVob3JuClNwb25zb3JlZCBi eTogQ2l0cml4IFN5c3RlbXMgUiZECi0tLQogc3lzL2Rldi9kcm0yL2k5MTUvaTkxNV9nZW0u YyB8ICAgIDYgKysrKy0tCiBzeXMvZGV2L2RybTIvdHRtL3R0bV9ib192bS5jIHwgICAgOCAr KysrKystLQogMiBmaWxlcyBjaGFuZ2VkLCAxMCBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9u cygtKQoKZGlmZiAtLWdpdCBhL3N5cy9kZXYvZHJtMi9pOTE1L2k5MTVfZ2VtLmMgYi9zeXMv ZGV2L2RybTIvaTkxNS9pOTE1X2dlbS5jCmluZGV4IGEzYWNiNjAuLjZkNDYyMDcgMTAwNjQ0 Ci0tLSBhL3N5cy9kZXYvZHJtMi9pOTE1L2k5MTVfZ2VtLmMKKysrIGIvc3lzL2Rldi9kcm0y L2k5MTUvaTkxNV9nZW0uYwpAQCAtMTQyOCw4ICsxNDI4LDEwIEBAIHJldHJ5OgogCiAJb2Jq LT5mYXVsdF9tYXBwYWJsZSA9IHRydWU7CiAJVk1fT0JKRUNUX1dMT0NLKHZtX29iaik7Ci0J bSA9IHZtX3BoeXNfZmljdGl0aW91c190b192bV9wYWdlKGRldi0+YWdwLT5iYXNlICsgb2Jq LT5ndHRfb2Zmc2V0ICsKLQkgICAgb2Zmc2V0KTsKKwltID0gUEhZU19UT19WTV9QQUdFKGRl di0+YWdwLT5iYXNlICsgb2JqLT5ndHRfb2Zmc2V0ICsgb2Zmc2V0KTsKKwlLQVNTRVJUKCht LT5mbGFncyAmIFBHX0ZJQ1RJVElPVVMpICE9IDAsCisJICAgICgicGh5c2ljYWwgYWRkcmVz cyAlI2p4IG5vdCBmaWN0aXRpb3VzIiwKKwkgICAgKHVpbnRtYXhfdCkoZGV2LT5hZ3AtPmJh c2UgKyBvYmotPmd0dF9vZmZzZXQgKyBvZmZzZXQpKSk7CiAJaWYgKG0gPT0gTlVMTCkgewog CQlWTV9PQkpFQ1RfV1VOTE9DSyh2bV9vYmopOwogCQljYXVzZSA9IDYwOwpkaWZmIC0tZ2l0 IGEvc3lzL2Rldi9kcm0yL3R0bS90dG1fYm9fdm0uYyBiL3N5cy9kZXYvZHJtMi90dG0vdHRt X2JvX3ZtLmMKaW5kZXggODNlYzc2Yy4uN2FhMWFjMCAxMDA2NDQKLS0tIGEvc3lzL2Rldi9k cm0yL3R0bS90dG1fYm9fdm0uYworKysgYi9zeXMvZGV2L2RybTIvdHRtL3R0bV9ib192bS5j CkBAIC0yMTYsOCArMjE2LDEyIEBAIHJlc2VydmU6CiAJfQogCiAJaWYgKGJvLT5tZW0uYnVz LmlzX2lvbWVtKSB7Ci0JCW0gPSB2bV9waHlzX2ZpY3RpdGlvdXNfdG9fdm1fcGFnZShiby0+ bWVtLmJ1cy5iYXNlICsKLQkJICAgIGJvLT5tZW0uYnVzLm9mZnNldCArIG9mZnNldCk7CisJ CW0gPSBQSFlTX1RPX1ZNX1BBR0UoYm8tPm1lbS5idXMuYmFzZSArIGJvLT5tZW0uYnVzLm9m ZnNldCArCisJCSAgICBvZmZzZXQpOworCQlLQVNTRVJUKChtLT5mbGFncyAmIFBHX0ZJQ1RJ VElPVVMpICE9IDAsCisJCSAgICAoInBoeXNpY2FsIGFkZHJlc3MgJSNqeCBub3QgZmljdGl0 aW91cyIsCisJCSAgICAodWludG1heF90KShiby0+bWVtLmJ1cy5iYXNlICsgYm8tPm1lbS5i dXMub2Zmc2V0CisJCSAgICArIG9mZnNldCkpKTsKIAkJcG1hcF9wYWdlX3NldF9tZW1hdHRy KG0sIHR0bV9pb19wcm90KGJvLT5tZW0ucGxhY2VtZW50KSk7CiAJfSBlbHNlIHsKIAkJdHRt ID0gYm8tPnR0bTsKLS0gCjEuNy43LjUgKEFwcGxlIEdpdC0yNikKCg== --------------060302080409010706040505-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 17:21:34 2014 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 ESMTPS id 6DD381E6 for ; Wed, 6 Aug 2014 17:21:34 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1081C2A1B for ; Wed, 6 Aug 2014 17:21:33 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id s76HLRbK002939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Aug 2014 19:21:27 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id s76HLR6x002936 for ; Wed, 6 Aug 2014 19:21:27 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 6 Aug 2014 19:21:27 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: current@freebsd.org Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] In-Reply-To: <8B832384-C1CC-4622-BA67-7447ECE317C9@FreeBSD.org> Message-ID: References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <53E1450D.5090708@protected-networks.net> <53E14CD1.20308@protected-networks.net> <8B832384-C1CC-4622-BA67-7447ECE317C9@FreeBSD.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 17:21:34 -0000 On Tue, 5 Aug 2014 20:49-0700, John Baldwin wrote: > > On Aug 5, 2014, at 2:29 PM, Michael Butler wrote: > > > On 08/05/14 16:56, Michael Butler wrote: > >> On 08/05/14 16:02, John Baldwin wrote: > >> > >>> My guess is that the recent Xen changes tickled something. > >> > >> I can confirm this on a kernel which is otherwise up to date .. > >> > >> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD > >> 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 > >> > >> I backed out all of SVN r269507 through r269515. > >> > >> Now working .. > > > > [ .. snip .. ] > > > >> Now to see if it's related to the other machine's disk woes (it's a > >> single-core device), > > > > And it fixes the inability to probe disks on my single-core machine :-) > > It looks like the MADT code to probe the I/O APICs isn't working so > it's trying to fall back to using the ATPIC while using SMP (which > doesn't work). I know it's a pain on a laptop, but if it is at all > possible to capture either a verbose or non-verbose dmesg that would > really help narrow it down. > > Also, if anyone can try reverting just the MADT-related changes in > the recent Xen changes to see if you can narrow down which exact one > triggers the panic that would be really helpful. I noticed this panic on i386 head r269607 yesterday, running in VBox on Windows 7 SP1 x64, on an Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz (3175.67-MHz 686-class CPU). Go to http://ximalas.info/~trond/atpic_assign_cpu/ where you'll find a verbose dmesg from i386 head r268838 from the same VM and a couple of screenshots of the crash while booting r269607 with the verbose flag on. I'm rewinding /usr/src to r269507, and I'll take it from there, one commit at the time. I'll also try to investigate this panic using my amd64 head VM. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 17:22:32 2014 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 ESMTPS id 7D8DE2F7; Wed, 6 Aug 2014 17:22:32 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4744D2A2D; Wed, 6 Aug 2014 17:22:32 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id hz1so3740579pad.8 for ; Wed, 06 Aug 2014 10:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=57ug++P8eGgoh/VUOJEVzyOw9g3/3vZAc3l2nS2W2TY=; b=qBn/HYMBNtZezEZ39DbepAxoy7etamSE5FS/x5rgp7aOXHy2YJMy2yPXCQHGsnf3yu 2U/3AuCxdvUE1H5sd8Q/uyT2BykYFZl1p3UQKjoNxv5d8tcW4PgyGEwCQn3QRa3tGGrG 8PLybfcjXUlhX/yBGovh9KzSf8mU7n0NM67kEZUu1a0fBgvWZaWQGVtbtH9/yeCbspbb SjuD7fslS1r/mFtJiWPW9/YQys5K1lBu3TjtLlHpr8xb3t/SnnBOrC62ur9ASexKdjqY llmLzn6WFgwcs1O5OXLFR27tgruOnSHd82BFfEahFA6OsgrAmFwKCCWrRAK3CcsCgWIk lNoA== X-Received: by 10.68.104.66 with SMTP id gc2mr12609278pbb.17.1407345751784; Wed, 06 Aug 2014 10:22:31 -0700 (PDT) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id ni5sm2611540pdb.35.2014.08.06.10.22.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 10:22:31 -0700 (PDT) References: <53E178BC.4040201@freebsd.org> <53E1F6E3.1040304@FreeBSD.org> <5850878054da9ac1898035b6c5d010e5@sonic.net> <53E25D3E.7000200@FreeBSD.org> Mime-Version: 1.0 (1.0) In-Reply-To: <53E25D3E.7000200@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: r259580 breaks radeonkms Date: Wed, 6 Aug 2014 10:22:31 -0700 To: =?utf-8?Q?Roger_Pau_Monn=C3=A9?= Cc: David Mackay , "freebsd-current@freebsd.org" , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 17:22:32 -0000 > On Aug 6, 2014, at 9:52, Roger Pau Monn=C3=A9 wrote: >=20 >> On 06/08/14 16:35, Nathan Whitehorn wrote: >>=20 >>=20 >>> On 2014-08-06 02:35, Roger Pau Monn=C3=A9 wrote: >>>> On 06/08/14 02:37, Nathan Whitehorn wrote: >>>> Kernels with r269580 will panic when loading the radeonkms driver in >>>> pmap_page_set_memattr(). This probably indicates a bug in radeonkms, bu= t >>>> the system is unusable in the meantime. >>>> -Nathan >>>=20 >>> I seem to be able to load radeonkms just fine after r269580: >>=20 >> It's possible that it is related to actually using it, rather than >> loading the module. I was only testing them together. I'm using vt and >> the panic (page fault in kernel mode) occurs when TTM tries to set >> memory attributes on some page while starting X. Before the panic, I see >> all the normal Radeon module messages as you do, so the module seems to >> have actually loaded correctly. The KMS console also seems to be >> functional enough to display the panic message, so I suspect it's X that >> triggers it. >> -Nathan >=20 > Please try the attached patch, it seems to solve the panic for me. It > also includes a fix for Intel i915 gem, which I'm not able to test > because I don't have the hardware. >=20 > Roger. >=20 > <0001-drm-fix-usage-of-vm_phys_fictitious_to_vm_page.patch> David McKay confirmed that the patch worked for them on an intel GEM compati= ble chipset. Cheers! -Garrett= From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 17:22:55 2014 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 ESMTPS id 1FF5D3FF; Wed, 6 Aug 2014 17:22:55 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id E8DE82A3C; Wed, 6 Aug 2014 17:22:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id A04CB3805E; Wed, 6 Aug 2014 12:22:48 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id vU2w8fHvky6J; Wed, 6 Aug 2014 12:22:48 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 4CACF3805C; Wed, 6 Aug 2014 12:22:48 -0500 (CDT) Message-ID: <53E26467.8020509@freebsd.org> Date: Wed, 06 Aug 2014 10:22:47 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , freebsd-current@FreeBSD.org Subject: Re: r259580 breaks radeonkms References: <53E178BC.4040201@freebsd.org> <53E1F6E3.1040304@FreeBSD.org> <5850878054da9ac1898035b6c5d010e5@sonic.net> <53E25D3E.7000200@FreeBSD.org> In-Reply-To: <53E25D3E.7000200@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.18 Precedence: 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, 06 Aug 2014 17:22:55 -0000 On 08/06/14 09:52, Roger Pau Monné wrote: > On 06/08/14 16:35, Nathan Whitehorn wrote: >> >> On 2014-08-06 02:35, Roger Pau Monné wrote: >>> On 06/08/14 02:37, Nathan Whitehorn wrote: >>>> Kernels with r269580 will panic when loading the radeonkms driver in >>>> pmap_page_set_memattr(). This probably indicates a bug in radeonkms, but >>>> the system is unusable in the meantime. >>>> -Nathan >>> I seem to be able to load radeonkms just fine after r269580: >> It's possible that it is related to actually using it, rather than >> loading the module. I was only testing them together. I'm using vt and >> the panic (page fault in kernel mode) occurs when TTM tries to set >> memory attributes on some page while starting X. Before the panic, I see >> all the normal Radeon module messages as you do, so the module seems to >> have actually loaded correctly. The KMS console also seems to be >> functional enough to display the panic message, so I suspect it's X that >> triggers it. >> -Nathan > Please try the attached patch, it seems to solve the panic for me. It > also includes a fix for Intel i915 gem, which I'm not able to test > because I don't have the hardware. > > Roger. > Works for me on radeon. Thanks! -Nathan From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 17:38:39 2014 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 ESMTPS id 0C513808; Wed, 6 Aug 2014 17:38:38 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53C672C78; Wed, 6 Aug 2014 17:38:38 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s76HcXd3091754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2014 20:38:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s76HcXd3091754 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s76HcXWX091753; Wed, 6 Aug 2014 20:38:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 6 Aug 2014 20:38:33 +0300 From: Konstantin Belousov To: Roger Pau Monn?? Subject: Re: r259580 breaks radeonkms Message-ID: <20140806173833.GJ93733@kib.kiev.ua> References: <53E178BC.4040201@freebsd.org> <53E1F6E3.1040304@FreeBSD.org> <5850878054da9ac1898035b6c5d010e5@sonic.net> <53E25D3E.7000200@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w3DoQEssjZnO/AC+" Content-Disposition: inline In-Reply-To: <53E25D3E.7000200@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 17:38:39 -0000 --w3DoQEssjZnO/AC+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 06, 2014 at 06:52:14PM +0200, Roger Pau Monn?? wrote: > On 06/08/14 16:35, Nathan Whitehorn wrote: > >=20 > >=20 > > On 2014-08-06 02:35, Roger Pau Monn?? wrote: > >> On 06/08/14 02:37, Nathan Whitehorn wrote: > >>> Kernels with r269580 will panic when loading the radeonkms driver in > >>> pmap_page_set_memattr(). This probably indicates a bug in radeonkms, = but > >>> the system is unusable in the meantime. > >>> -Nathan > >> > >> I seem to be able to load radeonkms just fine after r269580: > >=20 > > It's possible that it is related to actually using it, rather than > > loading the module. I was only testing them together. I'm using vt and > > the panic (page fault in kernel mode) occurs when TTM tries to set > > memory attributes on some page while starting X. Before the panic, I see > > all the normal Radeon module messages as you do, so the module seems to > > have actually loaded correctly. The KMS console also seems to be > > functional enough to display the panic message, so I suspect it's X that > > triggers it. > > -Nathan >=20 > Please try the attached patch, it seems to solve the panic for me. It > also includes a fix for Intel i915 gem, which I'm not able to test > because I don't have the hardware. >=20 > Roger. >=20 > From 9dd3a21d99ff2fc7bf3299359751d2399eee912a Mon Sep 17 00:00:00 2001 > From: Roger Pau Monne > Date: Wed, 6 Aug 2014 18:16:53 +0200 > Subject: [PATCH] drm: fix usage of vm_phys_fictitious_to_vm_page >=20 > vm_phys_fictitious_to_vm_page should not be called directly, even when > operating on a range that has been registered using > vm_phys_fictitious_reg_range. PHYS_TO_VM_PAGE should be used instead > because on arches that use VM_PHYSSEG_DENSE the page might come > directly from vm_page_array. >=20 > Reported by: nwhitehorn > Sponsored by: Citrix Systems R&D > --- > sys/dev/drm2/i915/i915_gem.c | 6 ++++-- > sys/dev/drm2/ttm/ttm_bo_vm.c | 8 ++++++-- > 2 files changed, 10 insertions(+), 4 deletions(-) >=20 > diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.c > index a3acb60..6d46207 100644 > --- a/sys/dev/drm2/i915/i915_gem.c > +++ b/sys/dev/drm2/i915/i915_gem.c > @@ -1428,8 +1428,10 @@ retry: > =20 > obj->fault_mappable =3D true; > VM_OBJECT_WLOCK(vm_obj); > - m =3D vm_phys_fictitious_to_vm_page(dev->agp->base + obj->gtt_offset + > - offset); > + m =3D PHYS_TO_VM_PAGE(dev->agp->base + obj->gtt_offset + offset); > + KASSERT((m->flags & PG_FICTITIOUS) !=3D 0, > + ("physical address %#jx not fictitious", > + (uintmax_t)(dev->agp->base + obj->gtt_offset + offset))); > if (m =3D=3D NULL) { > VM_OBJECT_WUNLOCK(vm_obj); > cause =3D 60; > diff --git a/sys/dev/drm2/ttm/ttm_bo_vm.c b/sys/dev/drm2/ttm/ttm_bo_vm.c > index 83ec76c..7aa1ac0 100644 > --- a/sys/dev/drm2/ttm/ttm_bo_vm.c > +++ b/sys/dev/drm2/ttm/ttm_bo_vm.c > @@ -216,8 +216,12 @@ reserve: > } > =20 > if (bo->mem.bus.is_iomem) { > - m =3D vm_phys_fictitious_to_vm_page(bo->mem.bus.base + > - bo->mem.bus.offset + offset); > + m =3D PHYS_TO_VM_PAGE(bo->mem.bus.base + bo->mem.bus.offset + > + offset); > + KASSERT((m->flags & PG_FICTITIOUS) !=3D 0, > + ("physical address %#jx not fictitious", > + (uintmax_t)(bo->mem.bus.base + bo->mem.bus.offset > + + offset))); > pmap_page_set_memattr(m, ttm_io_prot(bo->mem.placement)); > } else { > ttm =3D bo->ttm; This should be fine. In fact I considered doing similar change some time ago, but for some reasons decided not to. Still, it is not clear why does it break with your changes, in particular, the PCI hole where the aperture is mapped should be covered by vm_page_array. --w3DoQEssjZnO/AC+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT4mgYAAoJEJDCuSvBvK1BmWUP/jMkMT8iHQ63WrK3aYiRpN7w jjmTreBmUwlUJSxJJ9cFjwBqC/OXjLbmgoKtZx2Ru3gvUZ1Wm5x2OLAwU3Dhx7A1 aftGlUsQoStRR2FUOsUQPWTRCwp9mMCzTgieuQwX6P7j8JbJbZouAaqzKVTCTbXk zQ+zStJ0F6dA++EOhCjD+GLNlLClJP+DCYHcvm1CKpDpiXsGI67jgGi5sE/4jsmv eOMRkRlOVopQGFq9d9z7RMmCjWzIxsvrYI/bm0QgPGyVrFzyZoIeOsO89S4FbKd+ 3x3aw49pOJcrML8Y48fxirXg0e0SUFhbifLb8H+j/QA5C9xrGKXI23vGc1Nz+LhN buocbDy5HPxyyTGLEce3NljupdXRcxN2zIpB7UoWjb7J5BKSYZuIhzER5SCTMKoO ShQ4iwBCDM0YVIPLgvvcYlcy7r+3mu5gypwHu74mD5Ow3GeSuxZIDD1FGtz78gol xHgYZS88HsCsbRZt4VEbYFIA1V75ahot51TVO1HmfqmAkjR1xoPoKwXXe+fPAokz NOGJ4d3qdWu/SAG/FMks+Aav9qozo8QIIpg3yYVYKIW6ovqfkNdwpBHqGU46iFDL /DJ/qlF1do0MwYAo8hjMOH19fGfyZrQ9+3llbhXS3Pydews06H9XXOW7RvBcbJSl CD60H7wxCvijGPj51cTC =RXaN -----END PGP SIGNATURE----- --w3DoQEssjZnO/AC+-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 17:44:59 2014 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 ESMTPS id 312B0AE1; Wed, 6 Aug 2014 17:44:59 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94A8B2D3E; Wed, 6 Aug 2014 17:44:58 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id b13so3022982wgh.30 for ; Wed, 06 Aug 2014 10:44:56 -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=o35s5hPhAcygRdB2GSS6x2wYMQHE/PkoMNenkbA/9u8=; b=WT0AXk860L3jrpV0JZjbH7bo6Zw2aF9sQ6MgK7p55zxU2Cd2x0btafngQjPr2ru5Ws iom4pwPa7nWYmfVlosXbL4qma1N4Slywf8QHx41PF9J4mpgd3jDMT1AKF+iXDVymR5P7 GKvmZsUWAhrq9B+N9ae2Swt5+4JXXRuBRtHdbYWKyW7UF7ylLm0sNmOKIDhXC2QFl5MH wHkU/qGNaLkMeUTx9XCxurWqK1uOjrkTgTGwrTyOEfVC2K16Iw6GzO1Kd97P8z6z7lpr uPd5SzLSwE45X5S+uiTc4Vi+gTAIufh9TJLd8TZXeESfEnae2Wgvh649Oai8HqWYSFuL 3Fcg== X-Received: by 10.180.39.139 with SMTP id p11mr11883848wik.50.1407347096776; Wed, 06 Aug 2014 10:44:56 -0700 (PDT) Received: from [172.16.1.30] (39.Red-2-136-52.dynamicIP.rima-tde.net. [2.136.52.39]) by mx.google.com with ESMTPSA id f3sm8227434wiz.0.2014.08.06.10.44.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 10:44:55 -0700 (PDT) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: <53E26996.20503@FreeBSD.org> Date: Wed, 06 Aug 2014 19:44:54 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: r259580 breaks radeonkms References: <53E178BC.4040201@freebsd.org> <53E1F6E3.1040304@FreeBSD.org> <5850878054da9ac1898035b6c5d010e5@sonic.net> <53E25D3E.7000200@FreeBSD.org> <20140806173833.GJ93733@kib.kiev.ua> In-Reply-To: <20140806173833.GJ93733@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 17:44:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/08/14 19:38, Konstantin Belousov wrote: > On Wed, Aug 06, 2014 at 06:52:14PM +0200, Roger Pau Monn?? wrote: >> On 06/08/14 16:35, Nathan Whitehorn wrote: >>> >>> >>> On 2014-08-06 02:35, Roger Pau Monn?? wrote: >>>> On 06/08/14 02:37, Nathan Whitehorn wrote: >>>>> Kernels with r269580 will panic when loading the radeonkms >>>>> driver in pmap_page_set_memattr(). This probably indicates >>>>> a bug in radeonkms, but the system is unusable in the >>>>> meantime. -Nathan >>>> >>>> I seem to be able to load radeonkms just fine after r269580: >>> >>> It's possible that it is related to actually using it, rather >>> than loading the module. I was only testing them together. I'm >>> using vt and the panic (page fault in kernel mode) occurs when >>> TTM tries to set memory attributes on some page while starting >>> X. Before the panic, I see all the normal Radeon module >>> messages as you do, so the module seems to have actually loaded >>> correctly. The KMS console also seems to be functional enough >>> to display the panic message, so I suspect it's X that triggers >>> it. -Nathan >> >> Please try the attached patch, it seems to solve the panic for >> me. It also includes a fix for Intel i915 gem, which I'm not able >> to test because I don't have the hardware. >> >> Roger. >> > >> From 9dd3a21d99ff2fc7bf3299359751d2399eee912a Mon Sep 17 00:00:00 >> 2001 From: Roger Pau Monne Date: Wed, 6 >> Aug 2014 18:16:53 +0200 Subject: [PATCH] drm: fix usage of >> vm_phys_fictitious_to_vm_page >> >> vm_phys_fictitious_to_vm_page should not be called directly, even >> when operating on a range that has been registered using >> vm_phys_fictitious_reg_range. PHYS_TO_VM_PAGE should be used >> instead because on arches that use VM_PHYSSEG_DENSE the page >> might come directly from vm_page_array. >> >> Reported by: nwhitehorn Sponsored by: Citrix Systems R&D --- >> sys/dev/drm2/i915/i915_gem.c | 6 ++++-- >> sys/dev/drm2/ttm/ttm_bo_vm.c | 8 ++++++-- 2 files changed, 10 >> insertions(+), 4 deletions(-) >> >> diff --git a/sys/dev/drm2/i915/i915_gem.c >> b/sys/dev/drm2/i915/i915_gem.c index a3acb60..6d46207 100644 --- >> a/sys/dev/drm2/i915/i915_gem.c +++ >> b/sys/dev/drm2/i915/i915_gem.c @@ -1428,8 +1428,10 @@ retry: >> >> obj->fault_mappable = true; VM_OBJECT_WLOCK(vm_obj); - m = >> vm_phys_fictitious_to_vm_page(dev->agp->base + obj->gtt_offset + >> - offset); + m = PHYS_TO_VM_PAGE(dev->agp->base + >> obj->gtt_offset + offset); + KASSERT((m->flags & PG_FICTITIOUS) >> != 0, + ("physical address %#jx not fictitious", + >> (uintmax_t)(dev->agp->base + obj->gtt_offset + offset))); if (m >> == NULL) { VM_OBJECT_WUNLOCK(vm_obj); cause = 60; diff --git >> a/sys/dev/drm2/ttm/ttm_bo_vm.c b/sys/dev/drm2/ttm/ttm_bo_vm.c >> index 83ec76c..7aa1ac0 100644 --- a/sys/dev/drm2/ttm/ttm_bo_vm.c >> +++ b/sys/dev/drm2/ttm/ttm_bo_vm.c @@ -216,8 +216,12 @@ reserve: >> } >> >> if (bo->mem.bus.is_iomem) { - m = >> vm_phys_fictitious_to_vm_page(bo->mem.bus.base + - >> bo->mem.bus.offset + offset); + m = >> PHYS_TO_VM_PAGE(bo->mem.bus.base + bo->mem.bus.offset + + >> offset); + KASSERT((m->flags & PG_FICTITIOUS) != 0, + >> ("physical address %#jx not fictitious", + >> (uintmax_t)(bo->mem.bus.base + bo->mem.bus.offset + + >> offset))); pmap_page_set_memattr(m, >> ttm_io_prot(bo->mem.placement)); } else { ttm = bo->ttm; > > This should be fine. In fact I considered doing similar change > some time ago, but for some reasons decided not to. Still, it is > not clear why does it break with your changes, in particular, the > PCI hole where the aperture is mapped should be covered by > vm_page_array. This is because I've changed the logic in vm_phys_fictitious_reg_range, so that if a region is covered by vm_page_array it is no longer added to the red-black tree that tracks fictitious ranges, and thus vm_phys_fictitious_to_vm_page returns NULL in those cases. Roger. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iQEcBAEBAgAGBQJT4mmWAAoJEKXZdqUyumTAEpIH/1c/BgcC0MvlTPTq4yamnGTD FdoaNABSfh6VRRfAlQjzyTKldVLpXfcZnTpVaHiTNZgT2TRDzFoI3Brawhr33grg 1MDpYS+EusxadkTBYrsV8rQ4+t1K6jCPxgOJPVnB+85ud2Uu6SWJgilfZTW2Raq4 AKlItP2BrKtH0+Fbrtg7rBsz/Knx7kExC7bPHyBBDDuakfZJFhfIn/To1iJgw5Ug Nmtje8IhEChtZFG9Q3S1IT8Azb8FlnImXaBdwk2bBhjMaeP0jKQFV7a6lpG+4Jjs 3/PeJtgsQpCry7oIZNZ8sCptQSRAx4lSKjgpqoTchowSv1Fj41a0s7IsJ4ALiQ8= =DbvG -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 17:48:42 2014 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 ESMTPS id 41E46D84 for ; Wed, 6 Aug 2014 17:48:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 207012D79 for ; Wed, 6 Aug 2014 17:48:42 +0000 (UTC) Received: from bdrewery (uid 1298) (envelope-from bdrewery@freebsd.org) id dbc by freefall.freebsd.org (DragonFly Mail Agent v0.9+); Wed, 06 Aug 2014 17:48:42 +0000 Received: (qmail 10446 invoked from network); 6 Aug 2014 12:48:37 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 6 Aug 2014 12:48:37 -0500 Message-ID: <53E26A6C.4000806@FreeBSD.org> Date: Wed, 06 Aug 2014 12:48:28 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: current@FreeBSD.org Subject: Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() References: <53E1975D.4010703@FreeBSD.org> <20140806031932.GE93733@kib.kiev.ua> <53E1A76A.1070400@FreeBSD.org> In-Reply-To: <53E1A76A.1070400@FreeBSD.org> X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fDhGJu4KXLr2HuWFh5ALcNiTwtAso7Dc3" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 17:48:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fDhGJu4KXLr2HuWFh5ALcNiTwtAso7Dc3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/5/2014 10:56 PM, Bryan Drewery wrote: > On 8/5/2014 10:19 PM, Konstantin Belousov wrote: >> On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: >>> Has anyone else encountered this? Got it while running poudriere. >>> >>>> NULL mp in getnewvnode() >>>> [...] >>>> vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247d8e540 >>>> vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247d8e590 >>>> export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247d8e7c0 >>>> kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame >>>> 0xfffffe1247d8e840 >>>> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame >>>> 0xfffffe1247d8e900 >>>> sysctl_root_handler_locked() at >>>> sysctl_root_handler_locked+0x68/frame 0xfffffe1247d8e940 >>>> sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247d8e990 >>>> userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247d8ea30 >>>> sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247d8eae0 >>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d8ebf0 >>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d8ebf0 >>> >>> Unfortunately I have no dump as the kmem was too large compared to my= >>> swap, and I didn't get to the console before some of the text was >>> overwritten. Perhaps it will hit it again soon after reboot and I'll = get >>> a core. >> >> "NULL mp in getnewvnode()" is only the printf(), it is not a panic or >> KASSERT. The event does not stop the machine, nor it prints the >> backtrace. >> >> You mentioned that you was unable to dump, so did the system paniced ?= >> Without full log of the panic messages and backtrace, it is impossible= >> to start guessing what the problem is. >> >> That said, the printf seemingly outlived its usefulness. >> >=20 > Got it. I've set debug.debugger_on_panic=3D1 to not auto reboot on pani= c > next time this happens. I had it at 0 which was causing the lack of > information in these. Here is the full trace: > NULL mp in getnewvnode() > VNASSERT failed > 0xfffff806071dc760: tag null, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type zfs: EXCL by thread 0xfffff8009a53f490 (pid 1028, tmux, t= id 100881) > vp=3D0xfffff806071dc760, lowervp=3D0xfffff8013157f588 > panic: Don't call insmntque(foo, NULL) > cpuid =3D 5 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe124= 7e76b50 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247e76c00 > vpanic() at vpanic+0x126/frame 0xfffffe1247e76c40 > kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247e76cb0 > insmntque1() at insmntque1+0x230/frame 0xfffffe1247e76cf0 > null_nodeget() at null_nodeget+0x158/frame 0xfffffe1247e76d60 > null_lookup() at null_lookup+0xeb/frame 0xfffffe1247e76dd0 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfffffe1247e76e00 > lookup() at lookup+0x5ad/frame 0xfffffe1247e76e90 > namei() at namei+0x4e4/frame 0xfffffe1247e76f50 > vn_open_cred() at vn_open_cred+0x27a/frame 0xfffffe1247e770a0 > vop_stdvptocnp() at vop_stdvptocnp+0x161/frame 0xfffffe1247e773e0 > null_vptocnp() at null_vptocnp+0x2b/frame 0xfffffe1247e77440 > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf7/frame 0xfffffe1247e77470 > vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfffffe1247e774e0= > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247e77540 > vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247e77590 > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247e777c0 > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xfffffe= 1247e77840 > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame 0xf= ffffe1247e77900 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame 0= xfffffe1247e77940 > sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247e77990 > userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247e77a30 > sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247e77ae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247e77bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247e77bf0 > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip =3D 0x801041fca, rs= p =3D 0x7fffffffd878, rbp =3D 0x7fffffffd8b0 --- > KDB: enter: panic > [ thread pid 1028 tid 100881 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> call doadump() >=20 > Dump failed. Partition too small. > =3D 0 --=20 Regards, Bryan Drewery --fDhGJu4KXLr2HuWFh5ALcNiTwtAso7Dc3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT4mpsAAoJEDXXcbtuRpfPgAcH/2Qb0KJw9fvh2Ndi0xO1MUqo tkg5Rs2bZyC8iWEkMneSV5aIsvbHG6aOtPJrZD3e60FhK5vIcYiqN+Etk3/kV7Q2 bpgnwYYTNbS6a5ECkDquzRC8+GmCxRrfOXgwacYC7TlViOMXR+Y7iEnIG+ib6gzf ZlVOWPSC9/vXfVIRtWRXWw3ZOTdIWCKm2usHF/1sttSnXQ5cn+ba4WzSg0tQWDYR +hzWU0m8fs+GKu7a+ZBDZCNogITsSrzTkvLeislSykoYBcpmr/MVjbM4IZgxm+3S 7gdceQNR74OkJIrBu67xIXkzJKbj0J2KG1OCfu8GRMc29ByOGeRk+mVo4h/TZnE= =2iRA -----END PGP SIGNATURE----- --fDhGJu4KXLr2HuWFh5ALcNiTwtAso7Dc3-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 18:15:23 2014 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 ESMTPS id 20724447; Wed, 6 Aug 2014 18:15:23 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6CB22162; Wed, 6 Aug 2014 18:15:22 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s76IFD8b099801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2014 21:15:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s76IFD8b099801 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s76IFDMi099800; Wed, 6 Aug 2014 21:15:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 6 Aug 2014 21:15:12 +0300 From: Konstantin Belousov To: Bryan Drewery Subject: Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() Message-ID: <20140806181512.GK93733@kib.kiev.ua> References: <53E1975D.4010703@FreeBSD.org> <20140806031932.GE93733@kib.kiev.ua> <53E1A76A.1070400@FreeBSD.org> <53E26A6C.4000806@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhgEPFSZK1ORRBO1" Content-Disposition: inline In-Reply-To: <53E26A6C.4000806@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 18:15:23 -0000 --AhgEPFSZK1ORRBO1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 06, 2014 at 12:48:28PM -0500, Bryan Drewery wrote: > On 8/5/2014 10:56 PM, Bryan Drewery wrote: > > On 8/5/2014 10:19 PM, Konstantin Belousov wrote: > >> On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: > >>> Has anyone else encountered this? Got it while running poudriere. > >>> > >>>> NULL mp in getnewvnode() > >>>> [...] > >>>> vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247d8e540 > >>>> vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247d8e590 > >>>> export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247d8e7c0 > >>>> kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > >>>> 0xfffffe1247d8e840 > >>>> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame > >>>> 0xfffffe1247d8e900 > >>>> sysctl_root_handler_locked() at > >>>> sysctl_root_handler_locked+0x68/frame 0xfffffe1247d8e940 > >>>> sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247d8e990 > >>>> userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247d8ea30 > >>>> sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247d8eae0 > >>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d8ebf0 > >>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d8ebf0 > >>> > >>> Unfortunately I have no dump as the kmem was too large compared to my > >>> swap, and I didn't get to the console before some of the text was > >>> overwritten. Perhaps it will hit it again soon after reboot and I'll = get > >>> a core. > >> > >> "NULL mp in getnewvnode()" is only the printf(), it is not a panic or > >> KASSERT. The event does not stop the machine, nor it prints the > >> backtrace. > >> > >> You mentioned that you was unable to dump, so did the system paniced ? > >> Without full log of the panic messages and backtrace, it is impossible > >> to start guessing what the problem is. > >> > >> That said, the printf seemingly outlived its usefulness. > >> > >=20 > > Got it. I've set debug.debugger_on_panic=3D1 to not auto reboot on panic > > next time this happens. I had it at 0 which was causing the lack of > > information in these. >=20 > Here is the full trace: >=20 >=20 > > NULL mp in getnewvnode() > > VNASSERT failed > > 0xfffff806071dc760: tag null, type VDIR > > usecount 1, writecount 0, refcount 1 mountedhere 0 > > flags () > > lock type zfs: EXCL by thread 0xfffff8009a53f490 (pid 1028, tmux, t= id 100881) > > vp=3D0xfffff806071dc760, lowervp=3D0xfffff8013157f588 > > panic: Don't call insmntque(foo, NULL) > > cpuid =3D 5 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe124= 7e76b50 > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247e76c00 > > vpanic() at vpanic+0x126/frame 0xfffffe1247e76c40 > > kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247e76cb0 > > insmntque1() at insmntque1+0x230/frame 0xfffffe1247e76cf0 > > null_nodeget() at null_nodeget+0x158/frame 0xfffffe1247e76d60 > > null_lookup() at null_lookup+0xeb/frame 0xfffffe1247e76dd0 > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfffffe1247e76e00 > > lookup() at lookup+0x5ad/frame 0xfffffe1247e76e90 > > namei() at namei+0x4e4/frame 0xfffffe1247e76f50 > > vn_open_cred() at vn_open_cred+0x27a/frame 0xfffffe1247e770a0 > > vop_stdvptocnp() at vop_stdvptocnp+0x161/frame 0xfffffe1247e773e0 > > null_vptocnp() at null_vptocnp+0x2b/frame 0xfffffe1247e77440 > > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf7/frame 0xfffffe1247e77470 > > vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfffffe1247e774e0 > > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247e77540 > > vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247e77590 > > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247e777c0 > > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xfffffe= 1247e77840 > > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame 0xf= ffffe1247e77900 > > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame 0= xfffffe1247e77940 > > sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247e77990 > > userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247e77a30 > > sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247e77ae0 > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247e77bf0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247e77bf0 > > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip =3D 0x801041fca, rs= p =3D 0x7fffffffd878, rbp =3D 0x7fffffffd8b0 --- > > KDB: enter: panic > > [ thread pid 1028 tid 100881 ] > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > db> call doadump() > >=20 > > Dump failed. Partition too small. > > =3D 0 >=20 Try this. diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c index 481644c..e803c24 100644 --- a/sys/fs/nullfs/null_vnops.c +++ b/sys/fs/nullfs/null_vnops.c @@ -361,9 +361,11 @@ null_lookup(struct vop_lookup_args *ap) struct vnode *dvp =3D ap->a_dvp; int flags =3D cnp->cn_flags; struct vnode *vp, *ldvp, *lvp; + struct mount *mp; int error; =20 - if ((flags & ISLASTCN) && (dvp->v_mount->mnt_flag & MNT_RDONLY) && + mp =3D dvp->v_mount; + if ((flags & ISLASTCN) !=3D 0 && (mp->mnt_flag & MNT_RDONLY) !=3D 0 && (cnp->cn_nameiop =3D=3D DELETE || cnp->cn_nameiop =3D=3D RENAME)) return (EROFS); /* @@ -377,18 +379,27 @@ null_lookup(struct vop_lookup_args *ap) ("ldvp %p fl %#x dvp %p fl %#x flags %#x", ldvp, ldvp->v_vflag, dvp, dvp->v_vflag, flags)); error =3D VOP_LOOKUP(ldvp, &lvp, cnp); - if (error =3D=3D EJUSTRETURN && (flags & ISLASTCN) && - (dvp->v_mount->mnt_flag & MNT_RDONLY) && + if (error =3D=3D EJUSTRETURN && (flags & ISLASTCN) !=3D 0 && + (mp->mnt_flag & MNT_RDONLY) !=3D 0 && (cnp->cn_nameiop =3D=3D CREATE || cnp->cn_nameiop =3D=3D RENAME)) error =3D EROFS; =20 + /* + * VOP_LOOKUP() on lower vnode may unlock ldvp, which allows + * dvp to be reclaimed due to shared v_vnlock. Check for the + * doomed state and return error. + */ + if ((error =3D=3D 0 || error =3D=3D EJUSTRETURN) && + (dvp->v_iflag & VI_DOOMED) !=3D 0) + error =3D ENOENT; + if ((error =3D=3D 0 || error =3D=3D EJUSTRETURN) && lvp !=3D NULL) { if (ldvp =3D=3D lvp) { *ap->a_vpp =3D dvp; VREF(dvp); vrele(lvp); } else { - error =3D null_nodeget(dvp->v_mount, lvp, &vp); + error =3D null_nodeget(mp, lvp, &vp); if (error =3D=3D 0) *ap->a_vpp =3D vp; } --AhgEPFSZK1ORRBO1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT4nCwAAoJEJDCuSvBvK1B9GAP/38QJI4t+mLgIe9ygMUNjSNx WvP+VHTk/7lfSf3jRQmuIYSOn7Ru8aMhIvtkXYZTQsejREiIm3CSyIEPcz2O0+jS gcMD1ic1jLPZQwSQC/OOZFnkJgYwprL/8iRLuBhogmHopvS61LV5c+unGTj1q+LU 6Gc8QQNexFpyxhDj8EZAbXQm4FWaPYmlFJUQo3PwCaSOsYOH537/VudnjilNuxL0 HRrm8TRaA+G4oFk8SRY5N5qNNkHpC/pYwnn1I4HmeRkJ5oxr4L+CszGsR3NDSTgV w2538/xokkDJ8TUEfFr/jjbwdP25oHZaIyEDhM3rjQmX/jVf6qByqbpJDxCZOfTO LOhDe5yhm0TeAetnZwM0/+awN7XxzN6Owrl3Wn+jyrnm2IcKYGo0gAFOpp6Rnv9a Lrdqi7wzaTJ4gcgI77MW1enB19UiufZf37YJ4e/ZK3CR93BmIgSJG2qcXqE2PuxM 576zyjYiSMtIOejIKJxnYYBw6e3OVsHwkw7USKmJvmC0VKTNx7Bhqe4gFigTaMqr DkdgceEN2YvEYhmavmF0WoJ8F6V83yq7Znvb41yCoHzs/agaYYS6La2+++X0BGO9 PpIfZ/Z2uODnzs0JLx32OLOXIWVwJzqJGZPjtAAbVlVMfYQTFiOtNdbPf1wy2bTZ 03vSWVFrd7B49Z8Y/Wl5 =HiHa -----END PGP SIGNATURE----- --AhgEPFSZK1ORRBO1-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 20:48:40 2014 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 ESMTPS id 82EAAC8F for ; Wed, 6 Aug 2014 20:48:40 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 26819249E for ; Wed, 6 Aug 2014 20:48:39 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id s76KmXmg004365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Aug 2014 22:48:33 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id s76KmWwT004362 for ; Wed, 6 Aug 2014 22:48:33 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 6 Aug 2014 22:48:32 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: current@freebsd.org Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] In-Reply-To: Message-ID: References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <53E1450D.5090708@protected-networks.net> <53E14CD1.20308@protected-networks.net> <8B832384-C1CC-4622-BA67-7447ECE317C9@FreeBSD.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 20:48:40 -0000 On Wed, 6 Aug 2014 19:21+0200, Trond Endrestl wrote: > On Tue, 5 Aug 2014 20:49-0700, John Baldwin wrote: > > > > > On Aug 5, 2014, at 2:29 PM, Michael Butler wrote: > > > > > On 08/05/14 16:56, Michael Butler wrote: > > >> On 08/05/14 16:02, John Baldwin wrote: > > >> > > >>> My guess is that the recent Xen changes tickled something. > > >> > > >> I can confirm this on a kernel which is otherwise up to date .. > > >> > > >> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD > > >> 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 > > >> > > >> I backed out all of SVN r269507 through r269515. > > >> > > >> Now working .. > > > > > > [ .. snip .. ] > > > > > >> Now to see if it's related to the other machine's disk woes (it's a > > >> single-core device), > > > > > > And it fixes the inability to probe disks on my single-core machine :-) > > > > It looks like the MADT code to probe the I/O APICs isn't working so > > it's trying to fall back to using the ATPIC while using SMP (which > > doesn't work). I know it's a pain on a laptop, but if it is at all > > possible to capture either a verbose or non-verbose dmesg that would > > really help narrow it down. > > > > Also, if anyone can try reverting just the MADT-related changes in > > the recent Xen changes to see if you can narrow down which exact one > > triggers the panic that would be really helpful. > > I noticed this panic on i386 head r269607 yesterday, running in VBox > on Windows 7 SP1 x64, on an Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz > (3175.67-MHz 686-class CPU). > > Go to http://ximalas.info/~trond/atpic_assign_cpu/ where you'll find a > verbose dmesg from i386 head r268838 from the same VM and a couple of > screenshots of the crash while booting r269607 with the verbose flag > on. > > I'm rewinding /usr/src to r269507, and I'll take it from there, one > commit at the time. Reverting r269510 did the trick, i.e.: cd /usr/src && svn up && svn diff -r 269510:269509 | patch My i386 head VM is running smoothly with r269641M, with M meaning only the above reversal. > I'll also try to investigate this panic using my amd64 head VM. Work in progress. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 21:09:21 2014 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 ESMTPS id 9F5E23D9 for ; Wed, 6 Aug 2014 21:09:21 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 85B5C2720 for ; Wed, 6 Aug 2014 21:09:20 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s76L808C026366; Wed, 6 Aug 2014 14:08:00 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s76L7xs1026365; Wed, 6 Aug 2014 14:07:59 -0700 (PDT) (envelope-from david) Date: Wed, 6 Aug 2014 14:07:59 -0700 From: David Wolfskill To: Trond =?iso-8859-1?Q?Endrest=F8l?= Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] Message-ID: <20140806210759.GM1228@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Trond =?iso-8859-1?Q?Endrest=F8l?= , current@freebsd.org References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <53E1450D.5090708@protected-networks.net> <53E14CD1.20308@protected-networks.net> <8B832384-C1CC-4622-BA67-7447ECE317C9@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Z9TvlI/Spa97+Fm/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 21:09:21 -0000 --Z9TvlI/Spa97+Fm/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrest=F8l wrote: > ... > Reverting r269510 did the trick, i.e.: >=20 > cd /usr/src && svn up && svn diff -r 269510:269509 | patch >=20 > My i386 head VM is running smoothly with r269641M, with M meaning only=20 > the above reversal. > ... Works for me, as well -- thanks! FreeBSD 11.0-CURRENT #1333 r269622M/269622:1100028: Wed Aug 6 14:01:30 PD= T 2014 (I'll be providing more details to royger@ et al. in a moment.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Z9TvlI/Spa97+Fm/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT4pkuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7tMQQAIhfxD3u/JnAjUN2siHjmuov 3T/i284fRJMS+/sKdYmxeDKe5HV8onXIHiUqN8NfUuvoQGv+ujixasReX4wuUW1W u1GD4ztalaskZUyqBh3Enccb5PmwEfa4+/qeI4kv3V79e2RPle7GQvsgj3OlNknf sPYXFMe3qFJq2E+FF4gkVXtQypVVymhVTXo/Xo8dDKJ7GhYgTKcZMDb5FWtvlcbI 40+Bna6wbAFspwOz++Iy+O10AgHF0G+YITehCv1xwOnWpOnes0mF7HMPz/M2nfR9 DE2var5rhaetDT/YqCqhAyv6tYcjah5fE/dff5yaoTETwcFIeR0zvsYcRpS0GTG1 tL4QuUACeJAmaYNroxeuBysvhFEpTfbe+D+vrMhGE+IrHQHLxCTeVaSHz05aewfe F84n7djoxyBj48jPSB19ayWRHBkBgvKebu5sLNCJGjJ6hP74EFGS4hU9pb6yZgeD sq9XWkFwBeI25LOpHqGlocFfsOV/d+phbwpuXzIz+X+jtjDkowpOfEyY8tr17n+B KkP+Ust0Kd66vnSJbg4G9nDfyVBrmOYoI9xx2A/k4VNg6B5+KBgyWfnfb7ubvIR9 DezDB3PvTm2XT6rlkgoMh0eQ+Ta4jICX48jkRHD8IwsZZ7C8mSMGhXS3jjQbzPXE qAYTqCfHbAQTqq3rQv+A =xXlV -----END PGP SIGNATURE----- --Z9TvlI/Spa97+Fm/-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 21:21:17 2014 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 ESMTPS id E26AE920 for ; Wed, 6 Aug 2014 21:21:17 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A4D3A2904 for ; Wed, 6 Aug 2014 21:21:17 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 7B46A58; Wed, 6 Aug 2014 17:21:15 -0400 (EDT) Message-ID: <53E29C4A.1060202@protected-networks.net> Date: Wed, 06 Aug 2014 17:21:14 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: =?windows-1252?Q?Trond_Endrest=F8l?= , current@freebsd.org Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <53E1450D.5090708@protected-networks.net> <53E14CD1.20308@protected-networks.net> <8B832384-C1CC-4622-BA67-7447ECE317C9@FreeBSD.org> <20140806210759.GM1228@albert.catwhisker.org> In-Reply-To: <20140806210759.GM1228@albert.catwhisker.org> OpenPGP: id=0442D492 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 21:21:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/06/14 17:07, David Wolfskill wrote: > On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestl wrote: >> ... Reverting r269510 did the trick, i.e.: >> >> cd /usr/src && svn up && svn diff -r 269510:269509 | patch >> >> My i386 head VM is running smoothly with r269641M, with M meaning >> only the above reversal. Solves the problem for both of my machines, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPinEkACgkQQv9rrgRC1JLZfACgiiXUShFuZSSGcHdp256kdKM+ Du8An2St9nEIaTC6ViBNCrET+rXGD10I =vkkP -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 21:45:11 2014 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 ESMTPS id EE21D816 for ; Wed, 6 Aug 2014 21:45:11 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FEFF2D08 for ; Wed, 6 Aug 2014 21:45:11 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id s76Lj66J004616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Aug 2014 23:45:06 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id s76Lj6Gp004613 for ; Wed, 6 Aug 2014 23:45:06 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 6 Aug 2014 23:45:06 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: current@freebsd.org Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] In-Reply-To: Message-ID: References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <53E1450D.5090708@protected-networks.net> <53E14CD1.20308@protected-networks.net> <8B832384-C1CC-4622-BA67-7447ECE317C9@FreeBSD.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 06 Aug 2014 21:45:12 -0000 On Wed, 6 Aug 2014 22:48+0200, Trond Endrestl wrote: > On Wed, 6 Aug 2014 19:21+0200, Trond Endrestl wrote: > > > On Tue, 5 Aug 2014 20:49-0700, John Baldwin wrote: > > > > > > > > On Aug 5, 2014, at 2:29 PM, Michael Butler wrote: > > > > > > > On 08/05/14 16:56, Michael Butler wrote: > > > >> On 08/05/14 16:02, John Baldwin wrote: > > > >> > > > >>> My guess is that the recent Xen changes tickled something. > > > >> > > > >> I can confirm this on a kernel which is otherwise up to date .. > > > >> > > > >> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD > > > >> 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 > > > >> > > > >> I backed out all of SVN r269507 through r269515. > > > >> > > > >> Now working .. > > > > > > > > [ .. snip .. ] > > > > > > > >> Now to see if it's related to the other machine's disk woes (it's a > > > >> single-core device), > > > > > > > > And it fixes the inability to probe disks on my single-core machine :-) > > > > > > It looks like the MADT code to probe the I/O APICs isn't working so > > > it's trying to fall back to using the ATPIC while using SMP (which > > > doesn't work). I know it's a pain on a laptop, but if it is at all > > > possible to capture either a verbose or non-verbose dmesg that would > > > really help narrow it down. > > > > > > Also, if anyone can try reverting just the MADT-related changes in > > > the recent Xen changes to see if you can narrow down which exact one > > > triggers the panic that would be really helpful. > > > > I noticed this panic on i386 head r269607 yesterday, running in VBox > > on Windows 7 SP1 x64, on an Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz > > (3175.67-MHz 686-class CPU). > > > > Go to http://ximalas.info/~trond/atpic_assign_cpu/ where you'll find a > > verbose dmesg from i386 head r268838 from the same VM and a couple of > > screenshots of the crash while booting r269607 with the verbose flag > > on. > > > > I'm rewinding /usr/src to r269507, and I'll take it from there, one > > commit at the time. > > Reverting r269510 did the trick, i.e.: > > cd /usr/src && svn up && svn diff -r 269510:269509 | patch > > My i386 head VM is running smoothly with r269641M, with M meaning only > the above reversal. > > > I'll also try to investigate this panic using my amd64 head VM. > > Work in progress. amd64 is unaffected, as r269644 worked without any modifications. I'm guessing the changes to sys/x86/x86/local_apic.c and sys/x86/xen/xen_intr.c come as a pair. If not, then the changes done to sys/x86/x86/local_apic.c is the culprit somehow. Trond, going to bed. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 06:11:20 2014 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 ESMTPS id 5318AF67 for ; Thu, 7 Aug 2014 06:11:20 +0000 (UTC) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 1DFA825CC for ; Thu, 7 Aug 2014 06:11:19 +0000 (UTC) Received: (qmail 61944 invoked from network); 7 Aug 2014 06:11:11 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay01.pair.com with SMTP; 7 Aug 2014 06:11:11 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id s776BBvB006800; Thu, 7 Aug 2014 08:11:11 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id s776BB9X006799; Thu, 7 Aug 2014 08:11:11 +0200 (CEST) (envelope-from pho) Date: Thu, 7 Aug 2014 08:11:11 +0200 From: Peter Holm To: Konstantin Belousov Subject: Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() Message-ID: <20140807061111.GA6625@x2.osted.lan> References: <53E1975D.4010703@FreeBSD.org> <20140806031932.GE93733@kib.kiev.ua> <53E1A76A.1070400@FreeBSD.org> <53E26A6C.4000806@FreeBSD.org> <20140806181512.GK93733@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140806181512.GK93733@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org, Bryan Drewery X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 06:11:20 -0000 On Wed, Aug 06, 2014 at 09:15:12PM +0300, Konstantin Belousov wrote: > On Wed, Aug 06, 2014 at 12:48:28PM -0500, Bryan Drewery wrote: > > On 8/5/2014 10:56 PM, Bryan Drewery wrote: > > > On 8/5/2014 10:19 PM, Konstantin Belousov wrote: > > >> On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: > > >>> Has anyone else encountered this? Got it while running poudriere. > > >>> > > >>>> NULL mp in getnewvnode() > > >>>> [...] > > >>>> vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247d8e540 > > >>>> vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247d8e590 > > >>>> export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247d8e7c0 > > >>>> kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > > >>>> 0xfffffe1247d8e840 > > >>>> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame > > >>>> 0xfffffe1247d8e900 > > >>>> sysctl_root_handler_locked() at > > >>>> sysctl_root_handler_locked+0x68/frame 0xfffffe1247d8e940 > > >>>> sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247d8e990 > > >>>> userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247d8ea30 > > >>>> sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247d8eae0 > > >>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d8ebf0 > > >>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d8ebf0 > > >>> > > >>> Unfortunately I have no dump as the kmem was too large compared to my > > >>> swap, and I didn't get to the console before some of the text was > > >>> overwritten. Perhaps it will hit it again soon after reboot and I'll get > > >>> a core. > > >> > > >> "NULL mp in getnewvnode()" is only the printf(), it is not a panic or > > >> KASSERT. The event does not stop the machine, nor it prints the > > >> backtrace. > > >> > > >> You mentioned that you was unable to dump, so did the system paniced ? > > >> Without full log of the panic messages and backtrace, it is impossible > > >> to start guessing what the problem is. > > >> > > >> That said, the printf seemingly outlived its usefulness. > > >> > > > > > > Got it. I've set debug.debugger_on_panic=1 to not auto reboot on panic > > > next time this happens. I had it at 0 which was causing the lack of > > > information in these. > > > > Here is the full trace: > > > > > > > NULL mp in getnewvnode() > > > VNASSERT failed > > > 0xfffff806071dc760: tag null, type VDIR > > > usecount 1, writecount 0, refcount 1 mountedhere 0 > > > flags () > > > lock type zfs: EXCL by thread 0xfffff8009a53f490 (pid 1028, tmux, tid 100881) > > > vp=0xfffff806071dc760, lowervp=0xfffff8013157f588 > > > panic: Don't call insmntque(foo, NULL) > > > cpuid = 5 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe1247e76b50 > > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247e76c00 > > > vpanic() at vpanic+0x126/frame 0xfffffe1247e76c40 > > > kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247e76cb0 > > > insmntque1() at insmntque1+0x230/frame 0xfffffe1247e76cf0 > > > null_nodeget() at null_nodeget+0x158/frame 0xfffffe1247e76d60 > > > null_lookup() at null_lookup+0xeb/frame 0xfffffe1247e76dd0 > > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfffffe1247e76e00 > > > lookup() at lookup+0x5ad/frame 0xfffffe1247e76e90 > > > namei() at namei+0x4e4/frame 0xfffffe1247e76f50 > > > vn_open_cred() at vn_open_cred+0x27a/frame 0xfffffe1247e770a0 > > > vop_stdvptocnp() at vop_stdvptocnp+0x161/frame 0xfffffe1247e773e0 > > > null_vptocnp() at null_vptocnp+0x2b/frame 0xfffffe1247e77440 > > > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf7/frame 0xfffffe1247e77470 > > > vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfffffe1247e774e0 > > > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247e77540 > > > vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247e77590 > > > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247e777c0 > > > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xfffffe1247e77840 > > > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame 0xfffffe1247e77900 > > > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame 0xfffffe1247e77940 > > > sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247e77990 > > > userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247e77a30 > > > sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247e77ae0 > > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247e77bf0 > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247e77bf0 > > > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x801041fca, rsp = 0x7fffffffd878, rbp = 0x7fffffffd8b0 --- > > > KDB: enter: panic > > > [ thread pid 1028 tid 100881 ] > > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > > db> call doadump() > > > > > > Dump failed. Partition too small. > > > = 0 > > > > Try this. > > diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c > index 481644c..e803c24 100644 > --- a/sys/fs/nullfs/null_vnops.c With this patch I get a panic: Lock (lockmgr) null not locked @ kern/vfs_default.c:523. Details @ http://people.freebsd.org/~pho/stress/log/kostik698.txt - Peter From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 08:16:04 2014 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 ESMTPS id 3A80025D; Thu, 7 Aug 2014 08:16:04 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id D146C2268; Thu, 7 Aug 2014 08:16:03 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 5D570B84D; Thu, 7 Aug 2014 10:15:51 +0200 (SAST) Date: Thu, 7 Aug 2014 10:15:51 +0200 From: John Hay To: "Bjoern A. Zeeb" Subject: Re: m4 still broken on gcc platforms Message-ID: <20140807081551.GA72912@zibbi.meraka.csir.co.za> References: <1D4B336F-CCE0-4FD2-AE50-1C766D8990E2@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D4B336F-CCE0-4FD2-AE50-1C766D8990E2@lists.zabbadoz.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Baptiste Daroussin , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 08:16:04 -0000 On Thu, Jul 31, 2014 at 08:15:32AM +0000, Bjoern A. Zeeb wrote: > Hi, > > I am still seeing this with arm/power/sparc/mips. Can somene please fix it? Did this get fixed because I still see it on -current while trying to build armeb for the AVILA and CAMBRIA boards. Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za > > > > ===> usr.bin/m4/tests (all) > cc1: warnings being treated as errors > /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c: In function 'm4errx': > /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c:268: warning: declaration of 'eval' shadows a global declaration > /scratch/tmp/bz/head.svn/usr.bin/m4/extern.h:40: warning: shadowed declaration is here > --- misc.o --- > *** [misc.o] Error code 1 > > bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4 > cc1: warnings being treated as errors > /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_remove': > /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:123: warning: cast discards qualifiers from pointer target type > /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_find': > /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:144: warning: cast discards qualifiers from pointer target type > /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_next': > /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:183: warning: cast discards qualifiers from pointer target type > --- ohash.o --- > *** [ohash.o] Error code 1 > > bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4 > --- all_subdir_m4 --- > *** [all_subdir_m4] Error code 1 > > bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin > ===> usr.bin/mail (all) > > > ? > Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 > From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 08:23:51 2014 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 ESMTPS id D1AC9566 for ; Thu, 7 Aug 2014 08:23:51 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65250244A for ; Thu, 7 Aug 2014 08:23:51 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id u57so3800444wes.10 for ; Thu, 07 Aug 2014 01:23:49 -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=OQPo3pd1RNM6DAsMP0YXI2E/nEoMRW2YwQBMznOALns=; b=e1Tmd15lux8bLt68h7+nmJ/RWsv6Oug0Bhgq/luMX3/i+K8vScByHSh0N06pTHnyxH DtVMB+KCAlAEf1wQVmDtGh0DI/Xa2Tv8H4kXPXKLG6EEOvSe/7zUWzI7zulGVwCZlVyr 8OTb2yKeDQOhM7FvhpAuKAtOL6z/1tApCTEWvqb67AOH4KECkrXaqbDfBNblrkGrEbLu /I1u9AiAouz301i20cTsVzCIWFBj6vUjBJy0cPXS168OueTiCPayQ5dTozMhWM2MqbzF 7cIW79HvIWgb2sqBHyfPkKcZdiqfjLOovIoMeWVEcNRxi4KjdBBiSxnCSTSvIXmsZk8E 2Wmg== X-Received: by 10.194.60.110 with SMTP id g14mr22808507wjr.101.1407399829296; Thu, 07 Aug 2014 01:23:49 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id xn12sm26539845wib.13.2014.08.07.01.23.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Aug 2014 01:23:48 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 7 Aug 2014 10:23:46 +0200 From: Baptiste Daroussin To: John Hay Subject: Re: m4 still broken on gcc platforms Message-ID: <20140807082345.GT17537@ivaldir.etoilebsd.net> References: <1D4B336F-CCE0-4FD2-AE50-1C766D8990E2@lists.zabbadoz.net> <20140807081551.GA72912@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dBMBt2YGaTHbdllf" Content-Disposition: inline In-Reply-To: <20140807081551.GA72912@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 08:23:51 -0000 --dBMBt2YGaTHbdllf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 07, 2014 at 10:15:51AM +0200, John Hay wrote: > On Thu, Jul 31, 2014 at 08:15:32AM +0000, Bjoern A. Zeeb wrote: > > Hi, > >=20 > > I am still seeing this with arm/power/sparc/mips. Can somene please fi= x it? >=20 > Did this get fixed because I still see it on -current while trying to > build armeb for the AVILA and CAMBRIA boards. >=20 It has ben fixed last week regards, Bapt --dBMBt2YGaTHbdllf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPjN5EACgkQ8kTtMUmk6ExqPgCeMc84EBdnl9Ujl1pxbwrYRiLR WxcAnimWPw4XEwp0GYmU7yCl8IXJEi7r =7njK -----END PGP SIGNATURE----- --dBMBt2YGaTHbdllf-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 09:16:51 2014 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 ESMTPS id 6759B6DC; Thu, 7 Aug 2014 09:16:51 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3142A2D; Thu, 7 Aug 2014 09:16:50 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id B166FB84C; Thu, 7 Aug 2014 11:16:47 +0200 (SAST) Date: Thu, 7 Aug 2014 11:16:47 +0200 From: John Hay To: Baptiste Daroussin Subject: Re: m4 still broken on gcc platforms Message-ID: <20140807091647.GA73290@zibbi.meraka.csir.co.za> References: <1D4B336F-CCE0-4FD2-AE50-1C766D8990E2@lists.zabbadoz.net> <20140807081551.GA72912@zibbi.meraka.csir.co.za> <20140807082345.GT17537@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140807082345.GT17537@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 09:16:51 -0000 On Thu, Aug 07, 2014 at 10:23:46AM +0200, Baptiste Daroussin wrote: > On Thu, Aug 07, 2014 at 10:15:51AM +0200, John Hay wrote: > > On Thu, Jul 31, 2014 at 08:15:32AM +0000, Bjoern A. Zeeb wrote: > > > Hi, > > > > > > I am still seeing this with arm/power/sparc/mips. Can somene please fix it? > > > > Did this get fixed because I still see it on -current while trying to > > build armeb for the AVILA and CAMBRIA boards. > > > It has ben fixed last week It is still broken for me. Maybe it is my environment. The last time I have updated my source tree was about 2 weeks ago and with that I could build working AVILA and CAMBRIA boards. I have updated now so that I could get the interrupt fixes that Ian committed a few hours ago. My tree is at svn 269656. The machine I am building on is running 10-stable from around 30 March, if that makes a difference. Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 09:26:03 2014 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 ESMTPS id C3B1C971; Thu, 7 Aug 2014 09:26:03 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3193E2B68; Thu, 7 Aug 2014 09:26:03 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s779Pvb1095424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2014 12:25:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s779Pvb1095424 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s779PvcE095420; Thu, 7 Aug 2014 12:25:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Aug 2014 12:25:57 +0300 From: Konstantin Belousov To: Baptiste Daroussin Subject: Re: m4 still broken on gcc platforms Message-ID: <20140807092557.GR93733@kib.kiev.ua> References: <1D4B336F-CCE0-4FD2-AE50-1C766D8990E2@lists.zabbadoz.net> <20140807081551.GA72912@zibbi.meraka.csir.co.za> <20140807082345.GT17537@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pgLsEtboAgeppo3k" Content-Disposition: inline In-Reply-To: <20140807082345.GT17537@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: John Hay , "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 09:26:03 -0000 --pgLsEtboAgeppo3k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 07, 2014 at 10:23:46AM +0200, Baptiste Daroussin wrote: > On Thu, Aug 07, 2014 at 10:15:51AM +0200, John Hay wrote: > > On Thu, Jul 31, 2014 at 08:15:32AM +0000, Bjoern A. Zeeb wrote: > > > Hi, > > >=20 > > > I am still seeing this with arm/power/sparc/mips. Can somene please = fix it? > >=20 > > Did this get fixed because I still see it on -current while trying to > > build armeb for the AVILA and CAMBRIA boards. > >=20 > It has ben fixed last week The build is still broken. I did not looked too closely, but it seems related. /scratch/tmp/kib/src/usr.bin/m4/misc.c: In function 'm4errx': /scratch/tmp/kib/src/usr.bin/m4/misc.c:268: warning: declaration of 'eval' = shadows a global declaration /scratch/tmp/kib/src/usr.bin/m4/extern.h:40: warning: shadowed declaration = is here --pgLsEtboAgeppo3k Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT40YlAAoJEJDCuSvBvK1BZxwP/iTs4jpIUsmBP86mRcDaizOW FHprKQeDKhG9kImzJD1tShOs9O6xf5kiPAzxtgtp/msTkjbo/HEpMX9tRGtn8onM zbtlW3Av2A5jmTIPFbFyJSkcwB1n6YEGsk/T5EMSi552Ol9eZ7mhkYUYkZpG54NL oGf+mZ9uYDhE8o1onep+jiNsvptrl/3uCV/poFRhAoo5O/t2G7gcZNifYXvgwbd1 B7H+Q9ZVOEK1/PBrryoqlHLCKvOEbgTItSLNNUjHGqVI1mPAdCiipVstkRBt4e28 h6ueKL/6tBtXHbQggwnJKbZUuG5REwkwoR8HvQ3MmXqDEBzz8m95mPC5qo1tpYhD Hhmhz26dt0BSxZnUw6UdD4id3MK0KFf0X9N0t1pyyrc7RgtOQ6uL41pRxubXiHQ3 Wh/Cgz60/1yJKgHjT+1VLVKghpD8lCDjRnBi8fjIinbBXpkGxq2FwoH14UpEtOl7 riUpnep6l6pM5RTNl6D/0kr8XrLoXA0kgVzTtQEk9lIAiPA8zcScSH6wEHoNdQuq BRuSF3Xvxo0LjkL7PE9s+t88vQEWhFqhlUsW2elQVZClZI1QKwk1KINU/axROQaI Gipu4iahW38r2ApORyQc9vqAhgJQqBS8GNns7+wg7ERKYaOg5FhpNWcSKCBKFWSt Zlgv5JdXGWkbS5W4gIXA =LDaK -----END PGP SIGNATURE----- --pgLsEtboAgeppo3k-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 09:35:39 2014 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 ESMTPS id 6F58EB84 for ; Thu, 7 Aug 2014 09:35:39 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 025CE2CDA for ; Thu, 7 Aug 2014 09:35:38 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id z12so3915999wgg.24 for ; Thu, 07 Aug 2014 02:35:37 -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=XytxFPGXxO/m4u8vTSHmoLLUcfPjpES8L4fLqSneYOc=; b=wFJC8FLRPhjXWD7L1WpL6v8PLgTjNZHkI6ToppQ1uO84sbCI2sGxhO9NUPgKhH4YRB p2WdmytxQKIt7lee6ht4hCRnzBBXVEbIIoDhQbGaA8HBVcy2Bm1Ac7ZSGQ5YtWqeHP2j NStoQEB4VyIF81NJow+25bk4slZGRNmtRwcGZRfwibvWORh+VtPKEMs05C++RI8hRtXH ysyKe4H2TN3gv94sPUcC8FS/z4JnJhXC9lTwphrXj1f4C1PLeTTjfeeIIGDRbMz7n88X HropMtMw53GOfKtNHPJfuJYy7+Ok7BOhXu2eit6TLvlpvffPfjWzLvFNfAGW4YoGROEh Z5gg== X-Received: by 10.180.221.65 with SMTP id qc1mr58688507wic.28.1407404137247; Thu, 07 Aug 2014 02:35:37 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id r20sm27143961wik.0.2014.08.07.02.35.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Aug 2014 02:35:36 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 7 Aug 2014 11:35:34 +0200 From: Baptiste Daroussin To: Konstantin Belousov Subject: Re: m4 still broken on gcc platforms Message-ID: <20140807093534.GU17537@ivaldir.etoilebsd.net> References: <1D4B336F-CCE0-4FD2-AE50-1C766D8990E2@lists.zabbadoz.net> <20140807081551.GA72912@zibbi.meraka.csir.co.za> <20140807082345.GT17537@ivaldir.etoilebsd.net> <20140807092557.GR93733@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NQqDiQVflaif2hna" Content-Disposition: inline In-Reply-To: <20140807092557.GR93733@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: John Hay , "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 09:35:39 -0000 --NQqDiQVflaif2hna Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 07, 2014 at 12:25:57PM +0300, Konstantin Belousov wrote: > On Thu, Aug 07, 2014 at 10:23:46AM +0200, Baptiste Daroussin wrote: > > On Thu, Aug 07, 2014 at 10:15:51AM +0200, John Hay wrote: > > > On Thu, Jul 31, 2014 at 08:15:32AM +0000, Bjoern A. Zeeb wrote: > > > > Hi, > > > >=20 > > > > I am still seeing this with arm/power/sparc/mips. Can somene pleas= e fix it? > > >=20 > > > Did this get fixed because I still see it on -current while trying to > > > build armeb for the AVILA and CAMBRIA boards. > > >=20 > > It has ben fixed last week >=20 > The build is still broken. I did not looked too closely, but it seems > related. >=20 > /scratch/tmp/kib/src/usr.bin/m4/misc.c: In function 'm4errx': > /scratch/tmp/kib/src/usr.bin/m4/misc.c:268: warning: declaration of 'eval= ' shadows a global declaration > /scratch/tmp/kib/src/usr.bin/m4/extern.h:40: warning: shadowed declaratio= n is here >=20 Oh right I broke this yesterday Let me fix regards, Bapt --NQqDiQVflaif2hna Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPjSGYACgkQ8kTtMUmk6Ez7dACgvflA37I4tn05dSA6jwCpfSFW Aj8AoLcl77QWLlx2LxIeEgrZAW2RBjsa =VA50 -----END PGP SIGNATURE----- --NQqDiQVflaif2hna-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 11:32:56 2014 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 ESMTPS id E1A2077E for ; Thu, 7 Aug 2014 11:32:55 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D6A72A1A for ; Thu, 7 Aug 2014 11:32:55 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id l18so3921101wgh.26 for ; Thu, 07 Aug 2014 04:32:53 -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:subject :references:in-reply-to:content-type; bh=fXtakixbLr55wBWU9qAR6MM0oWNwTHmAEi/aVtqYeh0=; b=nZdyR6nGhtqaxyzi5tDXw0PZwC2EXeM/HvMx3Rxedp2r1q2sOw3M8ju0s0VrXTtYwo 3Vkip6xK6FxW+2NS8XgNqUk0A6stfURk4YQojAhSp/aE6nXOHZAKKgZPsV2vvQII7PAc zCpE17lZt0kMyooRJ/eMAf/Gea7AoiR5cE6Mutai3aEXpWKyoQpB7JxtFmiXWohuKYmn ZCE10hIELo3TuXEw1bAaFhiebRbRPCoMsalWU4U0IPmbBKZoCQRnwxrZWifnlKzEcnIz rF2eZsVF146O3p0TKOB06SomFSRFH7txODPpRLg3lAyU3CdbzW9EAUAxKQfoeBlnvyoE rysQ== X-Received: by 10.195.11.234 with SMTP id el10mr24004789wjd.95.1407411173406; Thu, 07 Aug 2014 04:32:53 -0700 (PDT) Received: from [172.16.1.30] (39.Red-2-136-52.dynamicIP.rima-tde.net. [2.136.52.39]) by mx.google.com with ESMTPSA id lq15sm15893343wic.1.2014.08.07.04.32.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 04:32:52 -0700 (PDT) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: <53E363DD.4040105@FreeBSD.org> Date: Thu, 07 Aug 2014 13:32:45 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Wolfskill , =?ISO-8859-1?Q?Trond_Endres?= =?ISO-8859-1?Q?t=F8l?= , current@freebsd.org Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <53E1450D.5090708@protected-networks.net> <53E14CD1.20308@protected-networks.net> <8B832384-C1CC-4622-BA67-7447ECE317C9@FreeBSD.org> <20140806210759.GM1228@albert.catwhisker.org> In-Reply-To: <20140806210759.GM1228@albert.catwhisker.org> Content-Type: multipart/mixed; boundary="------------010804040204010005020409" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 11:32:56 -0000 This is a multi-part message in MIME format. --------------010804040204010005020409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 06/08/14 23:07, David Wolfskill wrote: > On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestl wrote: >> ... >> Reverting r269510 did the trick, i.e.: >> >> cd /usr/src && svn up && svn diff -r 269510:269509 | patch >> >> My i386 head VM is running smoothly with r269641M, with M meaning only >> the above reversal. >> ... > > Works for me, as well -- thanks! > > FreeBSD 11.0-CURRENT #1333 r269622M/269622:1100028: Wed Aug 6 14:01:30 PDT 2014 > > (I'll be providing more details to royger@ et al. in a moment.) I think I've found the issue, but since I'm not able to reproduce it, could someone try the following patch? (without r269510 reverted). Thanks, Roger. --------------010804040204010005020409 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="0001-atpic-make-sure-atpic_init-is-called-after-IO-APIC-i.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-atpic-make-sure-atpic_init-is-called-after-IO-APIC-i.pa"; filename*1="tch" >From 91264290520a6a6eee6cd35d05a65e2dd0e61dc8 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Thu, 7 Aug 2014 12:05:10 +0200 Subject: [PATCH] atpic: make sure atpic_init is called after IO APIC initialization After r269510 the IO APIC and ATPIC initialization is done at the same order, which means atpic_init can be called before the IO APIC has been initalized. In that case the ATPIC will take over the interrupt sources, preventing the IO APIC from registering them. Reported by: David Wolfskill Sponsored by: Citrix Systems R&D --- sys/x86/isa/atpic.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sys/x86/isa/atpic.c b/sys/x86/isa/atpic.c index 6ce6d1a..e3fdb34 100644 --- a/sys/x86/isa/atpic.c +++ b/sys/x86/isa/atpic.c @@ -524,7 +524,7 @@ atpic_init(void *dummy __unused) intr_register_source(&ai->at_intsrc); } } -SYSINIT(atpic_init, SI_SUB_INTR, SI_ORDER_SECOND + 1, atpic_init, NULL); +SYSINIT(atpic_init, SI_SUB_INTR, SI_ORDER_FOURTH, atpic_init, NULL); void atpic_handle_intr(u_int vector, struct trapframe *frame) -- 1.7.7.5 (Apple Git-26) --------------010804040204010005020409-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 11:37:27 2014 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 ESMTPS id F32388DF for ; Thu, 7 Aug 2014 11:37:26 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F1D42A50 for ; Thu, 7 Aug 2014 11:37:26 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id s77BbMW9037771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Aug 2014 13:37:22 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id s77BbMMl037768 for ; Thu, 7 Aug 2014 13:37:22 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Thu, 7 Aug 2014 13:37:22 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: current@freebsd.org Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] In-Reply-To: <53E363DD.4040105@FreeBSD.org> Message-ID: References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <53E1450D.5090708@protected-networks.net> <53E14CD1.20308@protected-networks.net> <8B832384-C1CC-4622-BA67-7447ECE317C9@FreeBSD.org> <20140806210759.GM1228@albert.catwhisker.org> <53E363DD.4040105@FreeBSD.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-ID: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 11:37:27 -0000 On Thu, 7 Aug 2014 13:32+0200, Roger Pau Monn wrote: > On 06/08/14 23:07, David Wolfskill wrote: > > On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestl wrote: > >> ... > >> Reverting r269510 did the trick, i.e.: > >> > >> cd /usr/src && svn up && svn diff -r 269510:269509 | patch > >> > >> My i386 head VM is running smoothly with r269641M, with M meaning only > >> the above reversal. > >> ... > > > > Works for me, as well -- thanks! > > > > FreeBSD 11.0-CURRENT #1333 r269622M/269622:1100028: Wed Aug 6 14:01:30 PDT 2014 > > > > (I'll be providing more details to royger@ et al. in a moment.) > > I think I've found the issue, but since I'm not able to reproduce it, > could someone try the following patch? (without r269510 reverted). I'll try it once I'm back home, in about 3 hours. > Thanks, Roger. NP. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 12:27:33 2014 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 ESMTPS id 45F7C9E3 for ; Thu, 7 Aug 2014 12:27:33 +0000 (UTC) Received: from ivan-labs.com (ivan-labs.com [162.243.251.239]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC1D2124 for ; Thu, 7 Aug 2014 12:27:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ivan-labs.com (Postfix) with ESMTP id 6795C120625 for ; Thu, 7 Aug 2014 16:18:26 +0400 (MSK) X-Virus-Scanned: Debian amavisd-new at Received: from ivan-labs.com ([127.0.0.1]) by localhost (ivan-labs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPgZShpXcjKw for ; Thu, 7 Aug 2014 16:18:26 +0400 (MSK) Received: from [192.168.43.253] (host-48-159-66-217.spbmts.ru [217.66.159.48]) by ivan-labs.com (Postfix) with ESMTPSA id 79787120056 for ; Thu, 7 Aug 2014 16:18:22 +0400 (MSK) Message-ID: <53E36E84.4060806@ivan-labs.com> Date: Thu, 07 Aug 2014 16:18:12 +0400 From: "Ivan A. Kosarev" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: libthr and main thread stack size Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 12:27:33 -0000 Hello, According to libthr's thr_init.c (the 9.2 version) init_main_thread() allocates s.c. "red zone" below the main stack in order to protect other stacks. The size of the main stack is determined by the _thr_stack_initial variable that is declared extern though it doesn't seem it can be changed. The value of the variable is set to 4M on 64-bit platforms which is obviously not sufficient for the most of real programs. Can anyone please confirm that there is no way to increase the stack size for the main thread and thus any program linked against libthr has only a few megabytes of stack memory for its main thread--whatever the system stack size (ulimit -s) is set to? Thanks. -- From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 13:41:16 2014 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 ESMTPS id 05172CE8; Thu, 7 Aug 2014 13:41:16 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E575D2A0C; Thu, 7 Aug 2014 13:41:15 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5B1D3B8D; Thu, 7 Aug 2014 13:41:15 +0000 (UTC) Date: Thu, 7 Aug 2014 13:41:12 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, ae@FreeBSD.org, bapt@FreeBSD.org, roberto@FreeBSD.org Message-ID: <1669498700.519.1407418873817.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1189 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 13:41:16 -0000 See Changes: [roberto] 10 has a new flex (2.5.37) and the config.h for unbound has been updated to take this into account. Alas it breaks source upgrade from any version of 9 because flex is not built as a bootstrap-tools (it would be for older versions). That means "libunbound/configlexer.c" is built with the old flex but using config.h for the new one. Build is thus broken going from 9.* to 10. Make flex a bootstrap-tools entry if host is less than 1000033 to take into account the flex update in 10. Tested on both 9.2-RC3 and 9.3 by myself and dim@. Running buildworld in head but as both 10 and 11 has the new flex, it will not matter. Reviewed by: imp Approved by: des, imp MFC after: 1 week Phabric: D554 [ae] Use cpuset_setithread() to apply cpu mask to taskq threads. Sponsored by: Yandex LLC [bapt] Lower warnings again to 3 the right thing would be to fix the warnings which will be done by discussing with upstream I want the m4 code to stay as close as possible to upstream. ------------------------------------------ [...truncated 269369 lines...] --- rt2661.o --- ctfconvert -L VERSION -g rt2661.o --- if_sn.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- syscons.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- randomdev.o --- ctfconvert -L VERSION -g randomdev.o --- uart_dbg.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror ctfconvert -L VERSION -g uart_dbg.o --- uart_subr.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror ctfconvert -L VERSION -g uart_subr.o --- ehci.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- if_sn.o --- ctfconvert -L VERSION -g if_sn.o --- ohci.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- syscons.o --- ctfconvert -L VERSION -g syscons.o --- uhci.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- ehci.o --- ctfconvert -L VERSION -g ehci.o --- xhci.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- ohci.o --- ctfconvert -L VERSION -g ohci.o --- usb_busdma.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- rt2860.o --- ctfconvert -L VERSION -g rt2860.o --- usb_compat_linux.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_busdma.o --- ctfconvert -L VERSION -g usb_busdma.o --- usb_core.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- uhci.o --- ctfconvert -L VERSION -g uhci.o --- usb_debug.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_core.o --- ctfconvert -L VERSION -g usb_core.o --- usb_dynamic.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_debug.o --- ctfconvert -L VERSION -g usb_debug.o --- usb_error.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_compat_linux.o --- ctfconvert -L VERSION -g usb_compat_linux.o --- usb_dynamic.o --- ctfconvert -L VERSION -g usb_dynamic.o --- usb_generic.o --- --- usb_hid.o --- --- usb_generic.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_hid.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_error.o --- ctfconvert -L VERSION -g usb_error.o --- usb_hub.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_hid.o --- ctfconvert -L VERSION -g usb_hid.o --- usb_lookup.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- xhci.o --- ctfconvert -L VERSION -g xhci.o --- usb_mbuf.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_lookup.o --- ctfconvert -L VERSION -g usb_lookup.o --- usb_msctest.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_mbuf.o --- ctfconvert -L VERSION -g usb_mbuf.o --- usb_parse.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_generic.o --- ctfconvert -L VERSION -g usb_generic.o --- usb_pf.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_parse.o --- ctfconvert -L VERSION -g usb_parse.o --- usb_process.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_hub.o --- ctfconvert -L VERSION -g usb_hub.o --- usb_request.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_msctest.o --- ctfconvert -L VERSION -g usb_msctest.o --- usb_transfer.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_process.o --- ctfconvert -L VERSION -g usb_process.o --- usb_util.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_pf.o --- ctfconvert -L VERSION -g usb_pf.o --- ukbd.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_util.o --- ctfconvert -L VERSION -g usb_util.o --- if_vx.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- usb_request.o --- ctfconvert -L VERSION -g usb_request.o --- watchdog.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror ctfconvert -L VERSION -g watchdog.o --- usb_transfer.o --- ctfconvert -L VERSION -g usb_transfer.o --- if_wi.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- if_xe.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- ukbd.o --- ctfconvert -L VERSION -g ukbd.o --- console.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- if_vx.o --- ctfconvert -L VERSION -g if_vx.o --- xencons_ring.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror ctfconvert -L VERSION -g xencons_ring.o --- pvcpu.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- console.o --- ctfconvert -L VERSION -g console.o --- geom_dev.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- pvcpu.o --- ctfconvert -L VERSION -g pvcpu.o --- kern_clock.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- geom_dev.o --- ctfconvert -L VERSION -g geom_dev.o --- kern_cpuset.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- if_xe.o --- ctfconvert -L VERSION -g if_xe.o --- if_wi.o --- ctfconvert -L VERSION -g if_wi.o --- kern_ffclock.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_intr.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_cpuset.o --- :637:16: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] for (i = 0; i < (_NCPUWORDS - 1); i++) { ~ ^ ~~~~~~~~~~~~~~~~ --- kern_clock.o --- ctfconvert -L VERSION -g kern_clock.o WARNING: kern_clock.c: enum pmc_event has too many values: 1755 > 1023 --- kern_mutex.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_ffclock.o --- ctfconvert -L VERSION -g kern_ffclock.o --- kern_racct.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_cpuset.o --- 1 warning generated. ctfconvert -L VERSION -g kern_cpuset.o --- kern_rctl.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_intr.o --- ctfconvert -L VERSION -g kern_intr.o --- kern_timeout.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_racct.o --- ctfconvert -L VERSION -g kern_racct.o --- kern_mutex.o --- ctfconvert -L VERSION -g kern_mutex.o --- sched_ule.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_mutex.o --- WARNING: kern_mutex.c: enum pmc_event has too many values: 1755 > 1023 --- subr_bus.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_rctl.o --- ctfconvert -L VERSION -g kern_rctl.o --- subr_bus_dma.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_timeout.o --- ctfconvert -L VERSION -g kern_timeout.o --- subr_clock.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_bus_dma.o --- ctfconvert -L VERSION -g subr_bus_dma.o --- subr_hints.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_clock.o --- ctfconvert -L VERSION -g subr_clock.o --- subr_kdb.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_hints.o --- ctfconvert -L VERSION -g subr_hints.o --- subr_rman.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_kdb.o --- ctfconvert -L VERSION -g subr_kdb.o --- subr_smp.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- sched_ule.o --- ctfconvert -L VERSION -g sched_ule.o --- subr_taskqueue.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_rman.o --- ctfconvert -L VERSION -g subr_rman.o --- subr_trap.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_taskqueue.o --- :541:42: error: incompatible pointer to integer conversion passing 'cpuset_t *' (aka 'struct _cpuset *') to parameter of type 'u_char' (aka 'unsigned char') [-Werror,-Wint-conversion] error = cpuset_setithread(td->td_tid, mask); ^~~~ :121:42: note: passing argument to parameter 'cpu' here int cpuset_setithread(lwpid_t id, u_char cpu); ^ 1 error generated. *** [subr_taskqueue.o] Error code 1 make[2]: stopped in /usr/obj --- subr_smp.o --- ctfconvert -L VERSION -g subr_smp.o --- subr_bus.o --- ctfconvert -L VERSION -g subr_bus.o --- subr_trap.o --- ctfconvert -L VERSION -g subr_trap.o 1 error make[2]: stopped in /usr/obj *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 14:49:17 2014 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 ESMTPS id 366CF172; Thu, 7 Aug 2014 14:49:17 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1600246E; Thu, 7 Aug 2014 14:49:16 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s77EnFJm032932; Thu, 7 Aug 2014 07:49:15 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s77EnF4K032931; Thu, 7 Aug 2014 07:49:15 -0700 (PDT) (envelope-from david) Date: Thu, 7 Aug 2014 07:49:15 -0700 From: David Wolfskill To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] Message-ID: <20140807144915.GE30083@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Roger Pau =?iso-8859-1?Q?Monn=E9?= , current@freebsd.org References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <53E1450D.5090708@protected-networks.net> <53E14CD1.20308@protected-networks.net> <8B832384-C1CC-4622-BA67-7447ECE317C9@FreeBSD.org> <20140806210759.GM1228@albert.catwhisker.org> <53E363DD.4040105@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5oH/S/bF6lOfqCQb" Content-Disposition: inline In-Reply-To: <53E363DD.4040105@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 14:49:17 -0000 --5oH/S/bF6lOfqCQb Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 07, 2014 at 01:32:45PM +0200, Roger Pau Monn=E9 wrote: > ... > I think I've found the issue, but since I'm not able to reproduce it, > could someone try the following patch? (without r269510 reverted). > ... That worked for me; thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --5oH/S/bF6lOfqCQb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT45HpXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk73o4P/2nFW81n9sU1lnNv6+vzmlhx seVrZ9tdZjGmtLX71ByfQZ8KCKigqmgoVIkaERK903ZdAS+AidXUnVf7cP8GP1+D bL3Yd3F9rCbk2SgzTeyt+eyw+yQBt7+0N2xnKQ9IGzNj/3WPbr+2uQcI4WEhU8dW 892zUTu4v93IZt4GgZssk/ZisGQ+yDrpaAIFR6LhSzj/je1wRp0VpleyXGdhJBTa 5ZlkCqSI4SiUaYps9QCTKGPrPCUVKq8B2S+iW9ZkLwLbxf+GILj9OVwm/GhqP792 eiAOcRZQ6HRFbcnaavLkFKhaq+yjtE5+jS7e2+m/u16E5CSDSW2ablcuT5TOnrTX 5qF0NgJowUIzyCqGJt2KtA3UPQEGxzNo8o8lA+A+r2yvMelbHt0g8kke4Y8vU359 7uSkUWW69rWnm0HN2uZLVG25Eo9Q7n2jK/bsH35yi26LbuN8QxsMhKx1XuaPzATa p/qH8PFrSQilCdI2TIHgvYAmbAlU30ELtY1qMuxm5CbijKqvtaaz4JRr8GYqCNWF 3I0CoLzX4SaJUuEei9i83ZOHkloJUczH6fTWAwZJWiR9uJOdwNvulhOP5gJWEto/ UGTXPf07lYeFfHBKOzyqiUp8jdZsXROZKTQ0n08oKAR8KhGSquLDJqiofpeBKLPP YcWR1m75qZJT9veZrpzQ =Rr8j -----END PGP SIGNATURE----- --5oH/S/bF6lOfqCQb-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 15:23:56 2014 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 ESMTPS id 5EB59504; Thu, 7 Aug 2014 15:23:56 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C232728D4; Thu, 7 Aug 2014 15:23:55 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id s77FNN9k039003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2014 17:23:23 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id s77FNNXC039000; Thu, 7 Aug 2014 17:23:23 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Thu, 7 Aug 2014 17:23:23 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: David Wolfskill Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] In-Reply-To: <20140807144915.GE30083@albert.catwhisker.org> Message-ID: References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <53E1450D.5090708@protected-networks.net> <53E14CD1.20308@protected-networks.net> <8B832384-C1CC-4622-BA67-7447ECE317C9@FreeBSD.org> <20140806210759.GM1228@albert.catwhisker.org> <53E363DD.4040105@FreeBSD.org> <20140807144915.GE30083@albert.catwhisker.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 15:23:56 -0000 On Thu, 7 Aug 2014 07:49-0700, David Wolfskill wrote: > On Thu, Aug 07, 2014 at 01:32:45PM +0200, Roger Pau Monn wrote: > > ... > > I think I've found the issue, but since I'm not able to reproduce it, > > could someone try the following patch? (without r269510 reverted). > > ... > > That worked for me; thanks! +1 Verbose dmesg for i386 head r269666M with http://ximalas.info/~trond/atpic_assign_cpu/sys-x86-isa-atpic.c.patch as the sole modification is available at http://ximalas.info/~trond/atpic_assign_cpu/dmesg-verbose-head-i386-r269666M.txt -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 16:41:00 2014 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 ESMTPS id 0B7375ED; Thu, 7 Aug 2014 16:41:00 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id ED26525A5; Thu, 7 Aug 2014 16:40:59 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5BF54BD5; Thu, 7 Aug 2014 16:40:57 +0000 (UTC) Date: Thu, 7 Aug 2014 16:40:55 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, ae@FreeBSD.org, bapt@FreeBSD.org, jmmv@FreeBSD.org, hselasky@FreeBSD.org, roberto@FreeBSD.org Message-ID: <117811198.520.1407429656071.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1669498700.519.1407418873817.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1669498700.519.1407418873817.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1190 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 16:41:00 -0000 See From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 21:17:16 2014 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 ESMTPS id 62285B2A; Thu, 7 Aug 2014 21:17:16 +0000 (UTC) Received: from shxd.cx (unknown [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50584282D; Thu, 7 Aug 2014 21:17:16 +0000 (UTC) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:51430 helo=THEMADHATTER) by shxd.cx with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XFM4p-000MfC-BM; Thu, 07 Aug 2014 04:41:47 -0700 From: To: Subject: loader lszfs command Date: Thu, 7 Aug 2014 14:17:14 -0700 Message-ID: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+yg2hu5ZBhsXYxQAmylfgsOK9Cew== Content-Language: en-us Sender: devin@shxd.cx Cc: dteske@freebsd.org, avg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 21:17:16 -0000 Hi, People have been pestering me to update the Forth code to present a menu of ZFS datasets (*cough* boot environments *cough*). Would love to, but existing code seems broken. Can *anybody* produce meaningful output from the following? http://svnweb.freebsd.org/base?view=revision&revision=241284 All I get on every system I've tried (multiple versions, including HEAD) produce the following: OK lszfs zroot ZFS: i/o error - all block copies unavailable operation not permitted It's really hard for me to start with something that's broken. Can I get confirmation that this doesn't appear to be working as intended? If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a ) not crazy and ( b ) seeing the same thing everybody else is seeing. -- Devin From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 23:15:46 2014 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 ESMTPS id 5A8C9F85; Thu, 7 Aug 2014 23:15:46 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B00B25D9; Thu, 7 Aug 2014 23:15:45 +0000 (UTC) Received: from [192.168.200.205] (c-50-131-5-126.hsd1.ca.comcast.net [50.131.5.126]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 46B7419290A; Thu, 7 Aug 2014 23:15:44 +0000 (UTC) Subject: Re: loader lszfs command From: Sean Bruno Reply-To: sbruno@freebsd.org To: dteske@FreeBSD.org In-Reply-To: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> References: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Aug 2014 16:15:44 -0700 Message-ID: <1407453344.5935.3.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 23:15:46 -0000 On Thu, 2014-08-07 at 14:17 -0700, dteske@FreeBSD.org wrote: > Hi, > > People have been pestering me to update the Forth code to present > a menu of ZFS datasets (*cough* boot environments *cough*). > > Would love to, but existing code seems broken. > > Can *anybody* produce meaningful output from the following? > > http://svnweb.freebsd.org/base?view=revision&revision=241284 > > All I get on every system I've tried (multiple versions, including HEAD) > produce the following: > > OK lszfs zroot > ZFS: i/o error - all block copies unavailable > operation not permitted > > It's really hard for me to start with something that's broken. Can > I get confirmation that this doesn't appear to be working as intended? > If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a ) > not > crazy and ( b ) seeing the same thing everybody else is seeing. Hrm ... this seems to work for me. (fairly recent 11-current) OK lszfs zroot $MOS $FREE $ORIGIN tmp home usr var tftpboot poudriere OK From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 23:29:22 2014 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 ESMTPS id 415383FE; Thu, 7 Aug 2014 23:29:22 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0093326D4; Thu, 7 Aug 2014 23:29:21 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id c1so184880igq.13 for ; Thu, 07 Aug 2014 16:29: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=+6kI73oxR9yA2vYrXDOrlSQU7LmpCRERgw/4MLdLhrs=; b=Vzy8fYwisMko1woVKe/KXydLr95RZdS4TF30r4NxO7Lxl0IHXyXLAjLP8KtXTxpIQf gh/W09hZNroFEbEqurVfzvHCV2fJNH8JT5QELdYJuiCbtrrul36oDjuTyzmPL9pxIacn RyZQAe9/hhFZ2Aj+nV36luh2ozznsz2p4PfpOX61zDsDyuoRL4iF0zQfhCgwyS8/Slms lX0j6wpudBNC5PpSQ02JPU5IrDzEk83YEVOwo4/pKW7P9NmNSd6n2gcdY5BvRjZrlsm7 QMA9sdrF+dPojuUiwRZ+TpFbLfbu8TZj/It6Jav0i6j4YCG8EC39pm+2HdBs+JUvDONg UocQ== MIME-Version: 1.0 X-Received: by 10.42.91.200 with SMTP id q8mr7423888icm.63.1407454161324; Thu, 07 Aug 2014 16:29:21 -0700 (PDT) Received: by 10.50.76.229 with HTTP; Thu, 7 Aug 2014 16:29:21 -0700 (PDT) In-Reply-To: <1407453344.5935.3.camel@bruno> References: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> <1407453344.5935.3.camel@bruno> Date: Thu, 7 Aug 2014 16:29:21 -0700 Message-ID: Subject: Re: loader lszfs command From: Garrett Cooper To: sbruno@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: dteske@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 23:29:22 -0000 Hi Devin! On Thu, Aug 7, 2014 at 4:15 PM, Sean Bruno wrote: > On Thu, 2014-08-07 at 14:17 -0700, dteske@FreeBSD.org wrote: >> Hi, >> >> People have been pestering me to update the Forth code to present >> a menu of ZFS datasets (*cough* boot environments *cough*). >> >> Would love to, but existing code seems broken. >> >> Can *anybody* produce meaningful output from the following? >> >> http://svnweb.freebsd.org/base?view=revision&revision=241284 >> >> All I get on every system I've tried (multiple versions, including HEAD) >> produce the following: >> >> OK lszfs zroot >> ZFS: i/o error - all block copies unavailable >> operation not permitted >> >> It's really hard for me to start with something that's broken. Can >> I get confirmation that this doesn't appear to be working as intended? >> If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a ) >> not >> crazy and ( b ) seeing the same thing everybody else is seeing. > > > Hrm ... this seems to work for me. (fairly recent 11-current) > > OK lszfs zroot > $MOS > $FREE > $ORIGIN > tmp > home > usr > var > tftpboot > poudriere > OK Is the installed version you have in synch with the kernel and zpool version for boot0, gptzfsboot, etc? Cheers! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 23:42:44 2014 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 ESMTPS id 6F2F2AB0; Thu, 7 Aug 2014 23:42:44 +0000 (UTC) Received: from shxd.cx (unknown [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58F0E2865; Thu, 7 Aug 2014 23:42:44 +0000 (UTC) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:52410 helo=THEMADHATTER) by shxd.cx with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XFOLb-000NdM-Gh; Thu, 07 Aug 2014 07:07:15 -0700 From: To: "'Garrett Cooper'" , References: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> <1407453344.5935.3.camel@bruno> In-Reply-To: Subject: RE: loader lszfs command Date: Thu, 7 Aug 2014 16:42:42 -0700 Message-ID: <095501cfb299$4872b090$d95811b0$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHPg+tqnJ9d5aGmqEBT91hvjPRKGwFTa5sIAYo63+Cbrzy8AA== Content-Language: en-us Sender: devin@shxd.cx Cc: dteske@freebsd.org, 'freebsd-current' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 23:42:44 -0000 > -----Original Message----- > From: Garrett Cooper [mailto:yaneurabeya@gmail.com] > Sent: Thursday, August 7, 2014 4:29 PM > To: sbruno@freebsd.org > Cc: dteske@freebsd.org; freebsd-current > Subject: Re: loader lszfs command >=20 > Hi Devin! >=20 > On Thu, Aug 7, 2014 at 4:15 PM, Sean Bruno > wrote: > > On Thu, 2014-08-07 at 14:17 -0700, dteske@FreeBSD.org wrote: > >> Hi, > >> > >> People have been pestering me to update the Forth code to present > >> a menu of ZFS datasets (*cough* boot environments *cough*). > >> > >> Would love to, but existing code seems broken. > >> > >> Can *anybody* produce meaningful output from the following? > >> > >> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D241284 > >> > >> All I get on every system I've tried (multiple versions, including = HEAD) > >> produce the following: > >> > >> OK lszfs zroot > >> ZFS: i/o error - all block copies unavailable > >> operation not permitted > >> > >> It's really hard for me to start with something that's broken. Can > >> I get confirmation that this doesn't appear to be working as = intended? > >> If so, I'll go ahead and try to fix it, but need to confirm that = I'm ( a ) > >> not > >> crazy and ( b ) seeing the same thing everybody else is seeing. > > > > > > Hrm ... this seems to work for me. (fairly recent 11-current) > > > > OK lszfs zroot > > $MOS > > $FREE > > $ORIGIN > > tmp > > home > > usr > > var > > tftpboot > > poudriere > > OK >=20 > Is the installed version you have in synch with the kernel and > zpool version for boot0, gptzfsboot, etc? Not sure how the kernel factors into all this, but I have a 10.0-RC1 system. Some info: devin@scribe10 ~ $ uname -a FreeBSD scribe10 10.0-RC1 FreeBSD 10.0-RC1 #0 r259068: Sat Dec 7 = 17:45:20 UTC 2013 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC = amd64 devin@scribe10 ~ $ zpool get version NAME PROPERTY VALUE SOURCE bootpool version - default zroot version - default devin@scribe10 ~ $ zfs get version NAME PROPERTY VALUE SOURCE bootpool version 5 - zroot version 5 - zroot/ROOT version 5 - zroot/ROOT/default version 5 - zroot/ROOT/default@2014-08-04-19:38:24 version 5 - zroot/ROOT/test version 5 - zroot/tmp version 5 - zroot/usr version 5 - zroot/usr/home version 5 - zroot/usr/ports version 5 - zroot/usr/ports.RELEASE_9_1_0 version 5 - zroot/var version 5 - zroot/var/crash version 5 - zroot/var/log version 5 - zroot/var/mail version 5 - zroot/var/tmp version 5 - Maybe if I update boot0 to a HEAD copy maybe? Have already tried updating /boot/loader with no change. --=20 Devin From owner-freebsd-current@FreeBSD.ORG Thu Aug 7 23:51:50 2014 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 ESMTPS id 78E8DC0C; Thu, 7 Aug 2014 23:51:50 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 54B312921; Thu, 7 Aug 2014 23:51:50 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id A5068FA7; Thu, 7 Aug 2014 16:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1407455509; bh=ka0ghV9Qt6hc8beJpmIXlV3c/XszYL0vgXs9vu0e6C4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=P9to2uORvYqhZivmJhpABLBOw4A9ItCK/b14OMQL5AvSjEDztXG0U44gerxNkrwWw l8F/sMmhDX2KiuFuWuAXtKZfePuvDCyoINFl4Aa4QD0k4dOPT0o3t3hT+jjyD/E3Hj ERQXy8Xk4cAGhepE/WoTdbX2PJ6eCekeY6QP0oWE= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: loader lszfs command Date: Thu, 07 Aug 2014 16:51:45 -0700 Message-ID: <4011758.e2ejrZofOE@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <095501cfb299$4872b090$d95811b0$@FreeBSD.org> References: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> <095501cfb299$4872b090$d95811b0$@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10429256.VlLpqVZcUC"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: dteske@freebsd.org, 'Garrett Cooper' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 07 Aug 2014 23:51:50 -0000 --nextPart10429256.VlLpqVZcUC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Thursday 07 August 2014 16:42:42 dteske@FreeBSD.org wrote: > Maybe if I update boot0 to a HEAD copy maybe? > Have already tried updating /boot/loader with no change. =2Dr-xr-xr-x 1 root wheel 262144 Aug 1 12:24 /boot/loader* =2Dr-xr-xr-x 1 root wheel 299008 Aug 1 12:24 /boot/zfsloader* It sounds like something is wrong with your install. BTW; boot0 isn't involved - if you've got that far, boot0 / gptzfsboot = have=20 already done their part. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart10429256.VlLpqVZcUC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJT5BEVAAoJEDXWlwnsgJ4EJFYH/3lc+2slHwFUOG2HSMaEBqa+ PU4L4UFD+U090HmI9UPIIFvOEtWBTO7jcMMYthYUCpTGZr9LOsUDDa/96qdXJ9nu i0lwv7cwHhppXD1yceIBf5JJyXLqbJx4DwtwzS4CbncZfBclGCx5a57mOQQ1AywF 4P8hEhwgU+9Z+V7aavgltQnIfYLaZnZxN5xiyjnYWZ01ooRZszkDnkd+989f5phg O0ltWDiG5Sl+z41lwQnrgaz8krweIzZ2kNJNnIt4A/0dcv1oqBhGA6yr0pGgfwbD Cgdo3YyFTGzebNewccRZG5SngIZOy70mX7XpbRr4TnZgdL4LtWc8+58NxkNsWwc= =+ceJ -----END PGP SIGNATURE----- --nextPart10429256.VlLpqVZcUC-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 00:10:20 2014 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 ESMTPS id F3650F49; Fri, 8 Aug 2014 00:10:19 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B11B52A73; Fri, 8 Aug 2014 00:10:19 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id h15so223022igd.11 for ; Thu, 07 Aug 2014 17:10:19 -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=taJOnmD9gLOTY3y4B3RvPFInIH61QtyB2PIPqtYh6HE=; b=WzGr66KpMa+8ge8bYNI76UOJmqr3+10bMVTK0qNrLLiCxjlERz+L89MW7fb+D1KRHz /sjIzC3BoVwZ4feMTjYigSPKrDxdXqARVtblCDEwa+qBIDZbWjdgVuLOlGDxwEp59DEQ BHQlDQ3kG5hVlnb9Z7loTwPvfbqIOLCqVjjKrDD0+9UfOVaTd8AehXkaUf88dgO0/yt4 3DGJid815ZS6RKt8X6IhCzVNWzdEbJihiC0A5WGyLA0b6q6KHXmmXPqmyw3Vo5RzqLyp u7+phvjED7Pcjpw3pKUlM759bdSyyJf7iWkhj0uXIRef22Nn8Gcn0Aah+qcNPLt88qv8 /vfA== MIME-Version: 1.0 X-Received: by 10.42.68.66 with SMTP id w2mr7981922ici.74.1407456618954; Thu, 07 Aug 2014 17:10:18 -0700 (PDT) Received: by 10.50.76.229 with HTTP; Thu, 7 Aug 2014 17:10:18 -0700 (PDT) In-Reply-To: <095501cfb299$4872b090$d95811b0$@FreeBSD.org> References: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> <1407453344.5935.3.camel@bruno> <095501cfb299$4872b090$d95811b0$@FreeBSD.org> Date: Thu, 7 Aug 2014 17:10:18 -0700 Message-ID: Subject: Re: loader lszfs command From: Garrett Cooper To: dteske@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 00:10:20 -0000 On Thu, Aug 7, 2014 at 4:42 PM, wrote: > >> -----Original Message----- >> From: Garrett Cooper [mailto:yaneurabeya@gmail.com] >> Sent: Thursday, August 7, 2014 4:29 PM >> To: sbruno@freebsd.org >> Cc: dteske@freebsd.org; freebsd-current >> Subject: Re: loader lszfs command >> >> Hi Devin! >> >> On Thu, Aug 7, 2014 at 4:15 PM, Sean Bruno >> wrote: >> > On Thu, 2014-08-07 at 14:17 -0700, dteske@FreeBSD.org wrote: >> >> Hi, >> >> >> >> People have been pestering me to update the Forth code to present >> >> a menu of ZFS datasets (*cough* boot environments *cough*). >> >> >> >> Would love to, but existing code seems broken. >> >> >> >> Can *anybody* produce meaningful output from the following? >> >> >> >> http://svnweb.freebsd.org/base?view=revision&revision=241284 >> >> >> >> All I get on every system I've tried (multiple versions, including HEAD) >> >> produce the following: >> >> >> >> OK lszfs zroot >> >> ZFS: i/o error - all block copies unavailable >> >> operation not permitted >> >> >> >> It's really hard for me to start with something that's broken. Can >> >> I get confirmation that this doesn't appear to be working as intended? >> >> If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a ) >> >> not >> >> crazy and ( b ) seeing the same thing everybody else is seeing. >> > >> > >> > Hrm ... this seems to work for me. (fairly recent 11-current) >> > >> > OK lszfs zroot >> > $MOS >> > $FREE >> > $ORIGIN >> > tmp >> > home >> > usr >> > var >> > tftpboot >> > poudriere >> > OK >> >> Is the installed version you have in synch with the kernel and >> zpool version for boot0, gptzfsboot, etc? > > Not sure how the kernel factors into all this, but I have a > 10.0-RC1 system. I was asking for information to help determine whether or not the loader could read the zpool metadata, because it's interesting why things worked for Sean and not for you :). Cheers! -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 05:28:13 2014 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 ESMTPS id ABFD0AD1 for ; Fri, 8 Aug 2014 05:28:13 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E36F2B17 for ; Fri, 8 Aug 2014 05:28:13 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s785S7F2077591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 08:28:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s785S7F2077591 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s785S7ET077590; Fri, 8 Aug 2014 08:28:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Aug 2014 08:28:07 +0300 From: Konstantin Belousov To: "Ivan A. Kosarev" Subject: Re: libthr and main thread stack size Message-ID: <20140808052807.GB93733@kib.kiev.ua> References: <53E36E84.4060806@ivan-labs.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rvoHLDQQ7oYmoXsQ" Content-Disposition: inline In-Reply-To: <53E36E84.4060806@ivan-labs.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 05:28:13 -0000 --rvoHLDQQ7oYmoXsQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote: > Hello, >=20 > According to libthr's thr_init.c (the 9.2 version) init_main_thread()=20 > allocates s.c. "red zone" below the main stack in order to protect other= =20 > stacks. The size of the main stack is determined by the=20 > _thr_stack_initial variable that is declared extern though it doesn't=20 > seem it can be changed. The value of the variable is set to 4M on 64-bit= =20 > platforms which is obviously not sufficient for the most of real programs. >=20 > Can anyone please confirm that there is no way to increase the stack=20 > size for the main thread and thus any program linked against libthr has= =20 > only a few megabytes of stack memory for its main thread--whatever the=20 > system stack size (ulimit -s) is set to? Yes, there is no way to change the main thread stack clamping. Could you provide a reasonable use case for the 4MB stack ? Anyway, I somewhat sympathize to the idea to stop clamping the main thread stack, and to not reuse it for other threads stack carving. This also means that non-main threads stack allocator should stop tracking the explicit location for the stacks and rely on vm mmap(2) base selection instead. I do not know the motivations why the current scheme of stacks allocation was chosen. The changes do not look too involved. --rvoHLDQQ7oYmoXsQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT5F/nAAoJEJDCuSvBvK1B/28QAJ9sY74XKbI2LPGp0uycKSzX 0sztit6Ni/UhrX9YF1AdPI/4DYPcV6cuJIUqWrPMrQzhYeJLbC5qz2KvKiY8TsNB 4SsHoIRQlFSo36PQDp5xZwMoMnRhAigsRHMHN3B4vn1N7vggzTsCFo+Nym77ALlz Ui0rprqQKBmzUVxPBKX4RCs8+fcyETUI4oz49WI2M4afWN3W+psVyU8Okl7RIu8W N2V3gIE6aQPrpYESURzCxdxu0gZb9jXl2v1sR0L85pYgrjUuFr9vE646rbazpWzI UxxhQRLXTwEGcHvYku7aMUDePGDPOZp5zyt08ShHfAB6QTPSAxv0/jL0aoWg+7mf b51KhCyAyu3BFkA+1QO63X/40gtALL94a/aB3xH70XQdsTMtfTj9jkfNesfiD4kz nqRBxGv3khChfaTT+/Pv1y/o9G5ukaFwtAkG+sD11uJpY2n+rF+IydzoWEILmJ2X vhENZ+GdkCaPRnXxvjeEB2jJJgM4uOCp1w96ZAzbOwiUWaRMQhzcP2ZavEyS/Aiv UmI3BH8CSrt2a9Vspn8/UV+L+YbNghsmVKbwelQtKJd7gtFSSmI0m5dc5k0Cwois EFIjy3bMoBBV67lQ1RFHVzYqHFKAOV4+7u78EEawF9ZDoMAFWjBCX7zzOtES1opd ioBz1ROAnvFbTXyU0hBw =ZTfK -----END PGP SIGNATURE----- --rvoHLDQQ7oYmoXsQ-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 06:09:48 2014 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 ESMTPS id B17A8EA1; Fri, 8 Aug 2014 06:09:48 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 25BC82FFA; Fri, 8 Aug 2014 06:09:47 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id s7869fer071624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 08:09:41 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id s7869fCL071621; Fri, 8 Aug 2014 08:09:41 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Fri, 8 Aug 2014 08:09:41 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: dteske@FreeBSD.org Subject: Re: loader lszfs command In-Reply-To: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> Message-ID: References: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-current@freebsd.org, avg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 06:09:48 -0000 On Thu, 7 Aug 2014 14:17-0700, dteske@FreeBSD.org wrote: > Hi, > > People have been pestering me to update the Forth code to present > a menu of ZFS datasets (*cough* boot environments *cough*). > > Would love to, but existing code seems broken. > > Can *anybody* produce meaningful output from the following? > > http://svnweb.freebsd.org/base?view=revision&revision=241284 > > All I get on every system I've tried (multiple versions, including HEAD) > produce the following: > > OK lszfs zroot > ZFS: i/o error - all block copies unavailable > operation not permitted > > It's really hard for me to start with something that's broken. Can > I get confirmation that this doesn't appear to be working as intended? > If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a ) > not > crazy and ( b ) seeing the same thing everybody else is seeing. A bit on the side, but more user friendly: You should change the error message on line 335 to explain how to use lszfs, or add a "help lszfs" command. Instead of merely complaining about "wrong number of arguments", how about stating something like "wrong number of arguments, need at least pool name"? -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestl, | Trond Endrestl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 08:33:05 2014 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 ESMTPS id 20763259 for ; Fri, 8 Aug 2014 08:33:05 +0000 (UTC) Received: from ivan-labs.com (ivan-labs.com [162.243.251.239]) by mx1.freebsd.org (Postfix) with ESMTP id EC433207C for ; Fri, 8 Aug 2014 08:33:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ivan-labs.com (Postfix) with ESMTP id B043F12083C; Fri, 8 Aug 2014 12:33:03 +0400 (MSK) X-Virus-Scanned: Debian amavisd-new at Received: from ivan-labs.com ([127.0.0.1]) by localhost (ivan-labs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dGxtUaYk+Rw; Fri, 8 Aug 2014 12:33:03 +0400 (MSK) Received: from [192.168.43.253] (host-63-159-66-217.spbmts.ru [217.66.159.63]) by ivan-labs.com (Postfix) with ESMTPSA id B185A120056; Fri, 8 Aug 2014 12:33:02 +0400 (MSK) Message-ID: <53E48B38.9010607@ivan-labs.com> Date: Fri, 08 Aug 2014 12:32:56 +0400 From: "Ivan A. Kosarev" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: libthr and main thread stack size References: <53E36E84.4060806@ivan-labs.com> <20140808052807.GB93733@kib.kiev.ua> In-Reply-To: <20140808052807.GB93733@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 08:33:05 -0000 On 08/08/2014 09:28 AM, Konstantin Belousov wrote: > On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote: >> Hello, >> >> According to libthr's thr_init.c (the 9.2 version) init_main_thread() >> allocates s.c. "red zone" below the main stack in order to protect other >> stacks. The size of the main stack is determined by the >> _thr_stack_initial variable that is declared extern though it doesn't >> seem it can be changed. The value of the variable is set to 4M on 64-bit >> platforms which is obviously not sufficient for the most of real programs. >> >> Can anyone please confirm that there is no way to increase the stack >> size for the main thread and thus any program linked against libthr has >> only a few megabytes of stack memory for its main thread--whatever the >> system stack size (ulimit -s) is set to? > Yes, there is no way to change the main thread stack clamping. > Could you provide a reasonable use case for the 4MB stack ? Traversing trees with recursive functions or on-stack grammar parsers? > > Anyway, I somewhat sympathize to the idea to stop clamping the main > thread stack, and to not reuse it for other threads stack carving. > This also means that non-main threads stack allocator should stop > tracking the explicit location for the stacks and rely on vm mmap(2) > base selection instead. Yes, that would solve the problem. > I do not know the motivations why the current scheme of stacks allocation > was chosen. The changes do not look too involved. Thanks a lot. -- From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 11:22:07 2014 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 ESMTPS id 83B70810 for ; Fri, 8 Aug 2014 11:22:07 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22A66247E for ; Fri, 8 Aug 2014 11:22:06 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s78BM1rd057915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 14:22:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s78BM1rd057915 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s78BM11I057914; Fri, 8 Aug 2014 14:22:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Aug 2014 14:22:01 +0300 From: Konstantin Belousov To: "Ivan A. Kosarev" Subject: Re: libthr and main thread stack size Message-ID: <20140808112201.GC93733@kib.kiev.ua> References: <53E36E84.4060806@ivan-labs.com> <20140808052807.GB93733@kib.kiev.ua> <53E48B38.9010607@ivan-labs.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S7dBYt2qcX9qS6Ih" Content-Disposition: inline In-Reply-To: <53E48B38.9010607@ivan-labs.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 11:22:07 -0000 --S7dBYt2qcX9qS6Ih Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 08, 2014 at 12:32:56PM +0400, Ivan A. Kosarev wrote: >=20 > On 08/08/2014 09:28 AM, Konstantin Belousov wrote: > > On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote: > >> Hello, > >> > >> According to libthr's thr_init.c (the 9.2 version) init_main_thread() > >> allocates s.c. "red zone" below the main stack in order to protect oth= er > >> stacks. The size of the main stack is determined by the > >> _thr_stack_initial variable that is declared extern though it doesn't > >> seem it can be changed. The value of the variable is set to 4M on 64-b= it > >> platforms which is obviously not sufficient for the most of real progr= ams. > >> > >> Can anyone please confirm that there is no way to increase the stack > >> size for the main thread and thus any program linked against libthr has > >> only a few megabytes of stack memory for its main thread--whatever the > >> system stack size (ulimit -s) is set to? > > Yes, there is no way to change the main thread stack clamping. > > Could you provide a reasonable use case for the 4MB stack ? >=20 > Traversing trees with recursive functions or on-stack grammar parsers? >=20 > > > > Anyway, I somewhat sympathize to the idea to stop clamping the main > > thread stack, and to not reuse it for other threads stack carving. > > This also means that non-main threads stack allocator should stop > > tracking the explicit location for the stacks and rely on vm mmap(2) > > base selection instead. >=20 > Yes, that would solve the problem. >=20 > > I do not know the motivations why the current scheme of stacks allocati= on > > was chosen. The changes do not look too involved. In fact, I can resonably explain the current behaviour. The motivation seems to come from desire to interpret the RLIMIT_STACK as the global limit to the stack usage by all threads. From this PoV, it becomes clean why the other thread stacks are carved from the main stack. Of course, it does not quite work this way, because there is no check that we did not overflowed from the main stack area. >=20 > Thanks a lot. >=20 Below is the patch which adds environment variable LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the main thread stack left as is, and other threads allocate stack below the area of RLIMIT_STACK. Try it. I do not want to set this behaviour as default. diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c index 937d83f..9bf0e29 100644 --- a/lib/libthr/thread/thr_init.c +++ b/lib/libthr/thread/thr_init.c @@ -37,6 +37,7 @@ #include #include #include +#include #include #include #include @@ -441,6 +442,7 @@ init_main_thread(struct pthread *thread) static void init_private(void) { + struct rlimit rlim; size_t len; int mib[2]; char *env; @@ -471,6 +473,12 @@ init_private(void) len =3D sizeof (_usrstack); if (sysctl(mib, 2, &_usrstack, &len, NULL, 0) =3D=3D -1) PANIC("Cannot get kern.usrstack from sysctl"); + env =3D getenv("LIBPTHREAD_BIGSTACK_MAIN"); + if (env !=3D NULL) { + if (getrlimit(RLIMIT_STACK, &rlim) =3D=3D -1) + PANIC("Cannot get stack rlimit"); + _thr_stack_initial =3D rlim.rlim_cur; + } len =3D sizeof(_thr_is_smp); sysctlbyname("kern.smp.cpus", &_thr_is_smp, &len, NULL, 0); _thr_is_smp =3D (_thr_is_smp > 1); diff --git a/lib/libthr/thread/thr_stack.c b/lib/libthr/thread/thr_stack.c index 15a9c82..e5d149e 100644 --- a/lib/libthr/thread/thr_stack.c +++ b/lib/libthr/thread/thr_stack.c @@ -246,7 +246,10 @@ _thr_stack_alloc(struct pthread_attr *attr) THREAD_LIST_UNLOCK(curthread); } else { - /* Allocate a stack from usrstack. */ + /* + * Allocate a stack from or below usrstack, depending + * on the LIBPTHREAD_BIGSTACK_MAIN env variable. + */ if (last_stack =3D=3D NULL) last_stack =3D _usrstack - _thr_stack_initial - _thr_guard_default; @@ -268,7 +271,7 @@ _thr_stack_alloc(struct pthread_attr *attr) =20 /* Map the stack and guard page together, and split guard page from allocated space: */ - if ((stackaddr =3D mmap(stackaddr, stacksize+guardsize, + if ((stackaddr =3D mmap(stackaddr, stacksize + guardsize, _rtld_get_stack_prot(), MAP_STACK, -1, 0)) !=3D MAP_FAILED && (guardsize =3D=3D 0 || --S7dBYt2qcX9qS6Ih Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT5LLYAAoJEJDCuSvBvK1BYLEP/2FBbRhmS3++NiwcdGMeTSNR Y5wwAqMg0jP1uOaqUyoB4ee0LfizdGm1ihEz32LABPk8jPMzEdTHeUnoeqxWDN1G /goxKuZK+VjI9DfaqSLxKOob5/GlgCbZY0cqiKnriXsf2i5sQJN6EIN4YBzoxX2M VMj06wRVQvaLnNRAu3qmGh2IeZcJs2neiBfi6iuv3OU4tIF/Uh9c3h0DBNzkSvvB 2ad3gHU8JHPvX4+L5qy4hFsPAoqEA9HeGViXmugSgIIPaVN5H4yiebX51QvJb5Cu KpTll/8pBB1WwQ5YROgrRBgf2pZDSXQPGtIg7GVjJd9yLqfrOPJouwyfQj6WlFH0 rgbj3q9MZMdX6HZwfZ7cWr+aS2uHujwA6fMDLPP47qz8ulfxOR3Mk03ly2WrI20d aW71MfQ9Zq2YNsQ2M/cWrt2YzcF6twdmSw5iRKYRVlbjmQiGLeNlBxbB2xoUvyQL FO5jWXkD3xjPch1TS7c91w60JSiD3/NDiw1zgRcnSePnD9roZXnkbPIm77Z0g9Fs cdmVw8vxTkw6gglrm2hINbGOCQuX2vYhGS7DL4E1Q1+/M8Oel+CS1BLaoIOJFZwZ i2+RdZBEbpJoHzZIlx/NKslXyoh98ZMiOndW0Ya5HGxy+1QHRyEeY0OUzoXK/8Qk jovMXS+iJ6kM/KCE62zo =89Ms -----END PGP SIGNATURE----- --S7dBYt2qcX9qS6Ih-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 11:46:57 2014 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 ESMTPS id C0E60188; Fri, 8 Aug 2014 11:46:57 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63210265F; Fri, 8 Aug 2014 11:46:57 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s78BkpoZ063573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 14:46:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s78BkpoZ063573 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s78BkocE063571; Fri, 8 Aug 2014 14:46:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Aug 2014 14:46:50 +0300 From: Konstantin Belousov To: Peter Holm Subject: Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() Message-ID: <20140808114650.GD93733@kib.kiev.ua> References: <53E1975D.4010703@FreeBSD.org> <20140806031932.GE93733@kib.kiev.ua> <53E1A76A.1070400@FreeBSD.org> <53E26A6C.4000806@FreeBSD.org> <20140806181512.GK93733@kib.kiev.ua> <20140807061111.GA6625@x2.osted.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qK4iY2XH8GKezezA" Content-Disposition: inline In-Reply-To: <20140807061111.GA6625@x2.osted.lan> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: current@freebsd.org, Bryan Drewery X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 11:46:57 -0000 --qK4iY2XH8GKezezA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 07, 2014 at 08:11:11AM +0200, Peter Holm wrote: > On Wed, Aug 06, 2014 at 09:15:12PM +0300, Konstantin Belousov wrote: > > On Wed, Aug 06, 2014 at 12:48:28PM -0500, Bryan Drewery wrote: > > > On 8/5/2014 10:56 PM, Bryan Drewery wrote: > > > > On 8/5/2014 10:19 PM, Konstantin Belousov wrote: > > > >> On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: > > > >>> Has anyone else encountered this? Got it while running poudriere. > > > >>> > > > >>>> NULL mp in getnewvnode() > > > >>>> [...] > > > >>>> vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247d8e540 > > > >>>> vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247d8e590 > > > >>>> export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247d8e= 7c0 > > > >>>> kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > > > >>>> 0xfffffe1247d8e840 > > > >>>> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/fr= ame > > > >>>> 0xfffffe1247d8e900 > > > >>>> sysctl_root_handler_locked() at > > > >>>> sysctl_root_handler_locked+0x68/frame 0xfffffe1247d8e940 > > > >>>> sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247d8e990 > > > >>>> userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247d8e= a30 > > > >>>> sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247d8eae0 > > > >>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d8ebf0 > > > >>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d8ebf0 > > > >>> > > > >>> Unfortunately I have no dump as the kmem was too large compared t= o my > > > >>> swap, and I didn't get to the console before some of the text was > > > >>> overwritten. Perhaps it will hit it again soon after reboot and I= 'll get > > > >>> a core. > > > >> > > > >> "NULL mp in getnewvnode()" is only the printf(), it is not a panic= or > > > >> KASSERT. The event does not stop the machine, nor it prints the > > > >> backtrace. > > > >> > > > >> You mentioned that you was unable to dump, so did the system panic= ed ? > > > >> Without full log of the panic messages and backtrace, it is imposs= ible > > > >> to start guessing what the problem is. > > > >> > > > >> That said, the printf seemingly outlived its usefulness. > > > >> > > > >=20 > > > > Got it. I've set debug.debugger_on_panic=3D1 to not auto reboot on = panic > > > > next time this happens. I had it at 0 which was causing the lack of > > > > information in these. > > >=20 > > > Here is the full trace: > > >=20 > > >=20 > > > > NULL mp in getnewvnode() > > > > VNASSERT failed > > > > 0xfffff806071dc760: tag null, type VDIR > > > > usecount 1, writecount 0, refcount 1 mountedhere 0 > > > > flags () > > > > lock type zfs: EXCL by thread 0xfffff8009a53f490 (pid 1028, tmu= x, tid 100881) > > > > vp=3D0xfffff806071dc760, lowervp=3D0xfffff8013157f588 > > > > panic: Don't call insmntque(foo, NULL) > > > > cpuid =3D 5 > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffff= e1247e76b50 > > > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247e76c00 > > > > vpanic() at vpanic+0x126/frame 0xfffffe1247e76c40 > > > > kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247e76cb0 > > > > insmntque1() at insmntque1+0x230/frame 0xfffffe1247e76cf0 > > > > null_nodeget() at null_nodeget+0x158/frame 0xfffffe1247e76d60 > > > > null_lookup() at null_lookup+0xeb/frame 0xfffffe1247e76dd0 > > > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfffffe1247e76e00 > > > > lookup() at lookup+0x5ad/frame 0xfffffe1247e76e90 > > > > namei() at namei+0x4e4/frame 0xfffffe1247e76f50 > > > > vn_open_cred() at vn_open_cred+0x27a/frame 0xfffffe1247e770a0 > > > > vop_stdvptocnp() at vop_stdvptocnp+0x161/frame 0xfffffe1247e773e0 > > > > null_vptocnp() at null_vptocnp+0x2b/frame 0xfffffe1247e77440 > > > > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf7/frame 0xfffffe1247e77470 > > > > vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfffffe1247e7= 74e0 > > > > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247e77540 > > > > vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247e77590 > > > > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247e777c0 > > > > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xff= fffe1247e77840 > > > > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame= 0xfffffe1247e77900 > > > > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/fra= me 0xfffffe1247e77940 > > > > sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247e77990 > > > > userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247e77a30 > > > > sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247e77ae0 > > > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247e77bf0 > > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247e77bf0 > > > > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip =3D 0x801041fca= , rsp =3D 0x7fffffffd878, rbp =3D 0x7fffffffd8b0 --- > > > > KDB: enter: panic > > > > [ thread pid 1028 tid 100881 ] > > > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > > > db> call doadump() > > > >=20 > > > > Dump failed. Partition too small. > > > > =3D 0 > > >=20 > >=20 > > Try this. > >=20 > > diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c > > index 481644c..e803c24 100644 > > --- a/sys/fs/nullfs/null_vnops.c >=20 > With this patch I get a=20 > panic: Lock (lockmgr) null not locked @ kern/vfs_default.c:523. >=20 > Details @ http://people.freebsd.org/~pho/stress/log/kostik698.txt >=20 Peter tested the updated version of the patch, which fixed both issues in his setup. I committed this variant of the fix as r269708. --qK4iY2XH8GKezezA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT5LiqAAoJEJDCuSvBvK1BTS0QAIem66kaxmYx++vC1YNzdH8w ZvaHGpGtmvXr4mCqdZVGJVveP1jSabcOufpD6PgI6hMBENy0Q31nkeq0bpE4fJll 4BVI0Q9mLhvaKiG4eoLIkjwzVE1YxGMGBfePp9fsZ8Ch8MTvkzcKBlZYAiTn+J3x WqhOSAjFNu1lpILc7CQGTzzD5gIqrJQi75L0VYwxxs3nmVvaFMu+r4BJTu+xqy2i 0fPIBRbWy3wPR7R5af9WQ0O//FJvbREipOA76GS3P4XbD0CKj5mRawTvAUz1XdBn tVmN8N+OSMLlZBz0eDQHoVqFP8uqNDnJMSxb+94klPrV3E9WpS2OWW1k3vYkvqqc dOiSznvZ/EOmgGsFI7mXfJdvOUzeA+A2IV7JzBzSb0XCrjG2kQS3YqV8tfjqZrb8 SyHAJp+slUm+zMqs8TJX9E3a0dDpAJoFu7Gnfwa0wM8ubzbHgET+n0msje3aTjZv kVRqGyBZK/cq89By8hGy++D04jhU4pLGVDc4EBHMwhfek26RtUuoRcJLaw3JK6Vb jTtZGF5IhGJLPWEH4+x7bxUsVJqtuZFV9Raa55lcHfiwz2dX7KtmTw3aEujUD1Ga h3B1WqUpWwIL3VHgykOf2IRGes9xJsar14J1vJpylgylyLwfQITP0CJ3S2AFOj4j 8fhOAS+VoOM3ivHn8dRJ =k/XM -----END PGP SIGNATURE----- --qK4iY2XH8GKezezA-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 15:41:17 2014 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 ESMTPS id 93DFAFD9 for ; Fri, 8 Aug 2014 15:41:17 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77C842401 for ; Fri, 8 Aug 2014 15:41:17 +0000 (UTC) Received: from bdrewery (uid 1298) (envelope-from bdrewery@freebsd.org) id ffb by freefall.freebsd.org (DragonFly Mail Agent v0.9+); Fri, 08 Aug 2014 15:41:17 +0000 Received: (qmail 78171 invoked from network); 8 Aug 2014 10:41:15 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 8 Aug 2014 10:41:15 -0500 Message-ID: <53E4EF8B.9080008@FreeBSD.org> Date: Fri, 08 Aug 2014 10:40:59 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: current@freebsd.org Subject: Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() References: <53E1975D.4010703@FreeBSD.org> <20140806031932.GE93733@kib.kiev.ua> <53E1A76A.1070400@FreeBSD.org> <53E26A6C.4000806@FreeBSD.org> <20140806181512.GK93733@kib.kiev.ua> <20140807061111.GA6625@x2.osted.lan> <20140808114650.GD93733@kib.kiev.ua> In-Reply-To: <20140808114650.GD93733@kib.kiev.ua> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JNVt4XfNnWHI4s9KAmda7ctlpfiQv9HQ8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 15:41:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JNVt4XfNnWHI4s9KAmda7ctlpfiQv9HQ8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/8/2014 6:46 AM, Konstantin Belousov wrote: > On Thu, Aug 07, 2014 at 08:11:11AM +0200, Peter Holm wrote: >> On Wed, Aug 06, 2014 at 09:15:12PM +0300, Konstantin Belousov wrote: >>> On Wed, Aug 06, 2014 at 12:48:28PM -0500, Bryan Drewery wrote: >>>> On 8/5/2014 10:56 PM, Bryan Drewery wrote: >>>>> On 8/5/2014 10:19 PM, Konstantin Belousov wrote: >>>>>> On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: >>>>>>> Has anyone else encountered this? Got it while running poudriere.= >>>>>>> >>>>>>>> NULL mp in getnewvnode() >>>>>>>> [...] >>>>>>>> vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247d8e540 >>>>>>>> vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247d8e590 >>>>>>>> export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247d8e= 7c0 >>>>>>>> kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame >>>>>>>> 0xfffffe1247d8e840 >>>>>>>> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/fr= ame >>>>>>>> 0xfffffe1247d8e900 >>>>>>>> sysctl_root_handler_locked() at >>>>>>>> sysctl_root_handler_locked+0x68/frame 0xfffffe1247d8e940 >>>>>>>> sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247d8e990 >>>>>>>> userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247d8e= a30 >>>>>>>> sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247d8eae0 >>>>>>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d8ebf0 >>>>>>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d8ebf0 >>>>>>> >>>>>>> Unfortunately I have no dump as the kmem was too large compared t= o my >>>>>>> swap, and I didn't get to the console before some of the text was= >>>>>>> overwritten. Perhaps it will hit it again soon after reboot and I= 'll get >>>>>>> a core. >>>>>> >>>>>> "NULL mp in getnewvnode()" is only the printf(), it is not a panic= or >>>>>> KASSERT. The event does not stop the machine, nor it prints the >>>>>> backtrace. >>>>>> >>>>>> You mentioned that you was unable to dump, so did the system panic= ed ? >>>>>> Without full log of the panic messages and backtrace, it is imposs= ible >>>>>> to start guessing what the problem is. >>>>>> >>>>>> That said, the printf seemingly outlived its usefulness. >>>>>> >>>>> >>>>> Got it. I've set debug.debugger_on_panic=3D1 to not auto reboot on = panic >>>>> next time this happens. I had it at 0 which was causing the lack of= >>>>> information in these. >>>> >>>> Here is the full trace: >>>> >>>> >>>>> NULL mp in getnewvnode() >>>>> VNASSERT failed >>>>> 0xfffff806071dc760: tag null, type VDIR >>>>> usecount 1, writecount 0, refcount 1 mountedhere 0 >>>>> flags () >>>>> lock type zfs: EXCL by thread 0xfffff8009a53f490 (pid 1028, tmu= x, tid 100881) >>>>> vp=3D0xfffff806071dc760, lowervp=3D0xfffff8013157f588 >>>>> panic: Don't call insmntque(foo, NULL) >>>>> cpuid =3D 5 >>>>> KDB: stack backtrace: >>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffff= e1247e76b50 >>>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247e76c00 >>>>> vpanic() at vpanic+0x126/frame 0xfffffe1247e76c40 >>>>> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247e76cb0 >>>>> insmntque1() at insmntque1+0x230/frame 0xfffffe1247e76cf0 >>>>> null_nodeget() at null_nodeget+0x158/frame 0xfffffe1247e76d60 >>>>> null_lookup() at null_lookup+0xeb/frame 0xfffffe1247e76dd0 >>>>> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfffffe1247e76e00 >>>>> lookup() at lookup+0x5ad/frame 0xfffffe1247e76e90 >>>>> namei() at namei+0x4e4/frame 0xfffffe1247e76f50 >>>>> vn_open_cred() at vn_open_cred+0x27a/frame 0xfffffe1247e770a0 >>>>> vop_stdvptocnp() at vop_stdvptocnp+0x161/frame 0xfffffe1247e773e0 >>>>> null_vptocnp() at null_vptocnp+0x2b/frame 0xfffffe1247e77440 >>>>> VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf7/frame 0xfffffe1247e77470 >>>>> vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfffffe1247e7= 74e0 >>>>> vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247e77540 >>>>> vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247e77590 >>>>> export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247e777c0= >>>>> kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xff= fffe1247e77840 >>>>> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame= 0xfffffe1247e77900 >>>>> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/fra= me 0xfffffe1247e77940 >>>>> sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247e77990 >>>>> userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247e77a30= >>>>> sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247e77ae0 >>>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247e77bf0 >>>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247e77bf0 >>>>> --- syscall (202, FreeBSD ELF64, sys___sysctl), rip =3D 0x801041fca= , rsp =3D 0x7fffffffd878, rbp =3D 0x7fffffffd8b0 --- >>>>> KDB: enter: panic >>>>> [ thread pid 1028 tid 100881 ] >>>>> Stopped at kdb_enter+0x3e: movq $0,kdb_why >>>>> db> call doadump() >>>>> >>>>> Dump failed. Partition too small. >>>>> =3D 0 >>>> >>> >>> Try this. >>> >>> diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c >>> index 481644c..e803c24 100644 >>> --- a/sys/fs/nullfs/null_vnops.c >> >> With this patch I get a=20 >> panic: Lock (lockmgr) null not locked @ kern/vfs_default.c:523. >> >> Details @ http://people.freebsd.org/~pho/stress/log/kostik698.txt >> >=20 > Peter tested the updated version of the patch, which fixed both issues > in his setup. I committed this variant of the fix as r269708. >=20 Thanks! I had been running it for a few days and not hit any issues. --=20 Regards, Bryan Drewery --JNVt4XfNnWHI4s9KAmda7ctlpfiQv9HQ8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT5O+PAAoJEDXXcbtuRpfPwJIH/3nON2mSXN6yrATMRw67yuqo a1uy5HvfZ7ZceK22/I+mfjvl/QmgYMrKDFianeb3uyI1iZDRXHKc4G5NG3tgfI7N /clqrMZ4uyzxcQbcXZlF2fbv5rZc++9CBBmxvhdIzx6M227G57C7C7EEdqJHsJ0D 6bbsUZTFPGgvUd7b9UBI/5SpzWDtVsJt9wM2UWrtsrGCHR2Gm9UW2fwM9mZszjPT 5Q9HYGeJcTtP3r2yw50A/7MQ4jHjI80N3Sa2iRVt8KHzZgqRes7Y3eYOg9Xlrsr8 nPqEqQHvSoTiN01NN6aDqbZFBg4mpwr09+J3RdOWmiqMwCqHw8/r5XomIDUgciA= =K8i0 -----END PGP SIGNATURE----- --JNVt4XfNnWHI4s9KAmda7ctlpfiQv9HQ8-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 16:46:50 2014 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 ESMTPS id DB2BD5A0; Fri, 8 Aug 2014 16:46:50 +0000 (UTC) Received: from sh4-5.1blu.de (sh4-5.1blu.de [178.254.11.41]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2F6A2B09; Fri, 8 Aug 2014 16:46:50 +0000 (UTC) Received: from ftp51246-2575596 by sh4-5.1blu.de with local (Exim 4.76) (envelope-from ) id 1XFnJQ-0004RR-Ss; Fri, 08 Aug 2014 18:46:40 +0200 Date: Fri, 8 Aug 2014 18:46:40 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: poudriere: setting up jail failes Message-ID: <20140808164640.GA14611@sh4-5.1blu.de> Reply-To: Matthias Apitz MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Operating-System: FreeBSD 7.0-RELEASE (i386) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 16:46:50 -0000 Hello, I'm setting up a jail with poudriere(8) to compile my ports; after some hours it is crashing with: # poudriere jail -c -j freebsd-head -m svn+http -v head ; date =2E.. >>> Making hierarchy -------------------------------------------------------------- cd /usr/local/poudriere/jails/freebsd-head/usr/src; make -f Makefile.inc1 LOCAL_MTREE=3D hierarchy cd /usr/local/poudriere/jails/freebsd-head/usr/src/etc && PATH=3D/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/u= sr/sbin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/= usr/bin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/= usr/games:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legac= y/bin:/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/sbin:= /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/bin:/usr/ob= j/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/games:/usr/obj/usr= /local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/sbin:/usr/obj/us= r/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/bin:/usr/obj/us= r/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/games:/usr/obj/= usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/bin:/usr/obj/usr/= local/poudriere/jails/freebsd-head/usr/src/tmp/usr/sbin:/usr/obj/usr/local/= poudriere/jails/freebsd-head/usr/src/tmp/usr/bin:/usr/obj/usr/local/poudrie= re/jails/freebsd-head/usr/src/tmp/usr/games:/tmp/install.l1aks4sC make LOCAL_MTREE=3D distrib-dirs mtree -N /usr/local/poudriere/jails/freebsd-head/usr/src/etc -deU -f /usr/local/poudriere/jails/freebsd-head/usr/src/etc/mtree/BSD.root.dist -p /usr/local/poudriere/jails/freebsd-head/ mtree: illegal option -- N usage: mtree [-LPUcdeinqruxw] [-f spec] [-f spec] [-K key] [-k key] [-p path] [-s seed] [-X excludes] *** Error code 1 Stop. make[4]: stopped in /usr/local/poudriere/jails/freebsd-head/usr/src/etc *** Error code 1 =2E.. make: stopped in /usr/local/poudriere/jails/freebsd-head/usr/src =3D=3D=3D=3D>> Error: Failed to 'make installworld' =3D=3D=3D=3D>> Error while creating jail, cleaning up. =3D=3D=3D=3D>> Removing freebsd-head jail... done The host where poudriere is running is: # uname -a FreeBSD vm-tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 12:10:57 CEST 2013 guru@aurora.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 i.e. a CURRENT from Oct 2013 (r255948). Does this mean I should update the host where poudriere is running before? Thanks matthias --=20 Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 18:44:06 2014 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 ESMTPS id 7C1136E8 for ; Fri, 8 Aug 2014 18:44:06 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 480792A06 for ; Fri, 8 Aug 2014 18:44:06 +0000 (UTC) Received: from bdrewery (uid 1298) (envelope-from bdrewery@freebsd.org) id 59 by freefall.freebsd.org (DragonFly Mail Agent v0.9+); Fri, 08 Aug 2014 18:44:06 +0000 Received: (qmail 46683 invoked from network); 8 Aug 2014 13:44:03 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 8 Aug 2014 13:44:03 -0500 Message-ID: <53E51A67.1020904@FreeBSD.org> Date: Fri, 08 Aug 2014 13:43:51 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Matthias Apitz , freebsd-current@freebsd.org Subject: Re: poudriere: setting up jail failes References: <20140808164640.GA14611@sh4-5.1blu.de> In-Reply-To: <20140808164640.GA14611@sh4-5.1blu.de> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u9ae1kJUg53NhP0RCK9CiUFLnGkBabuA2" Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 18:44:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u9ae1kJUg53NhP0RCK9CiUFLnGkBabuA2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/8/2014 11:46 AM, Matthias Apitz wrote: >=20 > Hello, >=20 > I'm setting up a jail with poudriere(8) to compile my ports; after some= > hours it is crashing with: >=20 > # poudriere jail -c -j freebsd-head -m svn+http -v head ; date [...] > mtree: illegal option -- N > usage: mtree [-LPUcdeinqruxw] [-f spec] [-f spec] [-K key] [-k key] [-p= > path] [-s seed] > [-X excludes] > *** Error code 1 [...] > The host where poudriere is running is: >=20 > # uname -a > FreeBSD vm-tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 > 12:10:57 CEST 2013 guru@aurora.Sisis.de:/usr/obj/usr/src/sys/GENERI= C > i386 >=20 > i.e. a CURRENT from Oct 2013 (r255948). Does this mean I should update > the host where poudriere is running before? Yes. For you it is fixed in stable/10 r257460 (which was in before 10.0 release) which added -N to mtree. There was a lot of polish at the end of 10.0 so you should probably upgrade to at least 10.0 either way. It could be that older releases building 10 and head for Poudriere may be an issue still. I'll have to test more. Specifically the call of 'make distrib-dirs DB_FROM_SRC=3D1' seemingly not using the itools versio= n of mtree. Also note that running a head jail on a 10.0 system is not really supported. You may run into many weird issues building packages. It's supported to have your host be newer than the jails but not the other way around. Regards, Bryan Drewery --u9ae1kJUg53NhP0RCK9CiUFLnGkBabuA2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT5RpnAAoJEDXXcbtuRpfPfRkH/Rcm23Uuwnu2lESgERYQIvY1 FXZiRbC02d1pm5HqQIJ70F/9oslk0L69RgMoJSEnkySJeZmVVOJE2hL0pz48CbF8 /DB91iPs8NCyFd4KkttMpEZwbpwojZ27c0eNogdEU1VhxO/kT6JcJ5PmmojV3ALF cEHmtCzh78My2IpXpiBiGsFtt6ufOAaGPcOaTA5wyDLLff8V1e9sieOZNNkGPPTi 2IqKkNIuqBbRcq751zNzlYKtsfbFtpr2bh8w2l8bpSjDJu/3hzqgtzRtzBn/fW/S u4rhoT8iEjNek9XRRSmVZ+KUM+0mQ/UZwyYQEPqaIXYMhVH/1DrktENfc8o0GVM= =33nA -----END PGP SIGNATURE----- --u9ae1kJUg53NhP0RCK9CiUFLnGkBabuA2-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 18:57:24 2014 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 ESMTPS id CEC55F7C; Fri, 8 Aug 2014 18:57:24 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8CF242B42; Fri, 8 Aug 2014 18:57:24 +0000 (UTC) Received: from [89.15.238.254] (helo=localhost.my.domain) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XFpLn-0000qF-BL; Fri, 08 Aug 2014 20:57:15 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id s78IvESk001349; Fri, 8 Aug 2014 20:57:14 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id s78IvDP3001348; Fri, 8 Aug 2014 20:57:13 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Fri, 8 Aug 2014 20:57:13 +0200 From: Matthias Apitz To: Kurt Jaeger , freebsd-current@freebsd.org Subject: Re: poudriere: setting up jail failes Message-ID: <20140808185713.GA1304@La-Habana> Reply-To: Matthias Apitz References: <20140808164640.GA14611@sh4-5.1blu.de> <20140808171215.GQ2644@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140808171215.GQ2644@home.opsec.eu> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.15.238.254 Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 18:57:25 -0000 El día Friday, August 08, 2014 a las 07:12:15PM +0200, Kurt Jaeger escribió: > Hi! > > > The host where poudriere is running is: > > > > # uname -a > > FreeBSD vm-tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 > > 12:10:57 CEST 2013 guru@aurora.Sisis.de:/usr/obj/usr/src/sys/GENERIC > > i386 > > > > i.e. a CURRENT from Oct 2013 (r255948). Does this mean I should update > > the host where poudriere is running before? > > Yes. Go for 10.0-REL p7, then retry. Can you explain, why? If one looks at the code which is executed in the jail, it looks like this (for better readability I have changed the colons ':' in the PATH by newlines): PATH=/usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/sbin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/games /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/sbin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/games /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/sbin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/usr/games /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/legacy/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/sbin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/bin /usr/obj/usr/local/poudriere/jails/freebsd-head/usr/src/tmp/usr/games /tmp/install.l1aks4sC make LOCAL_MTREE= distrib-dirs mtree -N /usr/local/poudriere/jails/freebsd-head/usr/src/etc -deU -f /usr/local/poudriere/jails/freebsd-head/usr/src/etc/mtree/BSD.root.dist -p /usr/local/poudriere/jails/freebsd-head/ mtree: illegal option -- N usage: mtree [-LPUcdeinqruxw] [-f spec] [-f spec] [-K key] [-k key] [-p path] [-s seed] [-X excludes] *** Error code 1 i.e. the tool 'mtree' is run from a hardcoded PATH from inside the jail which was just compiled. Why the 'mtree' from a Makefile in CURRENT is called with the -N flag, or why the 'mtree' from CURRENT does not understand the -N flag? I do not have a SVN checked out CURRENT to look into at the moment, but I think either the Makefile or mtree is broken in CURRENT. And, btw., why is poudriere removing all the jail when an error occures? Wouldn't it be better to let it there to have a look into and remove it on the next run? > > -- > 6 years to go ! 6 years to go to where or what? Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 19:12:03 2014 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 ESMTPS id 038E4C64; Fri, 8 Aug 2014 19:12:03 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B517C2E1D; Fri, 8 Aug 2014 19:12:02 +0000 (UTC) Received: from [89.15.238.254] (helo=localhost.my.domain) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XFpa4-0005rm-IB; Fri, 08 Aug 2014 21:12:01 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id s78JBvuD001411; Fri, 8 Aug 2014 21:11:57 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id s78JBvf4001410; Fri, 8 Aug 2014 21:11:57 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Fri, 8 Aug 2014 21:11:56 +0200 From: Matthias Apitz To: Bryan Drewery Subject: Re: poudriere: setting up jail failes Message-ID: <20140808191156.GA1386@La-Habana> Reply-To: Matthias Apitz References: <20140808164640.GA14611@sh4-5.1blu.de> <53E51A67.1020904@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53E51A67.1020904@FreeBSD.org> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.15.238.254 Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 19:12:03 -0000 El día Friday, August 08, 2014 a las 01:43:51PM -0500, Bryan Drewery escribió: > Yes. For you it is fixed in stable/10 r257460 (which was in before 10.0 > release) which added -N to mtree. There was a lot of polish at the end > of 10.0 so you should probably upgrade to at least 10.0 either way. > > It could be that older releases building 10 and head for Poudriere may > be an issue still. I'll have to test more. Specifically the call of > 'make distrib-dirs DB_FROM_SRC=1' seemingly not using the itools version > of mtree. This is perhaps the problem. > Also note that running a head jail on a 10.0 system is not really > supported. You may run into many weird issues building packages. It's > supported to have your host be newer than the jails but not the other > way around. Hmm? The poudriere has the '-m svn' flag for creating jails. If one uses this flag, the jail will always be newer than the host. If this is an issue (which I do not understand if things are done in a jail, using the toolchain of the jail) then this flag should be deleted from poudriere, IMHO. Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 19:11:24 2014 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 ESMTPS id 48027A9E; Fri, 8 Aug 2014 19:11:24 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02A9F2D72; Fri, 8 Aug 2014 19:11:24 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XFpZT-000NiH-GQ; Fri, 08 Aug 2014 21:11:23 +0200 Date: Fri, 8 Aug 2014 21:11:23 +0200 From: Kurt Jaeger To: Matthias Apitz Subject: Re: poudriere: setting up jail failes Message-ID: <20140808191123.GR2644@home.opsec.eu> References: <20140808164640.GA14611@sh4-5.1blu.de> <20140808171215.GQ2644@home.opsec.eu> <20140808185713.GA1304@La-Habana> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140808185713.GA1304@La-Habana> X-Mailman-Approved-At: Fri, 08 Aug 2014 19:19:55 +0000 Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 19:11:24 -0000 Hi! > > > i.e. a CURRENT from Oct 2013 (r255948). Does this mean I should update > > > the host where poudriere is running before? > > > > Yes. Go for 10.0-REL p7, then retry. > > Can you explain, why? bdrewery@ knows much more about it than I do 8-) I only know that it helps to use a recent system if one tries to debug issues 8-} And: It takes time for others to help if one tries to use some -ALPHA to do recent things... -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 19:24:32 2014 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 ESMTPS id 1DA3B1E9 for ; Fri, 8 Aug 2014 19:24:32 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F40862FFF for ; Fri, 8 Aug 2014 19:24:31 +0000 (UTC) Received: from bdrewery (uid 1298) (envelope-from bdrewery@freebsd.org) id 6a by freefall.freebsd.org (DragonFly Mail Agent v0.9+); Fri, 08 Aug 2014 19:24:31 +0000 Received: (qmail 22235 invoked from network); 8 Aug 2014 14:24:30 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 8 Aug 2014 14:24:30 -0500 Message-ID: <53E523E2.5000103@FreeBSD.org> Date: Fri, 08 Aug 2014 14:24:18 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Matthias Apitz Subject: Re: poudriere: setting up jail failes References: <20140808164640.GA14611@sh4-5.1blu.de> <53E51A67.1020904@FreeBSD.org> <20140808191156.GA1386@La-Habana> In-Reply-To: <20140808191156.GA1386@La-Habana> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CF8VR2Fj2QXIj12Q05bbPA8PU5EBxP4rU" Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 19:24:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CF8VR2Fj2QXIj12Q05bbPA8PU5EBxP4rU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/8/2014 2:11 PM, Matthias Apitz wrote: > El d=C3=ADa Friday, August 08, 2014 a las 01:43:51PM -0500, Bryan Drewe= ry escribi=C3=B3: >=20 >> Yes. For you it is fixed in stable/10 r257460 (which was in before 10.= 0 >> release) which added -N to mtree. There was a lot of polish at the end= >> of 10.0 so you should probably upgrade to at least 10.0 either way. >> >> It could be that older releases building 10 and head for Poudriere may= >> be an issue still. I'll have to test more. Specifically the call of >> 'make distrib-dirs DB_FROM_SRC=3D1' seemingly not using the itools ver= sion >> of mtree. >=20 > This is perhaps the problem. >=20 >> Also note that running a head jail on a 10.0 system is not really >> supported. You may run into many weird issues building packages. It's >> supported to have your host be newer than the jails but not the other >> way around. >=20 > Hmm? The poudriere has the '-m svn' flag for creating jails. If one use= s > this flag, the jail will always be newer than the host. If this is an > issue (which I do not understand if things are done in a jail, using th= e > toolchain of the jail) then this flag should be deleted from > poudriere, IMHO. >=20 > Thanks >=20 > matthias >=20 The use of -v head from a 10.0 system is the issue. Once you start a build poudriere yells loudly that it is not supported. Major release jumps are not supported. You can usually get away with a head host using a head jail that is a few weeks newer as long as KBI does not change. Doing major releases though can get into trouble with unknown syscalls and different sized structs and capabilities. FreeBSD only tries to be backwards-compatible with its interfaces (among major releases), not guaranteed to be forward or even backwards compatible with head from yesterday. --=20 Regards, Bryan Drewery --CF8VR2Fj2QXIj12Q05bbPA8PU5EBxP4rU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT5SPiAAoJEDXXcbtuRpfPQd8IAIvjK/N83822sJjRGykymbZo cLPMw4jShPrg/JKosO0KkB03dYv50p6Pj8+lfiwp97cRagp5FtQR/2+ToSFOALa5 XYQ++bBmgzuhQAHGJTkg69317wNbB6DqpuBl/DPDby9rGzGPIilaZ9/pMMg2aoBx VIecbKnjye5+aN196SBDbJQaFBrcclpQftzmU3Z/Esea53rhT43zS3jHPrkT4KHA 5c9qoLxXGRYma3iX+mD1rJLZnzlyjwrOyn3gWkS7U5CT3a8RyH4/uZhiWbem95AY w3nkV+TNNfqIETNb2eULOeSfiMdviY8HWSLXV34HsqaksSuYAY0pBHY9GMY495E= =Gtbf -----END PGP SIGNATURE----- --CF8VR2Fj2QXIj12Q05bbPA8PU5EBxP4rU-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 19:27:54 2014 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 ESMTPS id 7633256A for ; Fri, 8 Aug 2014 19:27:54 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43AED202E for ; Fri, 8 Aug 2014 19:27:54 +0000 (UTC) Received: from bdrewery (uid 1298) (envelope-from bdrewery@freebsd.org) id 71 by freefall.freebsd.org (DragonFly Mail Agent v0.9+); Fri, 08 Aug 2014 19:27:54 +0000 Received: (qmail 56979 invoked from network); 8 Aug 2014 14:27:52 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 8 Aug 2014 14:27:52 -0500 Message-ID: <53E524AC.6040402@FreeBSD.org> Date: Fri, 08 Aug 2014 14:27:40 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Matthias Apitz , freebsd-current@freebsd.org Subject: Re: poudriere: setting up jail failes References: <20140808164640.GA14611@sh4-5.1blu.de> <20140808171215.GQ2644@home.opsec.eu> <20140808185713.GA1304@La-Habana> In-Reply-To: <20140808185713.GA1304@La-Habana> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B4goiNw9eia64hiQQPlQRBELgQsJFSKUS" Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 19:27:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B4goiNw9eia64hiQQPlQRBELgQsJFSKUS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/8/2014 1:57 PM, Matthias Apitz wrote: > And, btw., why is poudriere removing all the jail when an error occures= ? > Wouldn't it be better to let it there to have a look into and remove it= > on the next run? Yes I agree this should probably change. I'll evaluate it after the 3.1 release which is the major focus right now. The jail command has a lot of issues with building and error handling. --=20 Regards, Bryan Drewery --B4goiNw9eia64hiQQPlQRBELgQsJFSKUS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT5SSsAAoJEDXXcbtuRpfP/AgH/RnjXHQoepdI67hvzwLmE7DM I4YjK5hzNLtQWYY90XPlyZxieVtRnX7q/OyS2sisfx3gO34sAm8XME38WIfX9MtM UqNVEZlip5TpJ9lt0HnB7+NnmgcPR+LntvYClPDL5H8Tpyxq5yBmGxppeLYNKxWj BW37asMin8e1z8jvWtIWbYfhOudsdU7t0UFYUIbnB04VWkLuCXSDYfUF5wjzv43P mTtOjoQoIc/WU4jyOGpJyCZZ5RXRs8fDzlMTYMc/YsB7i0ZAJ49UI6tkBgjRKaPA gTBm37SLCVwSEVifVS5dtlAIRgmqgeeABV5jJU+G6+mYgFV2N/wJLnFP5lDgH8k= =1Q6K -----END PGP SIGNATURE----- --B4goiNw9eia64hiQQPlQRBELgQsJFSKUS-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 19:34:47 2014 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 ESMTPS id 26288AA8; Fri, 8 Aug 2014 19:34:47 +0000 (UTC) Received: from shxd.cx (unknown [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DC802106; Fri, 8 Aug 2014 19:34:47 +0000 (UTC) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:58821 helo=THEMADHATTER) by shxd.cx with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XFgxB-0007gP-VY; Fri, 08 Aug 2014 02:59:18 -0700 From: To: "'Garrett Cooper'" , References: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> <1407453344.5935.3.camel@bruno> <095501cfb299$4872b090$d95811b0$@FreeBSD.org> In-Reply-To: Subject: RE: loader lszfs command Date: Fri, 8 Aug 2014 12:34:44 -0700 Message-ID: <0afa01cfb33f$cec78ed0$6c56ac70$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHPg+tqnJ9d5aGmqEBT91hvjPRKGwFTa5sIAYo63+AC+H56YQKEqElqm4Sf0zA= Content-Language: en-us Sender: devin@shxd.cx Cc: 'freebsd-current' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 19:34:47 -0000 > -----Original Message----- > From: Garrett Cooper [mailto:yaneurabeya@gmail.com] > Sent: Thursday, August 7, 2014 5:10 PM > To: dteske@freebsd.org > Cc: Sean Bruno; freebsd-current > Subject: Re: loader lszfs command >=20 > On Thu, Aug 7, 2014 at 4:42 PM, wrote: > > > >> -----Original Message----- > >> From: Garrett Cooper [mailto:yaneurabeya@gmail.com] > >> Sent: Thursday, August 7, 2014 4:29 PM > >> To: sbruno@freebsd.org > >> Cc: dteske@freebsd.org; freebsd-current > >> Subject: Re: loader lszfs command > >> > >> Hi Devin! > >> > >> On Thu, Aug 7, 2014 at 4:15 PM, Sean Bruno > >> wrote: > >> > On Thu, 2014-08-07 at 14:17 -0700, dteske@FreeBSD.org wrote: > >> >> Hi, > >> >> > >> >> People have been pestering me to update the Forth code to = present > >> >> a menu of ZFS datasets (*cough* boot environments *cough*). > >> >> > >> >> Would love to, but existing code seems broken. > >> >> > >> >> Can *anybody* produce meaningful output from the following? > >> >> > >> >> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D241284 > >> >> > >> >> All I get on every system I've tried (multiple versions, = including HEAD) > >> >> produce the following: > >> >> > >> >> OK lszfs zroot > >> >> ZFS: i/o error - all block copies unavailable > >> >> operation not permitted > >> >> > >> >> It's really hard for me to start with something that's broken. = Can > >> >> I get confirmation that this doesn't appear to be working as = intended? > >> >> If so, I'll go ahead and try to fix it, but need to confirm that = I'm ( a ) > >> >> not > >> >> crazy and ( b ) seeing the same thing everybody else is seeing. > >> > > >> > > >> > Hrm ... this seems to work for me. (fairly recent 11-current) > >> > > >> > OK lszfs zroot > >> > $MOS > >> > $FREE > >> > $ORIGIN > >> > tmp > >> > home > >> > usr > >> > var > >> > tftpboot > >> > poudriere > >> > OK > >> > >> Is the installed version you have in synch with the kernel and > >> zpool version for boot0, gptzfsboot, etc? > > > > Not sure how the kernel factors into all this, but I have a > > 10.0-RC1 system. >=20 > I was asking for information to help determine whether or not the > loader could read the zpool metadata, because it's interesting why > things worked for Sean and not for you :). No explanation as of yet, but I have successfully built a system that has working lszfs command. Took a stable/10 snapshot from July 29th and that seems to be working alright. Since it's working as expected in stable/10 currently (the furthest point away that I intend to MFC these enhancements), I'm happy to ignore the fact that my aged 10.0-RC1 machine doesn't work. --=20 Devin From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 19:42:44 2014 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 ESMTPS id 6CD79213; Fri, 8 Aug 2014 19:42:44 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A3D221E5; Fri, 8 Aug 2014 19:42:43 +0000 (UTC) Received: from [89.15.238.254] (helo=localhost.my.domain) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XFq3l-0001NL-OG; Fri, 08 Aug 2014 21:42:41 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id s78Jgc7d001581; Fri, 8 Aug 2014 21:42:39 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id s78Jgcee001580; Fri, 8 Aug 2014 21:42:38 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Fri, 8 Aug 2014 21:42:38 +0200 From: Matthias Apitz To: Bryan Drewery Subject: Re: poudriere: setting up jail failes Message-ID: <20140808194237.GA1517@La-Habana> Reply-To: Matthias Apitz References: <20140808164640.GA14611@sh4-5.1blu.de> <53E51A67.1020904@FreeBSD.org> <20140808191156.GA1386@La-Habana> <53E523E2.5000103@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53E523E2.5000103@FreeBSD.org> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.15.238.254 Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 19:42:44 -0000 El día Friday, August 08, 2014 a las 02:24:18PM -0500, Bryan Drewery escribió: > The use of -v head from a 10.0 system is the issue. Once you start a > build poudriere yells loudly that it is not supported. Major release > jumps are not supported. You can usually get away with a head host using > a head jail that is a few weeks newer as long as KBI does not change. > ... OK, thanks. I will update the host to head and try again. Btw: I did not saw any loud yells of poudriere. Maybe, because I went away from the desk when poudriere was doing the SVN checkout and when I came back it was already nicely compiling. Maybe it should ask a question like: Do your really want that new jail on your old system? And wait for the answer :-) Thanks for your time. matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 19:45:37 2014 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 ESMTPS id 6DF60488 for ; Fri, 8 Aug 2014 19:45:37 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39E7A220A for ; Fri, 8 Aug 2014 19:45:37 +0000 (UTC) Received: from bdrewery (uid 1298) (envelope-from bdrewery@freebsd.org) id 7f by freefall.freebsd.org (DragonFly Mail Agent v0.9+); Fri, 08 Aug 2014 19:45:37 +0000 Received: (qmail 42218 invoked from network); 8 Aug 2014 14:45:35 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 8 Aug 2014 14:45:35 -0500 Message-ID: <53E528D3.3090004@FreeBSD.org> Date: Fri, 08 Aug 2014 14:45:23 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Matthias Apitz Subject: Re: poudriere: setting up jail failes References: <20140808164640.GA14611@sh4-5.1blu.de> <53E51A67.1020904@FreeBSD.org> <20140808191156.GA1386@La-Habana> <53E523E2.5000103@FreeBSD.org> <20140808194237.GA1517@La-Habana> In-Reply-To: <20140808194237.GA1517@La-Habana> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k9T82jgbHWHq7oc6HVkMVjj25jpvlRcRa" Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 19:45:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k9T82jgbHWHq7oc6HVkMVjj25jpvlRcRa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/8/2014 2:42 PM, Matthias Apitz wrote: > El d=C3=ADa Friday, August 08, 2014 a las 02:24:18PM -0500, Bryan Drewe= ry escribi=C3=B3: >=20 >> The use of -v head from a 10.0 system is the issue. Once you start a >> build poudriere yells loudly that it is not supported. Major release >> jumps are not supported. You can usually get away with a head host usi= ng >> a head jail that is a few weeks newer as long as KBI does not change. >> ... >=20 > OK, thanks. I will update the host to head and try again. >=20 > Btw: I did not saw any loud yells of poudriere. Maybe, because I went a= way from > the desk when poudriere was doing the SVN checkout and when I came back= > it was already nicely compiling. Maybe it should ask a question like: > Do your really want that new jail on your old system? And wait for the > answer :-) >=20 >=20 > Thanks for your time. >=20 > matthias >=20 Only in 'bulk', not 'jail'. There's also a securelevel blocker in 'bulk' that is not in 'jail'. Some of these need to move to 'jail' to warn earlier, yes. --=20 Regards, Bryan Drewery --k9T82jgbHWHq7oc6HVkMVjj25jpvlRcRa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT5SjTAAoJEDXXcbtuRpfP7FMH/03STGWSzOby1mH+1dLx+C56 n68g9M6LUrUij3GyBdvMiY7Nh1WMC18hXf/2IrsJuq5yCEr7+HSZaOuk3UL0yqJC +8/wMplzdaWm1dq34RLC4fFXdznsSh2MLxlnBmGTM5OR1tdaRpLxaYUblSIUioaV pVlQMhK6lj2ZVyb91UGbGjtwRxMqIuSLKFl8EzPaZdIeQETFDcpMhKyAND2SQfNa EKQQ6NPvakyv4ApjyuvYcoCOrsk8Csxd1PmFEv9B71uuDQbavHCwBWn87Xz3EpSA 0/gM4JnjeuVxKZE5b8fraWpk93FLfH7imqrA93tU1/eCxEPivHQ5s45sjeonjOk= =s0Hf -----END PGP SIGNATURE----- --k9T82jgbHWHq7oc6HVkMVjj25jpvlRcRa-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 22:41:03 2014 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 ESMTPS id 64356CCE; Fri, 8 Aug 2014 22:41:03 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B982A27A1; Fri, 8 Aug 2014 22:41:02 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id gf5so5072427lab.23 for ; Fri, 08 Aug 2014 15:41:00 -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=pdY/MgBA3/YX0JvtIqzM3mnU8EoSuIa+REfcdpNfrAw=; b=AwKzTQ94u3t5ae3JotKVIvuVIO0eLwfoPtpQUBkkfTz4EvzC0yCHwgd2vJGZULrfe4 GU4E7ZjUPWpWFXIp/74rg267cVNNlUxPHtA9QrnMFyh3WPeXFE1HY5b2g+xgFfML7YnS UpuAY/KrRrrOHQJ4Asz0Yri99S3CpWO2vVyFxxjwZvJDe11WhOFiz2i0/keZqjTTEY05 5H1hv4pARI3D3l/40d1Ofe2SzdBDLt9VRhk62sct4Rw0E4IQN7USPjKwsNuvjF87r1n3 txd7p/2Pz0776Mk+j6QzNuID60uOyLmd/XFGbLuoFtuEeTCvS3zOJpGxN6imuD+u+OQx hDCA== MIME-Version: 1.0 X-Received: by 10.153.11.162 with SMTP id ej2mr24022899lad.15.1407537660222; Fri, 08 Aug 2014 15:41:00 -0700 (PDT) Received: by 10.112.16.37 with HTTP; Fri, 8 Aug 2014 15:41:00 -0700 (PDT) Date: Sat, 9 Aug 2014 00:41:00 +0200 Message-ID: Subject: Problems with zpool upgrade embedded_data, and rebooting From: Daniel Peyrolon To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 22:41:03 -0000 Hello everyone, I just would like to gratuitously rant about something that happened on my machine. Basically, I upgraded my zpool to use embedded_data, since it would be more efficient, and rebooted. (I installed the system with zfs using bsdinstall). It turned out that gptzfsboot wasn't able to load that filesystem, so I tried to get it working from a live system that I have on a USB drive. It didn't work on that particular live system, but, fortunately, someone could do me a favor and download the latest snapshot, and burn it to my USB drive. >From there, it was a matter of importing zroot, mounting it at /mnt, and taking a look at the code of bsdinstall, trying to find the actual command to update the bootloader. I could manage to find it, and hopefully, everything worked again. Thanks to those who helped me :) What would be the better way to avoid this happening in the future? -- Daniel From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 23:08:19 2014 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 ESMTPS id A0AC327C for ; Fri, 8 Aug 2014 23:08:19 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B9B12A24 for ; Fri, 8 Aug 2014 23:08:18 +0000 (UTC) Received: from [IPv6:2601:2:4780:2fd:e806:9aa:f68a:db81] (2601:2:4780:2fd:e806:9aa:f68a:db81) by CY1PR0301MB0841.namprd03.prod.outlook.com (25.160.163.147) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 8 Aug 2014 23:08:03 +0000 Message-ID: <53E5584E.6050903@my.hennepintech.edu> Date: Fri, 8 Aug 2014 18:07:58 -0500 From: Andrew Berg User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Subject: Re: Problems with zpool upgrade embedded_data, and rebooting References: In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:2:4780:2fd:e806:9aa:f68a:db81] X-ClientProxiedBy: BY2PR03CA053.namprd03.prod.outlook.com (10.141.249.26) To CY1PR0301MB0841.namprd03.prod.outlook.com (25.160.163.147) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02973C87BC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(189002)(24454002)(199002)(77096002)(31966008)(64126003)(54356999)(20776003)(46102001)(64706001)(107886001)(65806001)(65816999)(85306004)(83322001)(74502001)(65956001)(83506001)(87266999)(76176999)(86362001)(88552001)(2351001)(101416001)(80022001)(74662001)(47776003)(50986999)(95666004)(79102001)(42186005)(23676002)(107046002)(50466002)(92726001)(76482001)(87976001)(81542001)(4396001)(85852003)(21056001)(102836001)(81342001)(77982001)(83072002)(59896001)(80316001)(110136001)(33656002)(99396002)(105586002)(75432001)(106356001)(92566001)(89122001)(558084003)(89472002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:CY1PR0301MB0841; H:[IPv6:2601:2:4780:2fd:e806:9aa:f68a:db81]; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: my.hennepintech.edu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 23:08:19 -0000 On 2014.08.08 17:41, Daniel Peyrolon wrote: > What would be the better way to avoid this happening in the future? > Always update the bootloader before doing a zpool upgrade on your root pool. From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 23:23:18 2014 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 ESMTPS id 8F8AA5B1; Fri, 8 Aug 2014 23:23:18 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B99C2BAA; Fri, 8 Aug 2014 23:23:17 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s78NNGS4084643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 16:23:17 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s78NNGed084642; Fri, 8 Aug 2014 16:23:16 -0700 (PDT) (envelope-from jmg) Date: Fri, 8 Aug 2014 16:23:16 -0700 From: John-Mark Gurney To: Daniel Peyrolon Subject: Re: Problems with zpool upgrade embedded_data, and rebooting Message-ID: <20140808232316.GA83475@funkthat.com> Mail-Followup-To: Daniel Peyrolon , freebsd-current@freebsd.org, freebsd-fs@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 08 Aug 2014 16:23:17 -0700 (PDT) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 23:23:18 -0000 Daniel Peyrolon wrote this message on Sat, Aug 09, 2014 at 00:41 +0200: > Hello everyone, > > I just would like to gratuitously rant about something that happened on my > machine. > > Basically, I upgraded my zpool to use embedded_data, since it would be more > efficient, and rebooted. (I installed the system with zfs using bsdinstall). > It turned out that gptzfsboot wasn't able to load that filesystem, so I > tried to get it working from a live system that I have on a USB drive. > It didn't work on that particular live system, but, fortunately, someone > could do me a favor and download the latest snapshot, and burn it to my USB > drive. > > >From there, it was a matter of importing zroot, mounting it at /mnt, and > taking a look at the code of bsdinstall, trying to find the actual command > to update the bootloader. > I could manage to find it, and hopefully, everything worked again. Thanks > to those who helped me :) > > What would be the better way to avoid this happening in the future? Didn't you get the following warning: # zpool upgrade -a This system is currently running ZFS pool version 28. Successfully upgraded 'tank' If you boot from pool 'tank', don't forget to update boot code. Assuming you use GPT partitioning and da0 is your boot disk the following command will do it: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 Or something similar? If you didn't follow the warnings, how else can we help you? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 23:33:21 2014 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 ESMTPS id 09BDF82F for ; Fri, 8 Aug 2014 23:33:21 +0000 (UTC) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Caravan", Issuer "Mail Client CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CAB202D4A for ; Fri, 8 Aug 2014 23:33:20 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 08A50B2E16; Fri, 8 Aug 2014 23:27:54 +0000 (UTC) Date: Sat, 9 Aug 2014 01:27:54 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Subject: ddb_enable=YES doesn't reboot anymore Message-ID: <20140808232754.GD4261@caravan.chchile.org> Mail-Followup-To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 08 Aug 2014 23:33:21 -0000 Hi, I noticed that on panic, the default ddb script does not reboot the machine automatically anymore. It just stays at the debugger prompt. # sysctl debug.ddb.scripting.scripts debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show lockedvnods kdb.enter.panic=capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset kdb.enter.witness=run lockinfo I don't really know when it started to behave like this as I upgrade pretty rarely. My kernel is running r268370. -- 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 Sat Aug 9 02:26:59 2014 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 ESMTPS id 3E3C7BE9 for ; Sat, 9 Aug 2014 02:26:59 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 006782BAA for ; Sat, 9 Aug 2014 02:26:58 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id CF11B37292 for ; Sat, 9 Aug 2014 02:26:56 +0000 (UTC) Message-ID: <53E58703.1050602@freebsd.org> Date: Fri, 08 Aug 2014 22:27:15 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Problems with zpool upgrade embedded_data, and rebooting References: <20140808232316.GA83475@funkthat.com> In-Reply-To: <20140808232316.GA83475@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B8n0V4Bxn9WpfU1EiC3g3sSn9CJFL95X4" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 09 Aug 2014 02:26:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B8n0V4Bxn9WpfU1EiC3g3sSn9CJFL95X4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-08-08 19:23, John-Mark Gurney wrote: > Daniel Peyrolon wrote this message on Sat, Aug 09, 2014 at 00:41 +0200:= >> Hello everyone, >> >> I just would like to gratuitously rant about something that happened o= n my >> machine. >> >> Basically, I upgraded my zpool to use embedded_data, since it would be= more >> efficient, and rebooted. (I installed the system with zfs using bsdins= tall). >> It turned out that gptzfsboot wasn't able to load that filesystem, so = I >> tried to get it working from a live system that I have on a USB drive.= >> It didn't work on that particular live system, but, fortunately, someo= ne >> could do me a favor and download the latest snapshot, and burn it to m= y USB >> drive. >> >> >From there, it was a matter of importing zroot, mounting it at /mnt, = and >> taking a look at the code of bsdinstall, trying to find the actual com= mand >> to update the bootloader. >> I could manage to find it, and hopefully, everything worked again. Tha= nks >> to those who helped me :) >> >> What would be the better way to avoid this happening in the future? >=20 > Didn't you get the following warning: > # zpool upgrade -a > This system is currently running ZFS pool version 28. >=20 > Successfully upgraded 'tank' >=20 > If you boot from pool 'tank', don't forget to update boot code. > Assuming you use GPT partitioning and da0 is your boot disk > the following command will do it: >=20 > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 >=20 > Or something similar? >=20 > If you didn't follow the warnings, how else can we help you? >=20 Yeah, there is a big warning with explicit instructions after you zpool upgrade, warning you about this specific issue. In order to save your self from a rescue system, it'd have to support the embedded_data feature as well. --=20 Allan Jude --B8n0V4Bxn9WpfU1EiC3g3sSn9CJFL95X4 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.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT5YcGAAoJEJrBFpNRJZKf9P0P/iOVrP3QALzdJSHT+RhPHC8K VpChOxEe8HrB6eLFalya51zkAP6f/Bhg+FhMcjeqIwPuXnH/l2Xi0UXFENeB+k/Y 6KkwMnnKFhx3DEC+m0Ak8tE1aAszm5I9NHZyCmfOFzJssIMr8AxEM5neRePpI21h kX9WvR714J1i7BQchQXg3fEoeBGN6dNZvJdvGIywIWZlh/Z3K6D7RtTgjxSa9z99 FfwHi+sWzWoUfh0bbc+GekUXnPXi5I/Fv9q26MAx2U9uUcQl/r3PzkQp/RChr71L lLb+UcHWIx7aHO1P6Ua2/5FA2AGM1uDTGAoN5fFRTRq5h3nVNv/es7wi3IPIQXEh yB7k0XKtaat+XTKwgCNm0AF15iZGiQuTG+RfWY3xH/5Qu+9foHfKDb8l7W7Lff4h BaAvA6pEGutvfgVdccSInaMYlg241cgBPXzUeLwO+HckDQcJO/MFz43nIMwekoG9 /qe/32MZDoBYfvkjOq+2df71nJaD5My8yBQwTlMVHfhwlkq3XSL6f5NKb/WMUI2k ld13PDmRuzDQTgGkjpcr5LjD1lwZYLnqv14wX3Uskr5308UaGO4DY8HTaqZOwdMb jTEjS5ljc337ux43QwtGWik2edQQQP869Crcq7g57e34DhzM2cnGgO/7QVSWY1ZW 6hrIcXhZiVI+x9BGs9eI =ksV4 -----END PGP SIGNATURE----- --B8n0V4Bxn9WpfU1EiC3g3sSn9CJFL95X4-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 9 17:33:00 2014 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 ESMTPS id 7935C8C9 for ; Sat, 9 Aug 2014 17:33:00 +0000 (UTC) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 418412451 for ; Sat, 9 Aug 2014 17:33:00 +0000 (UTC) Received: by mail-yk0-f182.google.com with SMTP id q9so4866755ykb.13 for ; Sat, 09 Aug 2014 10:32:59 -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=OaijLLu/YQrelF9Wdn/CAXWtKSwXCGphNv/XWPjaTPg=; b=ZJLzYwhu7Kqm0DcmAUmrv4LhxQMAqDYmTaJIAL/tExaj6koM4v54OC8SNJJxTXbhsm DMw2f/q6f2pmKDk47q41i+KnbunCl/3QXKys+4yhUbLpUQEKDf7EovGEaqQiyC0xlvUO 3tQAPXGvQDGUxJAnby3IAsho4bJl6zRHX+ztkJFqxVJHlfD77pBCN6S8Kawuj22e+b8j DXjmrZToYQkkToQG5r7OAnxbGEOJYRJURWAU7yx0vGXnTdwMvX2Qv28YnzQz8UbC8ob5 6C6IQW386SjZPwpKLUaxqNAkrMwFMHfklX8NUCfDdLqBXgk5qzzhES+le9OLLYSLfH/6 q1rw== MIME-Version: 1.0 X-Received: by 10.236.117.37 with SMTP id i25mr6770506yhh.85.1407605579535; Sat, 09 Aug 2014 10:32:59 -0700 (PDT) Received: by 10.170.161.196 with HTTP; Sat, 9 Aug 2014 10:32:59 -0700 (PDT) Date: Sat, 9 Aug 2014 10:32:59 -0700 Message-ID: Subject: No bootable device From: Mehmet Erol Sanliturk To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 09 Aug 2014 17:33:00 -0000 Dears All , When FreeBSD 9.1 amd64 Stable ( 2013-04-28 , r 250 009 , .iso ) , FreeBSD 9.2 amd64 Release ( .iso ) are installed with following steps , they are producing bootable and very well working systems : Install Partitioning : Guided , Partition : Entire disk Partition Editor : Finish Confirmation : Commit Final Configuration : Exit Manual Configuration : No Complete : Reboot When the same steps applied to the following installs : FreeBSD 9.3 amd64 Release ( .iso ) , FreeBSD 10.0 amd64 Stable ( 2014-06-30 , r 268 038 , .iso ) , FreeBSD 10.0 amd64 Stable ( 2014-07-12 , r 268 571 , .iso ) , FreeBSD 11.0 amd64 Current ( 2014-08-04 , r 269 497 , Disk 1 , iso ) , the installed systems are not bootable , and the last sentence on the screen is the following : No bootable device -- insert boot disk and press any key . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Sat Aug 9 18:50:14 2014 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 ESMTPS id E3C9B153; Sat, 9 Aug 2014 18:50:14 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0D102A94; Sat, 9 Aug 2014 18:50:14 +0000 (UTC) Received: from [89.204.153.246] (helo=localhost.my.domain) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XGBiU-000868-M6; Sat, 09 Aug 2014 20:50:10 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id s79Io9M5001381; Sat, 9 Aug 2014 20:50:09 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id s79Io8pg001380; Sat, 9 Aug 2014 20:50:09 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 9 Aug 2014 20:50:08 +0200 From: Matthias Apitz To: Bryan Drewery Subject: Re: poudriere: setting up jail failes Message-ID: <20140809185008.GA1337@La-Habana> Reply-To: Matthias Apitz References: <20140808164640.GA14611@sh4-5.1blu.de> <20140808171215.GQ2644@home.opsec.eu> <20140808185713.GA1304@La-Habana> <53E524AC.6040402@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53E524AC.6040402@FreeBSD.org> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.153.246 Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: 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, 09 Aug 2014 18:50:15 -0000 El día Friday, August 08, 2014 a las 02:27:40PM -0500, Bryan Drewery escribió: > On 8/8/2014 1:57 PM, Matthias Apitz wrote: > > And, btw., why is poudriere removing all the jail when an error occures? > > Wouldn't it be better to let it there to have a look into and remove it > > on the next run? > > Yes I agree this should probably change. I'll evaluate it after the 3.1 > release which is the major focus right now. The jail command has a lot > of issues with building and error handling. I have updated last night the host to 'head' and poudriere itself to poudriere-devel-3.0.99.20140801. Compiling the ports in the jail makes progress, as always with some hick-ups in the ports itself. I have one fundamental question, maybe a missunderstanding of poudriere: When I run 'poudriere options ...' it is not using the toolchain in the jail: # uname -a FreeBSD vm-tiny-r269739 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r269739: Sat Aug 9 07:07:40 CEST 2014 guru@vm-tiny-r269739:/usr/obj/usr/src/sys/GENERIC i386 $ # poudriere version 3.1-pre # poudriere options -c -j freebsd-head -p ports-head x11/kde4 brings up the Options menu of x11/kde4 and when you look with ps, it uses /usr/local/bin/dialog4ports for this: # ps ax | fgrep dialog 92303 3 I+ 0:00,00 /usr/local/bin/dialog4ports when I terminate the dialog, it seems that the pkg-* tools are used (which ofc are not installed on the host): ===> Setting user-specified options for kde-4.12.5 and dependencies /usr/local/sbin/pkg-static: not found make[1]: "/usr/local/poudriere/ports/ports-head/Mk/bsd.openssl.mk" line 99: warning: Couldn't read shell's output for "/usr/local/sbin/pkg-static which -qo /usr/local/lib/libcrypto.so || :" /usr/local/sbin/pkg-static: not found What I'm doing wrong or have understand wrong? Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign