From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 00:11:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 993EB106566B; Sun, 19 Dec 2010 00:11:53 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id 7CA558FC15; Sun, 19 Dec 2010 00:11:53 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.98.123] by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0LDN00DMNF5UZ480@asmtp030.mac.com>; Sat, 18 Dec 2010 16:10:47 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1012180140 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-12-18_02:2010-12-18, 2010-12-18, 1970-01-01 signatures=0 From: Chuck Swiger In-reply-to: <4D0D48B3.7000104@FreeBSD.org> Date: Sat, 18 Dec 2010 16:10:42 -0800 Message-id: <2E952F5B-15EB-483C-BAAD-8AAD1EC1BB7D@mac.com> References: <4D0C49A2.4000203@FreeBSD.org> <699B0DD9-A3E0-4508-8AAD-E493EF6DB3D9@mac.com> <4D0D41C9.8060807@FreeBSD.org> <04FBEACB-765E-4EC0-8FAE-3ED26E190773@mac.com> <4D0D48B3.7000104@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1082) Cc: freebsd-stable@freebsd.org Subject: Re: /etc/rc.d/named stop (Was: Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 00:11:53 -0000 On Dec 18, 2010, at 3:50 PM, Doug Barton wrote: > On 12/18/2010 15:41, Chuck Swiger wrote: >> /usr/local/sbin/named from ports seems to be using a /var/named/var/run/named/named.pid file instead. > > You're not using the default named.conf file then. Nope. > What you've got there is the named default, whether from ports or the base, doesn't matter. Yes, that seems to be right. > I always suggest that people start from the default named.conf, and add and subtract accordingly, preferably with include directives to make life easier. Look at pid-file in the options section in particular. :) It's different from the default due to hysterical raisins, which I'm sort of loathe to change now. It would be handy if named grew an option flag to control the pidfile location, so that the rc.d script could be sure that it is looking at the appropriate place. Failing that, however, I find it a bit surprising that I'd need to override some compiled-in default location in the config to make things work, when I'm not changing the defaults myself and named is being chroot'ed under a filesystem tree which the rc.d script is free to adjust as it needs to for things to align without symlink duct-tape. :-) Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 00:24:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE2401065670 for ; Sun, 19 Dec 2010 00:24:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 569D68FC0A for ; Sun, 19 Dec 2010 00:24:41 +0000 (UTC) Received: (qmail 24419 invoked by uid 399); 19 Dec 2010 00:24:40 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Dec 2010 00:24:40 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D0D50C7.5050905@FreeBSD.org> Date: Sat, 18 Dec 2010 16:24:39 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Chuck Swiger References: <4D0C49A2.4000203@FreeBSD.org> <699B0DD9-A3E0-4508-8AAD-E493EF6DB3D9@mac.com> <4D0D41C9.8060807@FreeBSD.org> <04FBEACB-765E-4EC0-8FAE-3ED26E190773@mac.com> <4D0D48B3.7000104@FreeBSD.org> <2E952F5B-15EB-483C-BAAD-8AAD1EC1BB7D@mac.com> In-Reply-To: <2E952F5B-15EB-483C-BAAD-8AAD1EC1BB7D@mac.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: /etc/rc.d/named stop (Was: Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 00:24:41 -0000 On 12/18/2010 16:10, Chuck Swiger wrote: > On Dec 18, 2010, at 3:50 PM, Doug Barton wrote: >> On 12/18/2010 15:41, Chuck Swiger wrote: >>> /usr/local/sbin/named from ports seems to be using a >>> /var/named/var/run/named/named.pid file instead. >> >> You're not using the default named.conf file then. > > Nope. Nothing wrong with that. :) > It would be handy if named grew an option flag to control the pidfile > location, so that the rc.d script could be sure that it is looking at > the appropriate place. Yes, I have that on my list, but haven't gotten enough round 'tuits. OTOH: grep named_pidfile /etc/defaults/rc.conf named_pidfile="/var/run/named/pid" # Must set this in named.conf as well > Failing that, however, I find it a bit surprising that I'd need to > override some compiled-in default location in the config to make > things work, when I'm not changing the defaults myself and named is > being chroot'ed under a filesystem tree which the rc.d script is free > to adjust as it needs to for things to align without symlink > duct-tape. :-) The symlink is necessary because of the way the named chroot works. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 05:57:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D0001065673; Sun, 19 Dec 2010 05:57:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C5CF08FC08; Sun, 19 Dec 2010 05:57:40 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oBJ5vasB060221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Dec 2010 07:57:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oBJ5vaUF038282; Sun, 19 Dec 2010 07:57:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oBJ5vaAP038281; Sun, 19 Dec 2010 07:57:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 19 Dec 2010 07:57:36 +0200 From: Kostik Belousov To: Doug Barton Message-ID: <20101219055736.GI33073@deviant.kiev.zoral.com.ua> References: <4D0C49A2.4000203@FreeBSD.org> <20101218111538.GZ33073@deviant.kiev.zoral.com.ua> <4D0D3E9F.4010100@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vV11x03Douyojv5R" Content-Disposition: inline In-Reply-To: <4D0D3E9F.4010100@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: Following vendor release cycle (Was: Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 05:57:41 -0000 --vV11x03Douyojv5R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 18, 2010 at 03:07:11PM -0800, Doug Barton wrote: > On 12/18/2010 03:15, Kostik Belousov wrote: > >On Fri, Dec 17, 2010 at 09:41:54PM -0800, Doug Barton wrote: > >>Howdy, > >> > >>Traditionally for contributed software generally, and BIND in particular > >>we have tried to keep the major version of the contributed software > >>consistent throughout a given RELENG_$N branch of FreeBSD. Hopefully the > >>reasoning for this is obvious, we want to avoid POLA violations. > >Actually not. My own POV is that we should follow the vendor release > >cycle, and not the FreeBSD release cycle, for the contributed software. > > > >I do not advocate immediate upgrade of the third-party software that > >reached its EOL, but I think that we should do this without pushback > >if maintainer consider the neccessity of upgrade. >=20 > Just to be clear, there were considerable discussions, over a long=20 > period of time; between myself, the release engineers, and the=20 > security-officer team regarding the subject of BIND 9.3 in RELENG_6. I=20 > was given the green light to upgrade if I felt it was necessary (as=20 > you're suggesting here) but the final decision to live with the status=20 > quo was mine, and I accept responsibility for it. >=20 > My reasoning was as follows: >=20 > 1. All the latest versions of BIND are available in ports, and I made=20 > sure that they worked in RELENG_6 so that users who wanted to stay at=20 > that OS level but had more serious DNS needs had an easy path. >=20 > 2. Because BIND 9.3 lacked the ability to do modern DNSSEC anyone who=20 > wanted that feature would have to upgrade anyway. >=20 > 3. BIND 9.3 was still suitable for the (primary) stated purpose of BIND= =20 > in the base, a basic local resolving name server. >=20 > 4. BIND 9.3 was different enough that users migrating from it to more=20 > modern versions were experiencing problems. >=20 > 5. Users were naturally migrating to RELENG_[78] at a pace which=20 > minimized the impact of the issue. >=20 > If any of those things had stopped being true my decision would have=20 > been different, but as it was I chose to "grin and bear it" in order to= =20 > avoid the POLA violation for any users who were actually using BIND 9.3= =20 > in RELENG_6. However, the circumstances for BIND 9.4 and RELENG_7 are=20 > different, and much more amenable to the upgrade, which is why I'm=20 > proposing it. I do not question your decision of upgrading or leaving the legacy version of BIND in the legacy branch of FreeBSD src. I only noted that my personal POV is that we develop the OS, and not are the vendor of the third-party software, in this case the BIND. As such, I think that following the vendor life-cycle for contrib is less resource-intensive for the project, and should be the default. If anybody who does the real work feels that it is interesting/nice to the users/generally better to spend the time neccessary to keep the upgrade path on the branch smoother, I am fine with this. --vV11x03Douyojv5R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0NntAACgkQC3+MBN1Mb4jZtgCdHRVnerwmoio52JpoaDbl5p0d BBUAnRoIEEQGuMwBfeCfKcmA+nbAMQ6l =1Hx/ -----END PGP SIGNATURE----- --vV11x03Douyojv5R-- From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 08:23:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDCCA106564A for ; Sun, 19 Dec 2010 08:23:28 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from deliver.hol.gr (deliver.hol.gr [62.38.3.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3541E8FC17 for ; Sun, 19 Dec 2010 08:23:27 +0000 (UTC) Received: from auth-smtp.hol.gr (takeit02.mail.dc.hol.net [192.168.20.72]) by deliver.hol.gr (8.12.11/8.11.6) with ESMTP id oBJ8MwRY019321 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified OK); Sun, 19 Dec 2010 10:22:58 +0200 Received: from mamalacation.ee.auth.gr (ppp046176009168.dsl.hol.gr [46.176.9.168]) by auth-smtp.hol.gr (8.13.1/8.13.1) with ESMTP id oBJ8Mvv3017286; Sun, 19 Dec 2010 10:22:58 +0200 Message-ID: <4D0DC0F1.1050808@eng.auth.gr> Date: Sun, 19 Dec 2010 10:23:13 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101103 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ronald Klop References: <201012180947.oBI9lMoU092383@lurza.secnetix.de> <4D0CA06A.2080603@eng.auth.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/10739/Wed Apr 14 06:54:30 2010 on takeit02.mail.dc.hol.net X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: vm.swap_reserved toooooo large? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 08:23:28 -0000 On 19/12/2010 00:17, Ronald Klop wrote: > On Sat, 18 Dec 2010 12:52:10 +0100, George Mamalakis > wrote: > >> Oliver, >> >> I am sending you this email outside the list, because I think that > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > That didn't work out as you intended. :-) > replying on emails and cooking on the same time may result in peculiar outcomes :)...sorry guys. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 09:20:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BE151065670; Sun, 19 Dec 2010 09:20:33 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB918FC20; Sun, 19 Dec 2010 09:20:33 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id oBJ9KWop035829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Dec 2010 01:20:32 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id oBJ9KWLs035828; Sun, 19 Dec 2010 01:20:32 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA14953; Sun, 19 Dec 10 01:12:21 PST Date: Sun, 19 Dec 2010 01:11:52 -0800 From: perryh@pluto.rain.com To: avg@freebsd.org Message-Id: <4d0dcc58.Z6ITxDmhSuMVmGVR%perryh@pluto.rain.com> References: <4cfc72a5.3nAjkv8mdrO/NrKQ%perryh@pluto.rain.com> <4CFD0633.9060509@freebsd.org> <4d089a74.vwMJkPEIddt7PIxy%perryh@pluto.rain.com> <4D08AACB.6060306@freebsd.org> <4d09dd2e.iVncbZ/gHBXX0WdL%perryh@pluto.rain.com> <4D09E0F3.5040302@freebsd.org> In-Reply-To: <4D09E0F3.5040302@freebsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Tunables (Re: How to debug a double fault? (Re: Could MSGBUF_SIZE be made a loader tunable?)) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 09:20:33 -0000 Andriy Gapon wrote: > on 16/12/2010 11:34 perryh@pluto.rain.com said the following: > > Andriy Gapon wrote: > >> BTW, are you sure that you correctly placed initialization of > >> msgbufsize ? > > > > I am not at all sure of that ... > > > > Apart from the name, msgbufsize is set up in exactly the same > > way and place -- in init_param1() -- as maxswzone and maxbcache. > > Perhaps that is not early enough ... > > I don't see any connection between msgbufsize and maxswzone, > so I also don't know if that place is early enough. The only "connection" is that maxswzone and maxbcache seemed to be loader tunables that cannot be changed (via sysctl) while the system is running -- the same usage paradigm I have in mind for msgbufsize. I've since found the description of i386 startup in the Architecture Handbook, and based on that -- and the code in locore.s and machdep.c -- it certainly _seems_ as if init_param1() should be early enough: Practically the first thing that locore.s does after establishing virtual addressing is to call init386(), and init386() calls init_param1() long before it either accesses msgbufsize directly or calls getmemsize() (which uses msgbufsize to allocate space for the kernel message buffer). > Just try to initialize the variable where it's defined and use > TUNABLE_LONG. Is there any documentation on how to use the TUNABLE_* macros, or on when to use, say, TUNABLE_LONG vs TUNABLE_LONG_FETCH? I found nothing with their definitions in sys/kernel.h, nor in any of the base-system manpages, nor in /usr/share/doc/... From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 14:25:55 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B8D6106566C for ; Sun, 19 Dec 2010 14:25:55 +0000 (UTC) (envelope-from ade@FreeBSD.org) Received: from panix.lovett.com (panix.lovett.com [166.84.7.128]) by mx1.freebsd.org (Postfix) with ESMTP id 169718FC18 for ; Sun, 19 Dec 2010 14:25:54 +0000 (UTC) Received: from cpe-66-68-128-204.austin.res.rr.com ([66.68.128.204] helo=[172.16.32.150]) by panix.lovett.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PUJn7-0001oE-Ee for freebsd-stable@FreeBSD.org; Sun, 19 Dec 2010 13:59:13 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ade Lovett In-Reply-To: <4D0C49A2.4000203@FreeBSD.org> Date: Sun, 19 Dec 2010 07:58:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2F54986F-58EB-4E79-9A2D-AD71EAC4B671@FreeBSD.org> References: <4D0C49A2.4000203@FreeBSD.org> To: freebsd-stable@FreeBSD.org X-Mailer: Apple Mail (2.1082) Cc: Subject: Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 14:25:55 -0000 On Dec 17, 2010, at 23:41 , Doug Barton wrote: > Your feedback on the issue of upgrading BIND in RELENG_7 is welcome. > Sooner is better. :) Seriously? For RELENG_7 which is going to be with us a long time. = Looks like we have a bunch of DNS mongers here that have tested out = their stuff with RELENG_8 to no apparent "omg, iceberg" ill-effect. Light blue touch paper. Stand back. -aDe From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 19:55:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFB66106566C for ; Sun, 19 Dec 2010 19:55:25 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 693A78FC21 for ; Sun, 19 Dec 2010 19:55:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([80.202.8.11]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LDO004FVY0B6LB0@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Sun, 19 Dec 2010 20:55:23 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LDO00ENLY0B47F0@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Sun, 19 Dec 2010 20:55:23 +0100 (CET) Date: Sun, 19 Dec 2010 20:55:23 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20101219205523.c2de9906.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: The FreeBSD 7.4-BETA1 CD wont boot properly on this machine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 19:55:25 -0000 Hi, I am trying to install FreeBSD 7.4-BETA1 / amd64 on this[1] machine. The machine doesn't have a CD drive built-in, so I am using a Plextor PX-608CU external DVD writer which connects via usb as the CD drive to install from. I use the FreeBSD-7.4-BETA1-amd64-disc1.iso, which is burned to a CD. After powering on the machine, I press F8, get a nice little bootmenu, select the Plextor drive, and off we go. The kernel boots, and everything is great. But, after detecting the hard drive (ad4, ok it's really a SSD) and the cd drive, it just spits out messages like these: run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config and after spitting out one more message (the one for 300 seconds), it just sits there. Booting with verbose doesn't give men any more messages related to this. I've tried the -bootonly CD too - it has the same problem. Yes, the sha256 checksums on the files verifies a-ok, the CD's can be mounted in FreeBSD, etc. I even mad a usb memory stick image of the -disc1 and booted the machine from that, and it has the same problem (the run_interrupt... messages). Kicker: the machine boots nicely from a FreeBSD 8.1-release (amd64) CD. Also tried with a OpenBSD 4.8 (amd64) install CD, yep - it also boots nicely. So, any hints on how to get FreeBSD 7.4-BETA1 onto this machine? References: 1) http://sites.google.com/site/tingox/asus_v7-p7h55e -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 20:04:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AD17106564A for ; Sun, 19 Dec 2010 20:04:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id A92A48FC16 for ; Sun, 19 Dec 2010 20:04:50 +0000 (UTC) Received: (qmail 12791 invoked by uid 399); 19 Dec 2010 20:04:49 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Dec 2010 20:04:49 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D0E6560.8010201@FreeBSD.org> Date: Sun, 19 Dec 2010 12:04:48 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kostik Belousov References: <4D0C49A2.4000203@FreeBSD.org> <20101218111538.GZ33073@deviant.kiev.zoral.com.ua> <4D0D3E9F.4010100@FreeBSD.org> <20101219055736.GI33073@deviant.kiev.zoral.com.ua> In-Reply-To: <20101219055736.GI33073@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Following vendor release cycle (Was: Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 20:04:51 -0000 On 12/18/2010 21:57, Kostik Belousov wrote: > I do not question your decision of upgrading or leaving the legacy version > of BIND in the legacy branch of FreeBSD src. You know that, and I know that. :) I just wanted to be sure that no one got the impression that anyone other than me was responsible for the decision. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 22:00:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 413E11065674 for ; Sun, 19 Dec 2010 22:00:03 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bw0-f48.google.com (mail-bw0-f48.google.com [209.85.214.48]) by mx1.freebsd.org (Postfix) with ESMTP id C0F3C8FC16 for ; Sun, 19 Dec 2010 22:00:02 +0000 (UTC) Received: by bwz8 with SMTP id 8so2333343bwz.7 for ; Sun, 19 Dec 2010 14:00:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:reply-to :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=sZ8rnTOyw/gnka5q3wFFlgwWb72sofsb411rng72s+I=; b=qMDRLvfz4VjJs8ffj/VtMR/KIq3uR3mW3zFFx/hh31EZR3I/ar2zRBwOCOMORMoqgg bhQzvptxWA4WVeVL+0b5a36tzdSqQjseOQHTw4J0oZUBOjI/KUvzfPZxayqGsSjQlT3J O2az0juwAL0cWTyipnmEr9A5+d9my5IyxfX3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; b=kdStBF/OlYa9G7Q7O5hrgVPmuLTaBt1nHMcvAd2QZOZGTnr5v9SXeHqtOLx8eOkQwb Xiz3sRW9JWCV8cl3/QXbEZWeisONOVN98dZLse8Zbtsr1+Zo+vw4ktnAATEbhuZ8h6uN 2g0CN+li252kaPFvPY8WvE5Efo4AfQJ3EQy6Q= Received: by 10.204.46.134 with SMTP id j6mr2871485bkf.112.1292794289211; Sun, 19 Dec 2010 13:31:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.52.19 with HTTP; Sun, 19 Dec 2010 13:30:59 -0800 (PST) In-Reply-To: <20101219205523.c2de9906.torfinn.ingolfsen@broadpark.no> References: <20101219205523.c2de9906.torfinn.ingolfsen@broadpark.no> From: Chris Rees Date: Sun, 19 Dec 2010 21:30:59 +0000 Message-ID: To: Torfinn Ingolfsen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: The FreeBSD 7.4-BETA1 CD wont boot properly on this machine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 22:00:03 -0000 On 19 December 2010 19:55, Torfinn Ingolfsen wrote: > Hi, > I am trying to install FreeBSD 7.4-BETA1 / amd64 on this[1] machine. > The machine doesn't have a CD drive built-in, so I am using a Plextor > PX-608CU external DVD writer which connects via usb as the CD drive to > install from. I use the FreeBSD-7.4-BETA1-amd64-disc1.iso, which is burne= d > to a CD. > After powering on the machine, I press F8, get a nice little bootmenu, > select the Plextor drive, and off we go. The kernel boots, and > everything is great. > But, after detecting the hard drive (ad4, ok it's really a SSD) and the > cd drive, it just spits out messages like these: > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_confi= g > run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_confi= g > run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_confi= g > > and after spitting out one more message =A0(the one for 300 seconds), it = just > sits there. Booting with verbose doesn't give men any more messages relat= ed > to this. I've tried the -bootonly CD too - it has the same problem. > Yes, the sha256 checksums on the files verifies a-ok, the CD's can be mou= nted > =A0in FreeBSD, etc. > I even mad a usb memory stick image of the -disc1 and booted the machine = from that, > and it has the same problem (the run_interrupt... messages). > > Kicker: the machine boots nicely from a FreeBSD 8.1-release (amd64) CD. > Also tried with a OpenBSD 4.8 (amd64) install CD, yep - it also boots nic= ely. > > So, any hints on how to get FreeBSD 7.4-BETA1 onto this machine? > > References: > 1) http://sites.google.com/site/tingox/asus_v7-p7h55e > -- > Regards, > Torfinn Ingolfsen Did you try installing using a different computer onto that hard drive? Is the hardware supported by 7.x (http://www.freebsd.org/releases/7.3R/hardware.html for pointers) Is there a reason you want 7.4 rather than 8.1? Chris From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 22:17:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB832106566B for ; Sun, 19 Dec 2010 22:17:20 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6AA988FC12 for ; Sun, 19 Dec 2010 22:17:20 +0000 (UTC) Received: by qwj9 with SMTP id 9so2108475qwj.13 for ; Sun, 19 Dec 2010 14:17:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=k+HKfp8H9cBvQiMqql55WVYWNpUMRf6KJ32sHnzSH0U=; b=CSvvEm2TCQt8Otiyv6/z2jat301eoe/prGDqlpSL51xh9FKbMyjXEHfivX++tszrjX 9fxZYlAvJhTnwKe1oZQuaPsdM7t1MRLXJR5WDigbulWDQ8dMGBQf4C9AGnY6mT/WLBF6 GCy1gWbckba8t50PbvG1M58eIvgxENphOFl7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OADy5j4oKUL0RZ++TiTF9FloAuhvxtS0J28RGLjf64KkKPIs+uAD2wkjVJ8Gl/j5fq 6EbTtHhOv4JpLuQUmEkrhI+8Jsb1v9jvMMBC3RvBI8aQryCwjvRu1topkcqncTcufTur 6DCZXRr1BuIX4mmSyJDVAJgE1p5Fe5ZDMRyg4= MIME-Version: 1.0 Received: by 10.229.43.72 with SMTP id v8mr3112994qce.290.1292795462577; Sun, 19 Dec 2010 13:51:02 -0800 (PST) Received: by 10.229.95.205 with HTTP; Sun, 19 Dec 2010 13:51:02 -0800 (PST) Date: Sun, 19 Dec 2010 22:51:02 +0100 Message-ID: From: Claus Guttesen To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: get ram usage using getrusage() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 22:17:20 -0000 Hi. I'm trying to read how much ram an app is using reading http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2006-03/msg00246.html from ru.ru_maxrss. While ru.ru_maxrss gives me used accurate ram-usage when memory increases it doesn't immediately count down when memory is released. So I tried to get a more accurate reading using this using /usr/src/sys/kern/kern_clock.c as example: struct thread *td; td = curthread; p = td->td_proc; vm = p->p_vmspace; rss = pgtok(vmspace_resident_count(vm)); Curthread is not defined, I searched google but can't find any references. But is this the proper way to get an apps memory usage? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare twitter.com/kometen From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 22:33:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E33D9106564A; Sun, 19 Dec 2010 22:33:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by mx1.freebsd.org (Postfix) with ESMTP id 7B00B8FC13; Sun, 19 Dec 2010 22:33:42 +0000 (UTC) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 8B3125F9865; Sun, 19 Dec 2010 22:33:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 4E729E6030; Sun, 19 Dec 2010 22:33:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 111868083B1; Mon, 20 Dec 2010 09:33:23 +1100 (EST) To: Jeremy Chadwick From: Mark Andrews References: <20101215004712.GA56065@icarus.home.lan> <20101218220244.GA19039@icarus.home.lan> In-reply-to: Your message of "Sat, 18 Dec 2010 14:02:44 -0800." <20101218220244.GA19039@icarus.home.lan> Date: Mon, 20 Dec 2010 09:33:22 +1100 Message-Id: <20101219223323.111868083B1@drugs.dv.isc.org> X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.ams1.isc.org Cc: Dan Allen , dougb@freebsd.org, FreeBSD-STABLE Mailing List Subject: Re: ntpd fails on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 22:33:43 -0000 In message <20101218220244.GA19039@icarus.home.lan>, Jeremy Chadwick writes: > On Sat, Dec 18, 2010 at 11:37:21AM -0700, Dan Allen wrote: > > > > On 14 Dec 2010, at 5:47 PM, Jeremy Chadwick wrote: > > > > > Anyway, many people are using the below with success. > > > > Sorry to say that netwait did NOT in the end fix the problem. > > > > I however discovered that if I put > > > > synchronous_dhclient="YES" > > > > into my /etc/rc.conf file, that over many days & reboots now has > > been delivering reliable networking such that ntpd always works. > > > > Thanks again to everyone for their help. > > For DHCP-based clients, yeah, netwait itself isn't sufficient; you'd > need to use synchronous_dhclient as you discovered. > synchronous_dhclient will accomplish the same thing as netwait for > DHCP-based clients. > > Explanation: dhclient will sit and wait until DHCP is fully negotiated > before continuing on with remaining rc scripts. The negotiation > involves packets going back/forth between the client and server on UDP > ports 67 and 68, which obvious acts as a validator that traffic is > flowing across the interface. > > I'll add a comment to the top of the netwait script noting that it > should be used for environments where the system is not using DHCP > (configured static IPs in rc.conf), and mention for DHCP-based clients > to use synchronous_dhclient instead. My solution was to start/re-start ntp using /etc/dhclient-exit-hooks whenever the IP address changed. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 22:55:43 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74C4C106564A; Sun, 19 Dec 2010 22:55:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by mx1.freebsd.org (Postfix) with ESMTP id 28F2F8FC0C; Sun, 19 Dec 2010 22:55:43 +0000 (UTC) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id E54145F98ED; Sun, 19 Dec 2010 22:55:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id D2812E605D; Sun, 19 Dec 2010 22:55:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8EF718088AD; Mon, 20 Dec 2010 09:55:23 +1100 (EST) To: Doug Barton From: Mark Andrews References: <201012181716.oBIHGS3m099731@hergotha.csail.mit.edu><4D0D408A.2020802@FreeBSD.org> In-reply-to: Your message of "Sat, 18 Dec 2010 15:15:22 -0800." <4D0D408A.2020802@FreeBSD.org> Date: Mon, 20 Dec 2010 09:55:23 +1100 Message-Id: <20101219225523.8EF718088AD@drugs.dv.isc.org> X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.ams1.isc.org Cc: stable@freebsd.org, Garrett Wollman Subject: Re: Enabling DNSSEC (Was: Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 22:55:43 -0000 In message <4D0D408A.2020802@FreeBSD.org>, Doug Barton writes: > On 12/18/2010 09:16, Garrett Wollman wrote: > > In article<4D0C49A2.4000203@FreeBSD.org>, dougb@freebsd.org writes: > > > >> In order to avoid repeating the scenario where we have a version of BIND > >> in the base that is not supported by the vendor I am proposing that we > >> upgrade to BIND 9.6-ESV in FreeBSD RELENG_7. > > > > +1 > > > > All users are going to want working DNSsec soon, if they don't > > already, and that requires 9.6. (In fact, we should start shipping > > with DNSsec enabled by default and the root key pre-configured, if we > > aren't already doing so.) > > I'm not planning to do that in the base for a couple of reasons. The > primary one being that the way BIND 9.6 handles the root key it would > have to be manually re-configured when the root key changes. When that > happens (not IF, it will happen someday) users who have the old > configuration will no longer be able to validate. The other reason I > don't want to do it in the base is that one open source OS vendor has > already been burned by doing something similar, and I don't want to > repeat that mistake. They also failed to put into place procedures to track the trust anchors as they change. OS vendors are in a much better place to do this than nameserver vendors. > What I do plan to do (and hopefully before the upcoming release) is to > make ports for BIND 9.6 and 9.7+ methods of handling DNSSEC so that > users can enable and disable it easily, have a very easy way of being > notified of changes, doing the updates, etc. It's also worth pointing > out that BIND 9.7 and up support RFC 5011 rollover of the root key, > which ICANN is going to perform, which means that people with "old" root > keys in their configurations will be much more resilient. There is still a boot stap issue to be addressed. BIND 9.6 and BIND 9.7 has /etc/bind.keys which needs to be updated as the keys referenced there change. This is just a reference file in BIND 9.6. > hth, > > Doug > > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-stable@FreeBSD.ORG Sun Dec 19 23:33:04 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ED54106566C for ; Sun, 19 Dec 2010 23:33:04 +0000 (UTC) (envelope-from jhelfman@experts-exchange.com) Received: from mail.experts-exchange.com (mail.experts-exchange.com [72.29.183.251]) by mx1.freebsd.org (Postfix) with ESMTP id 7B1958FC08 for ; Sun, 19 Dec 2010 23:33:04 +0000 (UTC) Received: from mail.experts-exchange.com (localhost [127.0.0.1]) by mail.experts-exchange.com (Postfix) with ESMTP id 78E5A9C74DD; Sun, 19 Dec 2010 15:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=e-e.com; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received:received; s=ee; t= 1292800578; x=1294614978; bh=XI0sLQHoalOdV2K1VQe5qeJ3FmHLQqP1L2y usGGTjfE=; b=YCmNuEWP5A4sNSL2OeFROKs8XuYywuNvrKZku348oY9wDtbLz94 CI4igrgu3CCuFy+oA9Mznx0BZq5YUUlTt+dHx729JmEznpndSfmF9Aw1gsTQ78D1 dsQ9rYJcy1i9eov99B4bNkpQ9vfaSvzhlhup5srTEurPjkJYe9VjUSI8= X-Virus-Scanned: amavisd-new at experts-exchange.com Received: from mail.experts-exchange.com ([127.0.0.1]) by mail.experts-exchange.com (mail.experts-exchange.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi33ShVH1N2g; Sun, 19 Dec 2010 15:16:18 -0800 (PST) Received: from experts-exchange.com (unknown [192.168.103.122]) by mail.experts-exchange.com (Postfix) with SMTP id 48EB09C74DC; Sun, 19 Dec 2010 15:16:18 -0800 (PST) Received: (nullmailer pid 45219 invoked by uid 1001); Sun, 19 Dec 2010 23:13:15 -0000 Date: Sun, 19 Dec 2010 15:13:15 -0800 From: Jason Helfman To: Doug Barton Message-ID: <20101219231315.GA45153@eggman.experts-exchange.com> References: <4D0C49A2.4000203@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <4D0C49A2.4000203@FreeBSD.org> X-Operating-System: FreeBSD 8.1-RELEASE X-Living-The-Dream: I love the SLO Life! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org Subject: Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 23:33:04 -0000 On Fri, Dec 17, 2010 at 09:41:54PM -0800, Doug Barton thus spake: >Your feedback on the issue of upgrading BIND in RELENG_7 is welcome. >Sooner is better. :) Does this mean that BIND would be updated in RELENG_7_x, as well, for the supported branches? I understand that they aren't security updates, per se, however it is an EOL issue as you have pointed out. I'm not certain if this could possibly fall under errata, but it does seem appropriate that if the branch isn't reaching EOL, and if third-party software will, it should be dealt with in some way for supporting the community through the RELENG_7_x tag. Just some thoughts... -- Jason Helfman From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 00:30:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F3C01065672 for ; Mon, 20 Dec 2010 00:30:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 0FBCE8FC28 for ; Mon, 20 Dec 2010 00:30:11 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta09.emeryville.ca.mail.comcast.net with comcast id lBnM1f0051bwxycA9CWAuF; Mon, 20 Dec 2010 00:30:10 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta18.emeryville.ca.mail.comcast.net with comcast id lCW81f00B2tehsa8eCW8fM; Mon, 20 Dec 2010 00:30:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 320C49B427; Sun, 19 Dec 2010 16:30:08 -0800 (PST) Date: Sun, 19 Dec 2010 16:30:08 -0800 From: Jeremy Chadwick To: Torfinn Ingolfsen Message-ID: <20101220003008.GA51776@icarus.home.lan> References: <20101219205523.c2de9906.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101219205523.c2de9906.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: The FreeBSD 7.4-BETA1 CD wont boot properly on this machine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 00:30:12 -0000 On Sun, Dec 19, 2010 at 08:55:23PM +0100, Torfinn Ingolfsen wrote: > Hi, > I am trying to install FreeBSD 7.4-BETA1 / amd64 on this[1] machine. > The machine doesn't have a CD drive built-in, so I am using a Plextor > PX-608CU external DVD writer which connects via usb as the CD drive to > install from. I use the FreeBSD-7.4-BETA1-amd64-disc1.iso, which is burned > to a CD. > After powering on the machine, I press F8, get a nice little bootmenu, > select the Plextor drive, and off we go. The kernel boots, and > everything is great. > But, after detecting the hard drive (ad4, ok it's really a SSD) and the > cd drive, it just spits out messages like these: > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config > > and after spitting out one more message (the one for 300 seconds), it just > sits there. Booting with verbose doesn't give men any more messages related > to this. I've tried the -bootonly CD too - it has the same problem. > Yes, the sha256 checksums on the files verifies a-ok, the CD's can be mounted > in FreeBSD, etc. > I even mad a usb memory stick image of the -disc1 and booted the machine from that, > and it has the same problem (the run_interrupt... messages). > > Kicker: the machine boots nicely from a FreeBSD 8.1-release (amd64) CD. > Also tried with a OpenBSD 4.8 (amd64) install CD, yep - it also boots nicely. > > So, any hints on how to get FreeBSD 7.4-BETA1 onto this machine? > > References: > 1) http://sites.google.com/site/tingox/asus_v7-p7h55e This has, historically, been caused by problems with certain firewire chipsets. The workaround has been to disable firewire in the BIOS. I've experienced this on a Shuttle system, and others have on different motherboards as well: http://old.nabble.com/run_interrupt_driven_hooks:-still-waiting-after-300-seconds-for-xpt_config-td23492390.html http://old.nabble.com/-Fwd%3A-run_interrupt_driven_hooks%3A-still-waiting...-for-xpt_config--td23641548.html http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009079.html However, that motherboard doesn't seem to support firewire (but Asus has been known to forget mentioning features on their site before). My advice would be to start disabling certain features in the BIOS anyway, and see if you can track down which one is responsible. Otherwise, run 8.x. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 00:30:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 654221065693 for ; Mon, 20 Dec 2010 00:30:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4B08FC2A for ; Mon, 20 Dec 2010 00:30:51 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta12.emeryville.ca.mail.comcast.net with comcast id lBm51f0041HpZEsACCWqj8; Mon, 20 Dec 2010 00:30:50 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta14.emeryville.ca.mail.comcast.net with comcast id lCWk1f0072tehsa8aCWmA9; Mon, 20 Dec 2010 00:30:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 063769B427; Sun, 19 Dec 2010 16:30:43 -0800 (PST) Date: Sun, 19 Dec 2010 16:30:43 -0800 From: Jeremy Chadwick To: Claus Guttesen Message-ID: <20101220003042.GB51776@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: get ram usage using getrusage() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 00:30:51 -0000 On Sun, Dec 19, 2010 at 10:51:02PM +0100, Claus Guttesen wrote: > I'm trying to read how much ram an app is using reading > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2006-03/msg00246.html > from ru.ru_maxrss. While ru.ru_maxrss gives me used accurate ram-usage > when memory increases it doesn't immediately count down when memory is > released. > > So I tried to get a more accurate reading using this using > /usr/src/sys/kern/kern_clock.c as example: > > struct thread *td; > td = curthread; > p = td->td_proc; > vm = p->p_vmspace; > rss = pgtok(vmspace_resident_count(vm)); > > Curthread is not defined, I searched google but can't find any references. > > But is this the proper way to get an apps memory usage? This question might be better suited for the freebsd-hackers mailing list. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 08:09:18 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB9E61065698 for ; Mon, 20 Dec 2010 08:09:18 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6B8658FC1D for ; Mon, 20 Dec 2010 08:09:18 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id oBK890kc015324; Mon, 20 Dec 2010 09:09:16 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id oBK890AJ015323; Mon, 20 Dec 2010 09:09:00 +0100 (CET) (envelope-from olli) Date: Mon, 20 Dec 2010 09:09:00 +0100 (CET) Message-Id: <201012200809.oBK890AJ015323@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, kometen@gmail.com In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Mon, 20 Dec 2010 09:09:16 +0100 (CET) Cc: Subject: Re: get ram usage using getrusage() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, kometen@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 08:09:19 -0000 Claus Guttesen wrote: > I'm trying to read how much ram an app is using reading Could you phrase that question more precisely? Note that "ram" and "memory" mean different things. Are you interested in the VM mapped to the process? Or do you want to know the amount of physical RAM only? Do you want to include pages that are currently paged to swap? Do you want to include shared pages, or only pages assigned exclusively to your process? Do you want to include memory that was free()ed but is still mapped to your process? And so on ... It might be helpful to know *WHY* you are interested in the app's RAM usage, in order to be able to give the most appropriate advice. > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2006-03/msg00246.html > from ru.ru_maxrss. While ru.ru_maxrss gives me used accurate ram-usage > when memory increases it doesn't immediately count down when memory is > released. What do you mean by "released"? If you mean free(), that doesn't necessarily unmap pages from the process. I think that the current malloc() implementation uses madvise() with MADV_FREE (but I'm not 100% sure). But this is an implementation detail that applications should not care about. > So I tried to get a more accurate reading using this using > /usr/src/sys/kern/kern_clock.c as example: > > struct thread *td; > td = curthread; > p = td->td_proc; > vm = p->p_vmspace; > rss = pgtok(vmspace_resident_count(vm)); > > Curthread is not defined, I searched google but can't find any references. That's a piece of kernel source code. It won't work in user space. > But is this the proper way to get an apps memory usage? I think asking for an app's "memory usage" is not proper in the first place. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "FreeBSD is Yoda, Linux is Luke Skywalker" -- Daniel C. Sobral From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 09:29:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 763381065675 for ; Mon, 20 Dec 2010 09:29:00 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27DFF8FC21 for ; Mon, 20 Dec 2010 09:28:59 +0000 (UTC) Received: by qwj9 with SMTP id 9so2407358qwj.13 for ; Mon, 20 Dec 2010 01:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=FkmuuPX6Fj8Uaup7bP22ujmNJDGfQ7275RAEoSP7yfk=; b=YmvurEKDpsQKhd9P/YeYP0HtcAx5sY37BTdtT6efoTJ5HBpM2HBIFQBIjGm7dJnXkI QUNBoZOlUkGGSiqlooLvTGDazePGpqlzmfNvX1ZITxnA6t3sT9llfN7TpTt++KXELUFM ade6yc7LjwXk9O7nIKaVvhxRyrm8lAfKAMmPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=qsSSjBo5clJ4Zjeo767yjgrPgfxwVsPa9i4eA5EU9oRg8N026jufFiHvrAWy40SOiS Xt0Yp0gblvm1bT3NWxoDMXT7pjXUhfBtUWhILCHMphpW9NyYyq7C+PVSbn2a4CBPBHkJ TmOfUUgMyRQzcFZm/rRDW1ZQOpiRyd6JEZmSc= MIME-Version: 1.0 Received: by 10.229.84.137 with SMTP id j9mr3637754qcl.214.1292837337573; Mon, 20 Dec 2010 01:28:57 -0800 (PST) Received: by 10.229.95.205 with HTTP; Mon, 20 Dec 2010 01:28:57 -0800 (PST) In-Reply-To: <201012200809.oBK890AJ015323@lurza.secnetix.de> References: <201012200809.oBK890AJ015323@lurza.secnetix.de> Date: Mon, 20 Dec 2010 10:28:57 +0100 Message-ID: From: Claus Guttesen To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: get ram usage using getrusage() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 09:29:00 -0000 >=A0> I'm trying to read how much ram an app is using reading > > Could you phrase that question more precisely? > It might be helpful to know *WHY* you are interested > in the app's RAM usage, in order to be able to give the > most appropriate advice. I'm testing the redis key-value-store with the (upcoming 2.2) maxmemory directive and redis - at least on FreeBSD - seems to report less ram used than what is shown in top (SIZE column). ru.ru_maxrss is more accurate at least when redis grows. Redis is useful with an expire in the key (setex) in my case where I want to store as much as possible and retain used key and have redis delete unused keys (LRU) In freeMemoryIfNeeded() redis deletes keys until allocated memory < maxmemory. I used ru.ru_maxrss for testing allocated memory but I ended up deleting all keys since ru.ru_maxrss is not counting down "fast enough", probably for quite reasonable reasons. But not what I wanted. :-) When I used redis zmalloc_used_memory() the server starts swapping. >=A0> struct thread *td; >=A0> td =3D curthread; >=A0> p =3D td->td_proc; >=A0> vm =3D p->p_vmspace; >=A0> rss =3D pgtok(vmspace_resident_count(vm)); > > That's a piece of kernel source code. =A0It won't work in > user space. Saw #ifdef _KERNEL in older versions of sys/pcpu.h that explicitly told it was kernel-related code (http://fxr.watson.org/fxr/source/sys/pcpu.h?v=3DFREEBSD70) but not on 8-stable. > I think asking for an app's "memory usage" is not proper in > the first place. =A0:-) Maybe the reason userland apps have their own accounting system? Can you elaborate? :-) --=20 regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare twitter.com/kometen From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 14:28:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FC971065673; Mon, 20 Dec 2010 14:28:00 +0000 (UTC) (envelope-from timur@bat.ru) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE788FC15; Mon, 20 Dec 2010 14:27:59 +0000 (UTC) Received: by gyf3 with SMTP id 3so1302182gyf.13 for ; Mon, 20 Dec 2010 06:27:59 -0800 (PST) Received: by 10.90.120.12 with SMTP id s12mr5542782agc.21.1292853660849; Mon, 20 Dec 2010 06:01:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.36.18 with HTTP; Mon, 20 Dec 2010 06:00:40 -0800 (PST) In-Reply-To: References: <4d0a2fd5.50f.2ce7dc40.5721f9f0@tms3.com> <20101217102612.GC7694@vpn.offrom.nl> From: "Timur I. Bakeyev" Date: Mon, 20 Dec 2010 15:00:40 +0100 Message-ID: To: Volker.Lendecke@sernet.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Samba List , freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [Samba] Samba upgrade HowTo requested X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 14:28:00 -0000 Hi, Volker! On Sat, Dec 18, 2010 at 10:10 AM, Volker Lendecke wrote: > On Fri, Dec 17, 2010 at 11:26:12AM +0100, Willy Offermans wrote: >> >> 20101026: >> =A0 AFFECTS: users of net/samba35 >> =A0 AUTHOR: Timur Bakeyev >> >> =A0 This is the latest stable release of the Samba3 distribution. It has >> =A0 been extended with the experimental support of the NFS4-like ACLs on >> =A0 ZFS partitions, thanks to the sysutils/libsunacl library by Edward >> =A0 Tomasz Napierala(trasz). This support haven't been tested thoroughly= , >> =A0 so try it on your own risk. > > This looks interesting. I just did a portsnap fetch update > in my FreeBSD 8.1 box, but I don't find that snippet. Where > can I find those patches? There are small patches in the port itself to detect and incorporate libsunacl via configure and build vfs_zfsacl module OOTB. As for the lib itself - it is situated in /usr/ports/sysutils/libsunacl. With regards, Timur. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 14:57:42 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F33DF1065694 for ; Mon, 20 Dec 2010 14:57:41 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9148FC1B for ; Mon, 20 Dec 2010 14:57:41 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id oBKEvOhb035606; Mon, 20 Dec 2010 15:57:40 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id oBKEvObO035605; Mon, 20 Dec 2010 15:57:24 +0100 (CET) (envelope-from olli) Date: Mon, 20 Dec 2010 15:57:24 +0100 (CET) Message-Id: <201012201457.oBKEvObO035605@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, kometen@gmail.com In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Mon, 20 Dec 2010 15:57:40 +0100 (CET) Cc: Subject: Re: get ram usage using getrusage() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, kometen@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 14:57:42 -0000 Claus Guttesen wrote: > >  > I'm trying to read how much ram an app is using reading > > > > Could you phrase that question more precisely? > > It might be helpful to know *WHY* you are interested > > in the app's RAM usage, in order to be able to give the > > most appropriate advice. > > I'm testing the redis key-value-store with the (upcoming 2.2) > maxmemory directive and redis - at least on FreeBSD - seems to report > less ram used than what is shown in top (SIZE column). ru.ru_maxrss is > more accurate at least when redis grows. The "SIZE" column of top(1) is the same as the "VSZ" column of ps(1): It displays the virtual process size. Basically this is the sum of all VM mappings that are assigned to the process. It has _nothing_ to do with the RAM usage. Somewhat more useful for your purpose is the resident set size ("RES" in top, "RSS" in ps). This is the amount of memory actually in use. But this also includes files that were mmap()ed, including libraries shared between many processes. I'm not sure this is what you want. Another problem is that the resident set size does NOT include pages in swap. So, if your process is swapped completely, the RSS is zero, as you can see here: PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 14388 olli 1 5 0 3864K 0K ttyin 0:00 0.00% > Redis is useful with an expire in the key (setex) in my case where I > want to store as much as > possible and retain used key and have redis delete unused keys (LRU) > > In freeMemoryIfNeeded() redis deletes keys until allocated memory < > maxmemory. I used ru.ru_maxrss for testing allocated memory but I > ended up deleting all keys since ru.ru_maxrss is not counting down > "fast enough", probably for quite reasonable reasons. But not what I > wanted. :-) If you free an object with the free() function, the pages are not necessarily unmapped immediately. This depends on the malloc implementation and configuration. Also, even if it is unmapped, the rusage statistics are not updated immediately (this depends on the statclock, see ``sysctl kern.clockrate''). I think that applications should better track their memory usage themselves, so it is portable and independent of implementation details of the VM system and malloc library. That's what most applications do, for example squid. > >  > struct thread *td; > >  > td = curthread; > >  > p = td->td_proc; > >  > vm = p->p_vmspace; > >  > rss = pgtok(vmspace_resident_count(vm)); > > > > That's a piece of kernel source code.  It won't work in > > user space. > > Saw #ifdef _KERNEL in older versions of sys/pcpu.h that explicitly > told it was kernel-related code > (http://fxr.watson.org/fxr/source/sys/pcpu.h?v=FREEBSD70) but not on > 8-stable. Your code snipped was from sys/kern/kern_clock.c which is kernel source. Curthread is a kernel variable (it's part of the per-CPU struct pcpu); it's not directly accessible from userland. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure." -- Eric Allman From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 19:03:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CAD4106566C for ; Mon, 20 Dec 2010 19:03:01 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 2250C8FC17 for ; Mon, 20 Dec 2010 19:03:00 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([80.202.8.11]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LDQ00HQRQ8ZGC10@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Mon, 20 Dec 2010 20:02:59 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LDQ00DFNQ8YOHL1@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Mon, 20 Dec 2010 20:02:59 +0100 (CET) Date: Mon, 20 Dec 2010 20:02:58 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20101220200258.71d8361c.torfinn.ingolfsen@broadpark.no> In-reply-to: References: <20101219205523.c2de9906.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Cc: utisoft@gmail.com Subject: Re: The FreeBSD 7.4-BETA1 CD wont boot properly on this machine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 19:03:01 -0000 On Sun, 19 Dec 2010 21:30:59 +0000 Chris Rees wrote: > > Did you try installing using a different computer onto that hard drive? Nope, not yet. Looking for easier alternatives first. > Is the hardware supported by 7.x > (http://www.freebsd.org/releases/7.3R/hardware.html for pointers) Well, AFAICT, it should work. Nothing odd or non-standard. Again, AFAICT. > Is there a reason you want 7.4 rather than 8.1? The machine already runs 8.1 (see [1]). Sorry for not making that clear. (in my defence, the information is available on the page I referenced in my post, but obviously nobody bothered to check that. Oh well.) Now I want to install 7.4 on another partition, so I can test that release as well. I always try to install as many different releases on a machine as I can / have space for; it has proven useful in the past, and it is my small way to help FreeBSD developers by testing as much (many releases / branches) as I can, on as much hardware as I can. References: 1) http://sites.google.com/site/tingox/asus_v7-p7h55e_freebsd -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 19:18:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E050106564A for ; Mon, 20 Dec 2010 19:18:08 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 349A28FC08 for ; Mon, 20 Dec 2010 19:18:07 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([80.202.8.11]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LDQ00HT3QY6NF00@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Mon, 20 Dec 2010 20:18:06 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LDQ00E8PQY62LG1@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Mon, 20 Dec 2010 20:18:06 +0100 (CET) Date: Mon, 20 Dec 2010 20:18:06 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20101220201806.489d6efb.torfinn.ingolfsen@broadpark.no> In-reply-to: <20101220003008.GA51776@icarus.home.lan> References: <20101219205523.c2de9906.torfinn.ingolfsen@broadpark.no> <20101220003008.GA51776@icarus.home.lan> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: The FreeBSD 7.4-BETA1 CD wont boot properly on this machine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 19:18:08 -0000 On Sun, 19 Dec 2010 16:30:08 -0800 Jeremy Chadwick wrote: > > This has, historically, been caused by problems with certain firewire > chipsets. The workaround has been to disable firewire in the BIOS. Aha! That's a great clue. I haven't seen that particular problem before. > I've experienced this on a Shuttle system, and others have on different > motherboards as well: > > http://old.nabble.com/run_interrupt_driven_hooks:-still-waiting-after-300-seconds-for-xpt_config-td23492390.html > http://old.nabble.com/-Fwd%3A-run_interrupt_driven_hooks%3A-still-waiting...-for-xpt_config--td23641548.html > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009079.html > > However, that motherboard doesn't seem to support firewire (but Asus has > been known to forget mentioning features on their site before). It has firewire. From /var/log/messages under FreeBSD 8.1-stable: fwohci0: <1394 Open Host Controller Interface> mem 0xfbdff800-0xfbdfffff,0xfbdff400-0xfbdff47f,0xfbdff000-0xfbdff07f,0xfbdfec00-0xfbdfec7f irq 19 at device 0.0 on pci1 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:1e:8c:00:00:2c:b8:9a fwohci0: Phy 1394a available S400, 2 ports. So a quick tour into the bios to disable the firewire, then back to boot from the 7.4-BETA1 cd. Yes, it works now, and while I have been wrinting this message, it has just finished installing. Great advice. Thanks! > Otherwise, run 8.x. I do already, see my other posting in this thread. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 20:02:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7AD51065673 for ; Mon, 20 Dec 2010 20:02:57 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6AA158FC0C for ; Mon, 20 Dec 2010 20:02:57 +0000 (UTC) Received: by qwj9 with SMTP id 9so3013228qwj.13 for ; Mon, 20 Dec 2010 12:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=uajgo5xLe+vXkuNTFGP4rTr5T7VU5vflGMVF1yJFzBo=; b=UGHoW+wiQpsWm0WE79iA2/BWTm5AA/q1zi8V4C4+x2nkVqHANyK386iBYjly5pxjBt op06v3VRgHmO2aSYSsP8IbjecyGdFxjxMm+2h93LstJCPx8P1mabelG9pYx4gdHwWEn6 2P52WaNjjQGmo8XRFLdkBum95NIxdc4Xt31tc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=xnCCPsmzPymUyTm5UGUesdqM4YtjXfNG8QQDKBFl7YLlilVe7Lv8H3F8DUaNYhhtyj khu/pU1uXraklmnpaAM/1KJFy4FEdDGgITEGtc1oe09wThpHNkHcHOtERSLK0zfOSsM2 RzrHqmJi8uifNdbdj6nOpCgTTMAdB3lQ7N/fw= MIME-Version: 1.0 Received: by 10.229.245.5 with SMTP id ls5mr4134745qcb.176.1292875376398; Mon, 20 Dec 2010 12:02:56 -0800 (PST) Received: by 10.229.95.205 with HTTP; Mon, 20 Dec 2010 12:02:56 -0800 (PST) In-Reply-To: <201012201457.oBKEvObO035605@lurza.secnetix.de> References: <201012201457.oBKEvObO035605@lurza.secnetix.de> Date: Mon, 20 Dec 2010 21:02:56 +0100 Message-ID: From: Claus Guttesen To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: get ram usage using getrusage() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 20:02:57 -0000 > The "SIZE" column of top(1) is the same as the "VSZ" column > of ps(1): =A0It displays the virtual process size. =A0Basically > this is the sum of all VM mappings that are assigned to the > process. =A0It has _nothing_ to do with the RAM usage. > > Somewhat more useful for your purpose is the resident set > size ("RES" in top, "RSS" in ps). =A0This is the amount of > memory actually in use. =A0But this also includes files that > were mmap()ed, including libraries shared between many > processes. =A0I'm not sure this is what you want. =A0Another > problem is that the resident set size does NOT include > pages in swap. =A0So, if your process is swapped completely, > the RSS is zero, as you can see here: > > =A0PID USERNAME THR PRI NICE =A0SIZE RES STATE TIME =A0 WCPU COMMAND > 14388 olli =A0 =A0 =A0 1 =A0 5 =A0 =A00 3864K =A00K ttyin 0:00 =A00.00% <= zsh> Thank you (vielen dank :-) ) for your explanation. > If you free an object with the free() function, the pages > are not necessarily unmapped immediately. =A0This depends on > the malloc implementation and configuration. =A0Also, even > if it is unmapped, the rusage statistics are not updated > immediately (this depends on the statclock, see ``sysctl > kern.clockrate''). > > I think that applications should better track their memory > usage themselves, so it is portable and independent of > implementation details of the VM system and malloc library. > That's what most applications do, for example squid. I get a clearer picture (had to read your reply a couple of times) but I'm on my way. --=20 regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare twitter.com/kometen From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 20:36:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B6781065788 for ; Mon, 20 Dec 2010 20:36:29 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id B26D38FC08 for ; Mon, 20 Dec 2010 20:36:28 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([80.202.8.11]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LDQ00HO1UKMNF60@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Mon, 20 Dec 2010 21:36:22 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LDQ00EO8UKL2LR1@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Mon, 20 Dec 2010 21:36:22 +0100 (CET) Date: Mon, 20 Dec 2010 21:36:21 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20101220213621.6f0d2dcc.torfinn.ingolfsen@broadpark.no> In-reply-to: <20101220201806.489d6efb.torfinn.ingolfsen@broadpark.no> References: <20101219205523.c2de9906.torfinn.ingolfsen@broadpark.no> <20101220003008.GA51776@icarus.home.lan> <20101220201806.489d6efb.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: The FreeBSD 7.4-BETA1 CD wont boot properly on this machine X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 20:36:29 -0000 On Mon, 20 Dec 2010 20:18:06 +0100 Torfinn Ingolfsen wrote: > So a quick tour into the bios to disable the firewire, then back to boot from the 7.4-BETA1 cd. > Yes, it works now, and while I have been wrinting this message, it has just finished installing. For completeness, I tried enabling the firewire in the bios after I had installed FreeBSD7.4-BETA1. But it didn't work (I didn't think it would), the machine just printed the same error messages as the install CD did. Anyway, dmesg output and other info is available here: http://sites.google.com/site/tingox/asus_v7-p7h55e_freebsd -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 21:59:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFD7F10657DC for ; Mon, 20 Dec 2010 21:59:58 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (gribble.egr.msu.edu [35.9.37.169]) by mx1.freebsd.org (Postfix) with ESMTP id 37D358FC15 for ; Mon, 20 Dec 2010 21:59:55 +0000 (UTC) Received: from gribble (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 2ECAE7FFE2 for ; Mon, 20 Dec 2010 16:59:55 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by gribble (gribble.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHOEK35HVNZ2 for ; Mon, 20 Dec 2010 16:59:55 -0500 (EST) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mail.egr.msu.edu (Postfix) with ESMTPSA id 091287FFD9 for ; Mon, 20 Dec 2010 16:59:54 -0500 (EST) Message-ID: <4D0FD1DA.8090209@egr.msu.edu> Date: Mon, 20 Dec 2010 16:59:54 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101104 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4CF5DEC4.3070901@egr.msu.edu> <1918825226.1032577.1291246386604.JavaMail.root@erie.cs.uoguelph.ca> <20101204233906.GY82436@egr.msu.edu> In-Reply-To: <20101204233906.GY82436@egr.msu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Stale NFS file handles on 8.x amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 21:59:58 -0000 On 12/04/10 18:39, Adam McDougall wrote: > On Wed, Dec 01, 2010 at 06:33:06PM -0500, Rick Macklem (and others) wrote: (various suggestions) > I had to call off the experimentation with live users and resorted to running all IMAP connections from a single NFS client for now. I was causing a little too much of a stir. Here are the things I can remember trying: negnametimeo=0 (no perceived difference) acregmin=0,acregmax=0,acdirmin=0,acdirmax=0 (slowed down imap but otherwise no perceived difference) stopped statd and lockd after changing dovecot to use dotlock (no perceived difference) vfs.lookup_shared=0 (no perceived difference) dovecot 1.1 (no better than 1.2 regarding this issue) Did not try (yet?): udp, nfsv4, freebsd 7 I feel compelled to keep the users happy for now while I look into the nfs director included with dovecot 2.0 designed to keep individual IMAP users on their own server, so I'm taking a stab at the recommended usage with newer software rather than more debugging with previous versions. I may return to other tactics if the future path slows down, I'm still curious why things changed. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 20 23:14:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73AC81065670 for ; Mon, 20 Dec 2010 23:14:33 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 162BF8FC0A for ; Mon, 20 Dec 2010 23:14:32 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id oBKN0NCN087628 for ; Mon, 20 Dec 2010 15:00:23 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id oBKN0Nrx087627; Mon, 20 Dec 2010 15:00:23 -0800 (PST) Date: Mon, 20 Dec 2010 15:00:23 -0800 (PST) From: Matthew Dillon Message-Id: <201012202300.oBKN0Nrx087627@apollo.backplane.com> To: freebsd-stable@freebsd.org Subject: Re: vm.swap_reserved toooooo large? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 23:14:33 -0000 One of the problems with resource management in general is that it has traditionally been per-process, and due to the multiplicative effect (e.g. max-descriptors * limit-per-descriptor), per-process resources cannot be set such that any given user is prevented from DDOSing the system without making them so low that normal programs begin to fail for no good reason. Hence the advent of per-user and other more suitable resource limits, nominally set via sysctl. Even with these, however, it is virtually impossible to protect against a user DDOS. The kernel itself has resource limitations which are fairly easy to blow out... mbufs are usually the easiest to blow up, followed by pipe KVM memory. Filesytems can be blown up too by creating sparse files and mmap()ing them (thus circumventing normal overcommit limitations). Paging just itself, without running the system out of VM, can destroy a machine's performance and be just as effective a DDOS attack as resource starvation is. Virtual memory resources are similarly impacted. Overcommit limiting features have as many downsides as they have upsides. Its an endless argument but I've seen systems blow up with overcommit limits set even more readily than with no (overcommit) limits set. Theoretically overcommit limits make the system more manageable but in actual practice they only work when the application base is written with such limits in mind (and most are not). So for a general purpose unix environment putting limits on overcommit tends to create headaches. To be sure, in a turn-key environment overcommit serves a very important function. In a non-turn-key environment however it will likely create more problems than it will solve. The only way to realistically deal with the mess, if it is important to you, is to partition the systems' real resources and run stuff inside their own virtualized kernels each of which does its own independent resource management and whos I/O on the real system can be well-controlled as an aggregate. Alternatively, creating very large swap partitions work very well to mitigate the more common problems. Swap itself is changing its function. Swap is no longer just used for real memory overcommit (in fact, real memory overcommit is quite uncommon these days). It is now also used for things like tmpfs, temporary virtual disks, meta-data caching, and so forth. These days the minimum amount of swap I configure is 32G and as efficient swap storage gets more cost effective (e.g. SSDs), significantly more. 70G, 110G, etc. It becomes more a matter of being able to detact and act on the DDOS/resource issue BEFORE it gets to the point of killing important processes (definition: whatever is important for the functioning of that particular machine, user-run or root-run), and less a matter of hoping the system will do the right thing when the resource limit is actually reached. Having a lot of swap gives you more time to act. -Matt From owner-freebsd-stable@FreeBSD.ORG Tue Dec 21 08:59:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BD90106564A for ; Tue, 21 Dec 2010 08:59:52 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 73CF48FC0A for ; Tue, 21 Dec 2010 08:59:51 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA01390; Tue, 21 Dec 2010 10:59:43 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PUy4N-000KzQ-F9; Tue, 21 Dec 2010 10:59:43 +0200 Message-ID: <4D106C7F.5090409@freebsd.org> Date: Tue, 21 Dec 2010 10:59:43 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4cfc72a5.3nAjkv8mdrO/NrKQ%perryh@pluto.rain.com> <4CFD0633.9060509@freebsd.org> <4d089a74.vwMJkPEIddt7PIxy%perryh@pluto.rain.com> <4D08AACB.6060306@freebsd.org> <4d09dd2e.iVncbZ/gHBXX0WdL%perryh@pluto.rain.com> <4D09E0F3.5040302@freebsd.org> <4d0dcc58.Z6ITxDmhSuMVmGVR%perryh@pluto.rain.com> In-Reply-To: <4d0dcc58.Z6ITxDmhSuMVmGVR%perryh@pluto.rain.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Tunables (Re: How to debug a double fault? (Re: Could MSGBUF_SIZE be made a loader tunable?)) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 08:59:52 -0000 on 19/12/2010 11:11 perryh@pluto.rain.com said the following: > Andriy Gapon wrote: >> on 16/12/2010 11:34 perryh@pluto.rain.com said the following: >>> Andriy Gapon wrote: >>>> BTW, are you sure that you correctly placed initialization of >>>> msgbufsize ? >>> >>> I am not at all sure of that ... >>> >>> Apart from the name, msgbufsize is set up in exactly the same >>> way and place -- in init_param1() -- as maxswzone and maxbcache. >>> Perhaps that is not early enough ... >> >> I don't see any connection between msgbufsize and maxswzone, >> so I also don't know if that place is early enough. > > The only "connection" is that maxswzone and maxbcache seemed to > be loader tunables that cannot be changed (via sysctl) while the > system is running -- the same usage paradigm I have in mind for > msgbufsize. In other words they are all tunables. We have dozens of them. > I've since found the description of i386 startup in the Architecture > Handbook, and based on that -- and the code in locore.s and machdep.c > -- it certainly _seems_ as if init_param1() should be early enough: > > Practically the first thing that locore.s does after establishing > virtual addressing is to call init386(), and init386() calls > init_param1() long before it either accesses msgbufsize directly > or calls getmemsize() (which uses msgbufsize to allocate space for > the kernel message buffer). Documentation and code are known to get out of sync sometimes. Not saying that this is the case here though... >> Just try to initialize the variable where it's defined and use >> TUNABLE_LONG. > > Is there any documentation on how to use the TUNABLE_* macros, or > on when to use, say, TUNABLE_LONG vs TUNABLE_LONG_FETCH? I found > nothing with their definitions in sys/kernel.h, nor in any of the > base-system manpages, nor in /usr/share/doc/... Another question for which I don't have an answer. So far in my experience TUNABLE_XXX has always sufficed for me, I've never had a reason to use TUNABLE_XXX_FETCH. Technical difference is that TUNABLE_XXX_FETCH is a function (function-like macro) that explicitly fetches tunable's value from kernel environment; while TUNABLE_XXX is a wrapper around SYSINIT that registers the tunable for automatic processing during rather early stage of boot (SI_SUB_TUNABLES). -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Dec 21 09:04:38 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69866106566C for ; Tue, 21 Dec 2010 09:04:38 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4768FC15 for ; Tue, 21 Dec 2010 09:04:36 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.4/8.14.4) with ESMTP id oBL94TAH029724 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Dec 2010 11:04:29 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.4/8.14.4/Submit) id oBL94Ox8029723 for stable@freebsd.org; Tue, 21 Dec 2010 11:04:24 +0200 (SAST) (envelope-from lordcow) Date: Tue, 21 Dec 2010 11:04:24 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20101221090424.GA29240@lordcow.org> References: <20101127132249.GA80611@lordcow.org> <20101206110754.GA82394@lordcow.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101206110754.GA82394@lordcow.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: Re: ZFS raidz recovery X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 09:04:38 -0000 On Mon 2010-12-06 (13:07), Gareth de Vaux wrote: > 'zpool replace' also only works if you physically swap out a disk > at the same port, or replace disk1 with disk2 online. 'zpool remove' > and 'zpool detach' don't remove devices from a raidz. > > So I can recover an array if I have an extra disk to play with, > to use temporarily or to swap out with. If I don't and a disk is > giving trouble I can't drop it from the array, try to do something > with it, and reinsert it. As the ZFS guys point out, you can replace the same disk out if you zero both its EFI labels - about 1MB at the beginning and end of the disk. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 21 10:07:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 732F2106566B for ; Tue, 21 Dec 2010 10:07:34 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id CDEC08FC08 for ; Tue, 21 Dec 2010 10:07:33 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oBLA7UdZ031174; Tue, 21 Dec 2010 16:07:30 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D107C5D.6080409@rdtc.ru> Date: Tue, 21 Dec 2010 16:07:25 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4cfc72a5.3nAjkv8mdrO/NrKQ%perryh@pluto.rain.com> <4CFD0633.9060509@freebsd.org> <4d089a74.vwMJkPEIddt7PIxy%perryh@pluto.rain.com> In-Reply-To: <4d089a74.vwMJkPEIddt7PIxy%perryh@pluto.rain.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, avg@freebsd.org Subject: Re: How to debug a double fault? (Re: Could MSGBUF_SIZE be made a loader tunable?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 10:07:34 -0000 On 15.12.2010 16:37, perryh@pluto.rain.com wrote: > Andriy Gapon wrote: >> on 06/12/2010 07:20 perryh@pluto.rain.com said the following: >>> Would there be some fundamental problem in changing MSGBUF_SIZE >>> from a compiled-in constant to a tunable that could be set at the >>> loader prompt? >>> I didn't see any obvious downside from examining the 8.1-RELEASE >>> code ... >> I also don't immediately see why that wouldn't work. >> Can you try to come up with a patch? > > I came up with what I think is a start, but it has led to: > How do I go about debugging a "Fatal double fault"? You also may checkup the code to not abuse stack. Kernel threads have not much of free stack space and allocating increasing length arrays in stack will lead to double fault. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Dec 21 15:39:40 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94805106566C; Tue, 21 Dec 2010 15:39:39 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id 341BA8FC08; Tue, 21 Dec 2010 15:39:38 +0000 (UTC) Received: from [IPv6:::1] (ruben@erg [IPv6:2a02:898:96::5e8e:f508]) (authenticated bits=0) by erg.verweg.com (8.14.4/8.14.4) with ESMTP id oBLFdWAx079266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 Dec 2010 15:39:37 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host ruben@erg [IPv6:2a02:898:96::5e8e:f508] claimed to be [IPv6:::1] Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ruben van Staveren In-Reply-To: <4D0A09AF.3040005@FreeBSD.org> Date: Tue, 21 Dec 2010 16:39:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <029006A4-B55F-4616-8946-0D4DF64E2D0E@verweg.com> References: <4D0A09AF.3040005@FreeBSD.org> To: Martin Matuska X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]); Tue, 21 Dec 2010 15:39:37 +0000 (UTC) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: New ZFSv28 patchset for 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 15:39:40 -0000 Ok, On 16 Dec 2010, at 13:44, Martin Matuska wrote: > Please test, test, test. Chances are this is the last patchset before > v28 going to HEAD (finally) and after a reasonable testing period into > 8-STABLE. > Especially test new changes, like boot support and sendfile(2) = support. > Also be sure to verify if you can import for existing ZFS pools > (v13-v15) when running v28 or boot from your existing pools. >=20 > Please test the (v13-v15) compatibility layer as well: > Old usereland + new kernel / old kernel + new userland Using v28 kernel+userland seems to work on FreeBSD/amd64, I didn't dare = to mix userland/kernel as that is ill advised by itself when there are = major changes, like this one. I can't seem to use zfs allow/userspace/groupspace. old py-zfs just = dumped core on those commands, recompiling gave my warnings about a = missing solaris.misc module which persisted even after a upgrade to = py26-zfs-1_1. Thanks for keeping up the good work on ZFS in FreeBSD! Best Regards, Ruben= From owner-freebsd-stable@FreeBSD.ORG Tue Dec 21 20:40:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDA681065693 for ; Tue, 21 Dec 2010 20:40:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 58A648FC08 for ; Tue, 21 Dec 2010 20:40:16 +0000 (UTC) Received: (qmail 23605 invoked by uid 399); 21 Dec 2010 20:40:15 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 21 Dec 2010 20:40:15 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D1110AE.7030103@FreeBSD.org> Date: Tue, 21 Dec 2010 12:40:14 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4D0C49A2.4000203@FreeBSD.org> In-Reply-To: <4D0C49A2.4000203@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 20:40:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thanks to everyone who replied, the feedback was very useful. Unfortunately I have missed the deadline for getting this into 7.4, so the current thinking is that I will do the update after the release is cut so that those who need to stay with the RELENG_7 branch through its EOL will at least have the BIND 9.6.x version available 7-stable. I should also mention that regardless of the timing of the update in RELENG_7 I plan to remove the dns/bind94 port when that version of BIND EOLs. This is an intentional departure from how I did it with RELENG_6 and dns/bind9, so I thought it was worth pointing that out. :) hth, Doug - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJNERCuAAoJEFzGhvEaGryEobYIAL84lGO+BvG5vBMhvlbyxjay PJGyN5lIUConmG9pN/mQCHvrGqGO3LrF1oCjXhMLB4PprHyf3fcl+/5YAyNAduhj APy5KZKTwESPvVMLtEsh6FoXdzyyGUwaeUPUoB++vVdO3EGBJ2tNt+mGyW4GXKUB 3tJXRCqzG7IiMAC31Jh8K0GaZ4uIswDWPqtX0UH0UWBrQb2ck4A7MHc4kjdVyDwU Y5P7tanTLPyAf0jJlQ3+AqHV+5+Bl8evVbyHGx3dkXoA4o/+mA4+z4R9hRUiB8X1 49MBPd2l81CeQiJ/gCnqF39VV8whDhenvT8DH4GX0scef4uaW2D/WowX31Hj2aI= =Gwgw -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 10:12:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 361CF106566B for ; Wed, 22 Dec 2010 10:12:05 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id E829D8FC16 for ; Wed, 22 Dec 2010 10:12:04 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PVLfv-0000y6-21 for freebsd-stable@freebsd.org; Wed, 22 Dec 2010 12:12:03 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Dec 2010 12:12:03 +0200 From: Daniel Braniss Message-ID: Subject: panic on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 10:12:05 -0000 the hardware is Sun Fire X2200 M2, and it's discless, PXE booted. this seems to have started sometime before 8.2, and it 'sometimes happens': FreeBSD 8.2-PRERELEASE #15 r4274: Wed Dec 22 09:11:27 IST 2010c40, rbp = 0xffffffff80ef5c60 --- danny@rnd:/home/obj/rnd/r+d/stable/8/sys/HUJI amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2613.40-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f ... SMP: AP CPU #3 Launched! (cd0:ata0:0:0:0): SCSI status: Check Condition cpu3 AP: (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff (cd0: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff ata0:0: timer: 0x000200ef therm: 0x00010000 err: 0x000000f00: pmc: 0x000104000): Error 6, Unretryable error SMP: AP CPU #2 Launched! cd0 at ata0 bus 0 scbus0 target 0 lun 0 cpu2 AP: cd0: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff Removable CD-ROM SCSI-0 device lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff cd0: 33.300MB/s transfers timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 ( pmc: 0x00010400UDMA2, ATAPI 12bytes, ioapic0: routing intpin 3 (PIO 65534bytesISA IRQ 3)) to lapic 1 vector 48 f loiwotaapbilce0 :c lreoaunteirn gs tianrttpeidn 4 (cd0: Attempt to query device size failed: NOT READY, Medium not present ISA IRQ 4) to lapic 2 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 2 vector 49 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 3 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 50 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x10 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808b1581 stack pointer = 0x28:0xffffffff80ef5b20 frame pointer = 0x28:0xffffffff80ef5b50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 trap_fatal() at trap_fatal+0x290 trap_pfault() at trap_pfault+0x28f trap() at trap+0x3df calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff808b1581, rsp = 0xffffffff80ef5b20, rbp = 0xffffffff80ef5b50 --- intr_execute_handlers() at intr_execute_handlers+0x21 lapic_handle_intr() at lapic_handle_intr+0x37 Xapic_isr1() at Xapic_isr1+0xa5 --- interrupt, rip = 0xffffffff808b6cf3, rsp = 0xffffffff80ef5c40, rbp = 0xffffffff80ef5c60 --- spinlock_exit() at spinlock_exit+0x33 ioapic_assign_cpu() at ioapic_assign_cpu+0x123 intr_shuffle_irqs() at intr_shuffle_irqs+0x9d mi_startup() at mi_startup+0x77 btext() at btext+0x2c Uptime: 2s From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 12:03:19 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C2781065672 for ; Wed, 22 Dec 2010 12:03:19 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id 0D3EC8FC17 for ; Wed, 22 Dec 2010 12:03:18 +0000 (UTC) Received: from [192.168.0.93] (f055206104.adsl.alicedsl.de [78.55.206.104]) (authenticated bits=0) by unimail.uni-dortmund.de (8.14.4/8.14.4) with ESMTP id oBMC3G1Z004264 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 22 Dec 2010 13:03:17 +0100 (CET) Message-ID: <4D11E902.3070102@FreeBSD.org> Date: Wed, 22 Dec 2010 13:03:14 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Subject: recent 8.2-STABLE commits break nullfs for tinderbox? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 12:03:19 -0000 Greetings, I'm tracking 8.2-PRERELEASE, and it appears that recent commits to nullfs, zfs, vfs, or thereabouts have broken Tinderbox for me. I'm mounting my ports tree via nullfs, which has been working fine for a year. Any ideas, or further info needed? Best regards Matthias From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 12:41:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41594106566B for ; Wed, 22 Dec 2010 12:41:30 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 01FD98FC0C for ; Wed, 22 Dec 2010 12:41:29 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 5C7A619E030 for ; Wed, 22 Dec 2010 13:41:28 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 10E5019E038 for ; Wed, 22 Dec 2010 13:41:26 +0100 (CET) Message-ID: <4D11F1F5.7050902@quip.cz> Date: Wed, 22 Dec 2010 13:41:25 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 12:41:30 -0000 Hi, the machine in question was upgraded from 7.3 to FreeBSD 8.2-BETA1 i386 GENERIC After this upgrade, i got following mesages in /var/log/messages every hour. The machine is almost idle (for testing only) Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000833 Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, APIC ID 0 Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source DRD Memory Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x236493c0 Dec 21 12:42:26 kavkaz kernel: MCA: Bank 1, Status 0xd400400000000853 Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, APIC ID 0 Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source IRD Memory Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x2a1c9440 Dec 21 12:42:26 kavkaz kernel: MCA: Bank 2, Status 0xd000400000000863 Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, APIC ID 0 Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source PREFETCH Memory Dec 21 12:42:26 kavkaz kernel: MCA: Bank 4, Status 0xdc0e400200000813 Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, APIC ID 0 Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source RD Memory Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x2cac9678 Dec 21 12:42:26 kavkaz kernel: MCA: Misc 0xe00d0fff00000000 Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000833 Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, APIC ID 1 Dec 21 12:42:26 kavkaz kernel: MCA: CPU 1 COR OVER BUSLG Source DRD Memory Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x23649640 Dec 21 12:42:26 kavkaz kernel: MCA: Bank 1, Status 0xd400400000000853 Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, APIC ID 1 Dec 21 12:42:26 kavkaz kernel: MCA: CPU 1 COR OVER BUSLG Source IRD Memory Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x2a1c9440 Dec 21 12:42:26 kavkaz kernel: MCA: Bank 2, Status 0xd000400000000863 Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, APIC ID 1 Dec 21 12:42:26 kavkaz kernel: MCA: CPU 1 COR OVER BUSLG Source PREFETCH Memory Can somebody tell me, what these messages are? Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 12:44:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36886106564A; Wed, 22 Dec 2010 12:44:19 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id E8AC18FC0A; Wed, 22 Dec 2010 12:44:18 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:5570:ff31:c40c:8eac] ([IPv6:2607:f3e0:0:4:5570:ff31:c40c:8eac]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oBMCiH47024621 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 07:44:17 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D11F29F.8060108@sentex.net> Date: Wed, 22 Dec 2010 07:44:15 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Matthias Andree References: <4D11E902.3070102@FreeBSD.org> In-Reply-To: <4D11E902.3070102@FreeBSD.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-stable@freebsd.org Subject: Re: recent 8.2-STABLE commits break nullfs for tinderbox? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 12:44:19 -0000 On 12/22/2010 7:03 AM, Matthias Andree wrote: > Greetings, > > I'm tracking 8.2-PRERELEASE, and it appears that recent commits to nullfs, zfs, > vfs, or thereabouts have broken Tinderbox for me. > > I'm mounting my ports tree via nullfs, which has been working fine for a year. > > Any ideas, or further info needed? Hi, Whats specifically broken ? Two of the freebsd tinderbox machines are RELENG_8 from Dec 3 and they are fine. However, they dont use nullfs, just zfs and ufs. Is it just nullfs thats broken ? What are the errors you are getting ? ---Mike > > Best regards > Matthias > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 13:21:24 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFE281065675 for ; Wed, 22 Dec 2010 13:21:24 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id 6B5918FC41 for ; Wed, 22 Dec 2010 13:21:23 +0000 (UTC) Received: from [192.168.0.93] (f055206104.adsl.alicedsl.de [78.55.206.104]) (authenticated bits=0) by unimail.uni-dortmund.de (8.14.4/8.14.4) with ESMTP id oBMDLLPU025164 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 22 Dec 2010 14:21:22 +0100 (CET) Message-ID: <4D11FB50.5040307@FreeBSD.org> Date: Wed, 22 Dec 2010 14:21:20 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <4D11E902.3070102@FreeBSD.org> <4D11F29F.8060108@sentex.net> In-Reply-To: <4D11F29F.8060108@sentex.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Subject: Re: recent 8.2-STABLE commits break nullfs for tinderbox? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 13:21:24 -0000 Am 22.12.2010 13:44, schrieb Mike Tancsa: > On 12/22/2010 7:03 AM, Matthias Andree wrote: >> Greetings, >> >> I'm tracking 8.2-PRERELEASE, and it appears that recent commits to nullfs, zfs, >> vfs, or thereabouts have broken Tinderbox for me. >> >> I'm mounting my ports tree via nullfs, which has been working fine for a year. >> >> Any ideas, or further info needed? > > Hi, > Whats specifically broken ? Two of the freebsd tinderbox machines are > RELENG_8 from Dec 3 and they are fine. However, they dont use nullfs, > just zfs and ufs. Is it just nullfs thats broken ? What are the errors > you are getting ? I updated after that. mount_nullfs /usr/ports.cvs /usr/local/tinderbox/portstrees/FreeBSD/ports fails with "resource conflict avoided". I'll now rebuild GENERIC from scratch (including "make clean") to see if that helps. Tried switching to NFS, this appears to work now. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 13:29:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23664106566C for ; Wed, 22 Dec 2010 13:29:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 0B1E38FC08 for ; Wed, 22 Dec 2010 13:29:26 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta12.emeryville.ca.mail.comcast.net with comcast id mDGK1f00617UAYkACDVSVY; Wed, 22 Dec 2010 13:29:26 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta13.emeryville.ca.mail.comcast.net with comcast id mDVL1f00D2tehsa8ZDVNBu; Wed, 22 Dec 2010 13:29:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id EEAF89B427; Wed, 22 Dec 2010 05:29:19 -0800 (PST) Date: Wed, 22 Dec 2010 05:29:19 -0800 From: Jeremy Chadwick To: Matthias Andree Message-ID: <20101222132919.GA19916@icarus.home.lan> References: <4D11E902.3070102@FreeBSD.org> <4D11F29F.8060108@sentex.net> <4D11FB50.5040307@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D11FB50.5040307@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org Subject: Re: recent 8.2-STABLE commits break nullfs for tinderbox? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 13:29:27 -0000 On Wed, Dec 22, 2010 at 02:21:20PM +0100, Matthias Andree wrote: > Am 22.12.2010 13:44, schrieb Mike Tancsa: > > On 12/22/2010 7:03 AM, Matthias Andree wrote: > >> Greetings, > >> > >> I'm tracking 8.2-PRERELEASE, and it appears that recent commits to nullfs, zfs, > >> vfs, or thereabouts have broken Tinderbox for me. > >> > >> I'm mounting my ports tree via nullfs, which has been working fine for a year. > >> > >> Any ideas, or further info needed? > > > > Hi, > > Whats specifically broken ? Two of the freebsd tinderbox machines are > > RELENG_8 from Dec 3 and they are fine. However, they dont use nullfs, > > just zfs and ufs. Is it just nullfs thats broken ? What are the errors > > you are getting ? > > I updated after that. > > mount_nullfs /usr/ports.cvs /usr/local/tinderbox/portstrees/FreeBSD/ports fails > with "resource conflict avoided". I'll now rebuild GENERIC from scratch > (including "make clean") to see if that helps. > > Tried switching to NFS, this appears to work now. FWIW, i can't find this error message ("resource conflict avoided") anywhere in /usr/src, /usr/include, nor /usr/ports on RELENG_8 source dated from 2 hours ago. grep -ri "resource conflict" /usr/src does return some results, but nothing that looks identical to the string you posted. Only reason I'm pointing this out: it would be good to find the commit that breaks things for you, if there is such a commit, but we need something to key off of. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 13:57:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B555106566C; Wed, 22 Dec 2010 13:57:52 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 58A778FC19; Wed, 22 Dec 2010 13:57:52 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:5570:ff31:c40c:8eac] ([IPv6:2607:f3e0:0:4:5570:ff31:c40c:8eac]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oBMDvnBW036758 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 08:57:50 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D1203DC.7040105@sentex.net> Date: Wed, 22 Dec 2010 08:57:48 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Matthias Andree References: <4D11E902.3070102@FreeBSD.org> <4D11F29F.8060108@sentex.net> <4D11FB50.5040307@FreeBSD.org> In-Reply-To: <4D11FB50.5040307@FreeBSD.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-stable@freebsd.org Subject: Re: recent 8.2-STABLE commits break nullfs for tinderbox? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 13:57:52 -0000 On 12/22/2010 8:21 AM, Matthias Andree wrote: > Am 22.12.2010 13:44, schrieb Mike Tancsa: >> On 12/22/2010 7:03 AM, Matthias Andree wrote: >>> Greetings, >>> >>> I'm tracking 8.2-PRERELEASE, and it appears that recent commits to nullfs, zfs, >>> vfs, or thereabouts have broken Tinderbox for me. >>> >>> I'm mounting my ports tree via nullfs, which has been working fine for a year. >>> >>> Any ideas, or further info needed? >> >> Hi, >> Whats specifically broken ? Two of the freebsd tinderbox machines are >> RELENG_8 from Dec 3 and they are fine. However, they dont use nullfs, >> just zfs and ufs. Is it just nullfs thats broken ? What are the errors >> you are getting ? > > I updated after that. > > mount_nullfs /usr/ports.cvs /usr/local/tinderbox/portstrees/FreeBSD/ports fails > with "resource conflict avoided". I'll now rebuild GENERIC from scratch > (including "make clean") to see if that helps. Is the error resource deadlock avoided ? or conflict ? EDEADLK Strange, I am able to do this on RELENG_8 i386 from Dec 15th and AMD64 from the 12th 0(ich10)# mount_nullfs /usr/ports /mnt 0(ich10)# mount /dev/ada0s1a on / (ufs, local) devfs on /dev (devfs, local, multilabel) /dev/ada0s1g on /home (ufs, NFS exported, local, soft-updates) /dev/ada0s1f on /tmp (ufs, local, soft-updates) /dev/ada0s1d on /usr (ufs, local, soft-updates) /dev/ada0s1e on /var (ufs, local, soft-updates) /usr/ports on /mnt (nullfs, local) 0(ich10)# ls -l /mnt/ | head total 22888 drwxr-xr-x 69 root wheel - 1536 Dec 14 09:03 . drwxr-xr-x 25 root wheel - 512 Dec 15 16:33 .. -rw-r--r-- 1 root wheel - 19 Jul 14 1997 .cvsignore -rw-r--r-- 1 root wheel - 57038 Sep 29 14:06 CHANGES -rw-r--r-- 1 root wheel - 1498 Dec 31 2009 COPYRIGHT -rw-r--r-- 1 root wheel - 2680 Dec 14 09:03 GIDs -rw-r--r-- 1 root wheel - 21942459 Jul 18 22:23 INDEX-8 -rw-r--r-- 1 root wheel - 9184 Oct 12 11:10 KNOBS -rw-r--r-- 1 root wheel - 32882 Dec 3 13:55 LEGAL 0(ich10)# md5 /mnt/INDEX-8 /usr/ports/INDEX-8 MD5 (/mnt/INDEX-8) = 2dd40914941dadac0afe3e0d86038322 MD5 (/usr/ports/INDEX-8) = 2dd40914941dadac0afe3e0d86038322 0(ich10)# ---Mike From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 14:07:55 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75A971065693 for ; Wed, 22 Dec 2010 14:07:55 +0000 (UTC) (envelope-from ciaby@autistici.org) Received: from rivolta.investici.org (rivolta.investici.org [78.46.89.173]) by mx1.freebsd.org (Postfix) with ESMTP id 3F0D18FC0C for ; Wed, 22 Dec 2010 14:07:54 +0000 (UTC) Received: from vpn8 (vilipendio-vpn.investici.org [172.16.1.4]) by rivolta.investici.org (Postfix) with ESMTP id B0ECE10A593 for ; Wed, 22 Dec 2010 13:48:12 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 22 Dec 2010 15:48:11 +0200 From: ciaby To: Message-ID: <88c5f0ced2411ed60eae361a2de4a047@autistici.org> X-Sender: ciaby@autistici.org User-Agent: A/I Webmail (RoundCube 0.2) Cc: Subject: ZFS v28 on 8.2-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 14:07:55 -0000 I just downloaded and installed the latest zfs v28 patch (this one: http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101218.patch.xz). System boots fine, a 4-disks RAIDZ set get mounted properly, no problems so far. Thanks a lot to all the FreeBSD community for this great piece of software! :-) Ciaby P.S. Can i remove the SSD ZIL without upgrading the pool? From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 14:13:51 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9615106564A for ; Wed, 22 Dec 2010 14:13:51 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id 72BBC8FC0C for ; Wed, 22 Dec 2010 14:13:51 +0000 (UTC) Received: from [192.168.0.93] (f055206104.adsl.alicedsl.de [78.55.206.104]) (authenticated bits=0) by unimail.uni-dortmund.de (8.14.4/8.14.4) with ESMTP id oBMEDn8C011436 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Dec 2010 15:13:50 +0100 (CET) Message-ID: <4D12079B.7020206@FreeBSD.org> Date: Wed, 22 Dec 2010 15:13:47 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D11E902.3070102@FreeBSD.org> <4D11F29F.8060108@sentex.net> <4D11FB50.5040307@FreeBSD.org> <20101222132919.GA19916@icarus.home.lan> In-Reply-To: <20101222132919.GA19916@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: recent 8.2-STABLE commits break nullfs for tinderbox? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 14:13:51 -0000 Am 22.12.2010 14:29, schrieb Jeremy Chadwick: > On Wed, Dec 22, 2010 at 02:21:20PM +0100, Matthias Andree wrote: >> Am 22.12.2010 13:44, schrieb Mike Tancsa: >> > On 12/22/2010 7:03 AM, Matthias Andree wrote: >> >> Greetings, >> >> >> >> I'm tracking 8.2-PRERELEASE, and it appears that recent commits to nullfs, zfs, >> >> vfs, or thereabouts have broken Tinderbox for me. >> >> >> >> I'm mounting my ports tree via nullfs, which has been working fine for a year. >> >> >> >> Any ideas, or further info needed? >> > >> > Hi, >> > Whats specifically broken ? Two of the freebsd tinderbox machines are >> > RELENG_8 from Dec 3 and they are fine. However, they dont use nullfs, >> > just zfs and ufs. Is it just nullfs thats broken ? What are the errors >> > you are getting ? >> >> I updated after that. >> >> mount_nullfs /usr/ports.cvs /usr/local/tinderbox/portstrees/FreeBSD/ports fails >> with "resource conflict avoided". I'll now rebuild GENERIC from scratch >> (including "make clean") to see if that helps. >> >> Tried switching to NFS, this appears to work now. > > FWIW, i can't find this error message ("resource conflict avoided") > anywhere in /usr/src, /usr/include, nor /usr/ports on RELENG_8 source > dated from 2 hours ago. > > grep -ri "resource conflict" /usr/src does return some results, but > nothing that looks identical to the string you posted. Sorry, my fault, was quoting from memory. This is now pasted: mount_nullfs: Resource deadlock avoided > Only reason I'm pointing this out: it would be good to find the commit > that breaks things for you, if there is such a commit, but we need > something to key off of. Provided above. Tests of "kernel rebuilt from scratch" are pending (requires reboot and reconfiguration for nullfs). From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 14:21:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B20C106564A; Wed, 22 Dec 2010 14:21:18 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D44468FC18; Wed, 22 Dec 2010 14:21:17 +0000 (UTC) Received: by qwj9 with SMTP id 9so4951087qwj.13 for ; Wed, 22 Dec 2010 06:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tVJyKPWsxcbFsaHGVjqeRimaF4Nt6juuggBCA/8O4QU=; b=ChTLWRy6DgXJoRtr/qSagDcokNO5SoA1p2iShduiqHFuuyywmUsrj607GhpWMapprz dSklXkl4o2x0uuHETXJpRw7eJMtfdIf+7R/P+InS0bGC7uFiEwtd9VYUNR0OQVjGAFbC fzLy8GOCP24C+mo7cJQkreFIm9LZTNm0U6AVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IGyyU0Z1ctQi+ZzZoEYuzS/q1dRh/dthnt9ZFDqaw6EOFDH41/BJjOff9lKkowXcje +5ABkreV8LQlkJgZEn6kNkHNztZnGBZT1cPKBMv1kaspIOueuA992iW22xBD65JmdoxT nF0zU6JUuAcSBbaCmDSkH6nvmVsqxt9gUN06I= MIME-Version: 1.0 Received: by 10.224.11.68 with SMTP id s4mr6358451qas.385.1293026020328; Wed, 22 Dec 2010 05:53:40 -0800 (PST) Received: by 10.220.175.141 with HTTP; Wed, 22 Dec 2010 05:53:40 -0800 (PST) In-Reply-To: <20101222132919.GA19916@icarus.home.lan> References: <4D11E902.3070102@FreeBSD.org> <4D11F29F.8060108@sentex.net> <4D11FB50.5040307@FreeBSD.org> <20101222132919.GA19916@icarus.home.lan> Date: Wed, 22 Dec 2010 13:53:40 +0000 Message-ID: From: Paul B Mahol To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Matthias Andree Subject: Re: recent 8.2-STABLE commits break nullfs for tinderbox? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 14:21:18 -0000 On 12/22/10, Jeremy Chadwick wrote: > On Wed, Dec 22, 2010 at 02:21:20PM +0100, Matthias Andree wrote: >> Am 22.12.2010 13:44, schrieb Mike Tancsa: >> > On 12/22/2010 7:03 AM, Matthias Andree wrote: >> >> Greetings, >> >> >> >> I'm tracking 8.2-PRERELEASE, and it appears that recent commits to >> >> nullfs, zfs, >> >> vfs, or thereabouts have broken Tinderbox for me. >> >> >> >> I'm mounting my ports tree via nullfs, which has been working fine for >> >> a year. >> >> >> >> Any ideas, or further info needed? >> > >> > Hi, >> > Whats specifically broken ? Two of the freebsd tinderbox machines are >> > RELENG_8 from Dec 3 and they are fine. However, they dont use nullfs, >> > just zfs and ufs. Is it just nullfs thats broken ? What are the errors >> > you are getting ? >> >> I updated after that. >> >> mount_nullfs /usr/ports.cvs /usr/local/tinderbox/portstrees/FreeBSD/ports >> fails >> with "resource conflict avoided". I'll now rebuild GENERIC from scratch >> (including "make clean") to see if that helps. >> >> Tried switching to NFS, this appears to work now. > > FWIW, i can't find this error message ("resource conflict avoided") > anywhere in /usr/src, /usr/include, nor /usr/ports on RELENG_8 source > dated from 2 hours ago. > > grep -ri "resource conflict" /usr/src does return some results, but > nothing that looks identical to the string you posted. > > Only reason I'm pointing this out: it would be good to find the commit > that breaks things for you, if there is such a commit, but we need > something to key off of. Perhaps OP means "resource deadlock avoided"? Such message appears if you try to mount same mount point with nullfs twice - which doesnt have sense. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 14:45:58 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 813EF106566C for ; Wed, 22 Dec 2010 14:45:58 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id 19D6A8FC24 for ; Wed, 22 Dec 2010 14:45:57 +0000 (UTC) Received: from [192.168.0.93] (f055206104.adsl.alicedsl.de [78.55.206.104]) (authenticated bits=0) by unimail.uni-dortmund.de (8.14.4/8.14.4) with ESMTP id oBMEjuvE020010 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 22 Dec 2010 15:45:56 +0100 (CET) Message-ID: <4D120F22.7070105@FreeBSD.org> Date: Wed, 22 Dec 2010 15:45:54 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <4D11E902.3070102@FreeBSD.org> <4D11F29F.8060108@sentex.net> <4D11FB50.5040307@FreeBSD.org> <20101222132919.GA19916@icarus.home.lan> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: recent 8.2-STABLE commits break nullfs for tinderbox? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 14:45:58 -0000 Am 22.12.2010 14:53, schrieb Paul B Mahol: > On 12/22/10, Jeremy Chadwick wrote: >> On Wed, Dec 22, 2010 at 02:21:20PM +0100, Matthias Andree wrote: >>> Am 22.12.2010 13:44, schrieb Mike Tancsa: >>> > On 12/22/2010 7:03 AM, Matthias Andree wrote: >>> >> Greetings, >>> >> >>> >> I'm tracking 8.2-PRERELEASE, and it appears that recent commits to >>> >> nullfs, zfs, >>> >> vfs, or thereabouts have broken Tinderbox for me. >>> >> >>> >> I'm mounting my ports tree via nullfs, which has been working fine for >>> >> a year. >>> >> >>> >> Any ideas, or further info needed? >>> > >>> > Hi, >>> > Whats specifically broken ? Two of the freebsd tinderbox machines are >>> > RELENG_8 from Dec 3 and they are fine. However, they dont use nullfs, >>> > just zfs and ufs. Is it just nullfs thats broken ? What are the errors >>> > you are getting ? >>> >>> I updated after that. >>> >>> mount_nullfs /usr/ports.cvs /usr/local/tinderbox/portstrees/FreeBSD/ports >>> fails >>> with "resource conflict avoided". I'll now rebuild GENERIC from scratch >>> (including "make clean") to see if that helps. >>> >>> Tried switching to NFS, this appears to work now. >> >> FWIW, i can't find this error message ("resource conflict avoided") >> anywhere in /usr/src, /usr/include, nor /usr/ports on RELENG_8 source >> dated from 2 hours ago. >> >> grep -ri "resource conflict" /usr/src does return some results, but >> nothing that looks identical to the string you posted. >> >> Only reason I'm pointing this out: it would be good to find the commit >> that breaks things for you, if there is such a commit, but we need >> something to key off of. > > Perhaps OP means "resource deadlock avoided"? > > Such message appears if you try to mount same mount point with nullfs > twice - which doesnt have sense. Then either tinderbox's check if the directory exists is broken, else it wouldn't retry mounting it, or something else is broken. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 14:59:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21FA21065767 for ; Wed, 22 Dec 2010 14:59:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7726C8FC17 for ; Wed, 22 Dec 2010 14:59:11 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0FF9F46B49; Wed, 22 Dec 2010 09:59:11 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E66D08A027; Wed, 22 Dec 2010 09:59:08 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 22 Dec 2010 09:51:50 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012220951.50493.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 22 Dec 2010 09:59:09 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Re: panic on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 14:59:12 -0000 On Wednesday, December 22, 2010 5:12:03 am Daniel Braniss wrote: > the hardware is Sun Fire X2200 M2, and it's discless, PXE booted. > > this seems to have started sometime before 8.2, and it > 'sometimes happens': > > FreeBSD 8.2-PRERELEASE #15 r4274: Wed Dec 22 09:11:27 IST 2010c40, rbp = > 0xffffffff80ef5c60 --- > danny@rnd:/home/obj/rnd/r+d/stable/8/sys/HUJI amd64 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2613.40-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 > Features=0x178bfbff CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x1f > ... > SMP: AP CPU #3 Launched! > (cd0:ata0:0:0:0): SCSI status: Check Condition > cpu3 AP: > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > (cd0: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > ata0:0: timer: 0x000200ef therm: 0x00010000 err: 0x000000f00: pmc: 0x000104000): > Error 6, Unretryable error > SMP: AP CPU #2 Launched! > cd0 at ata0 bus 0 scbus0 target 0 lun 0 > cpu2 AP: > cd0: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > Removable CD-ROM SCSI-0 device > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > cd0: 33.300MB/s transfers timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 ( pmc: 0x00010400UDMA2, > ATAPI 12bytes, ioapic0: routing intpin 3 (PIO 65534bytesISA IRQ 3)) to lapic 1 vector 48 > f > loiwotaapbilce0 :c lreoaunteirn gs tianrttpeidn > 4 (cd0: Attempt to query device size failed: NOT READY, Medium not present > ISA IRQ 4) to lapic 2 vector 48 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 2 vector 49 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 3 vector 49 > ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 50 > ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x10 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff808b1581 > stack pointer = 0x28:0xffffffff80ef5b20 > frame pointer = 0x28:0xffffffff80ef5b50 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 (swapper) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x187 > trap_fatal() at trap_fatal+0x290 > trap_pfault() at trap_pfault+0x28f > trap() at trap+0x3df > calltrap() at calltrap+0x8 > --- trap 0xc, rip = 0xffffffff808b1581, rsp = 0xffffffff80ef5b20, rbp = 0xffffffff80ef5b50 --- > intr_execute_handlers() at intr_execute_handlers+0x21 > lapic_handle_intr() at lapic_handle_intr+0x37 > Xapic_isr1() at Xapic_isr1+0xa5 > --- interrupt, rip = 0xffffffff808b6cf3, rsp = 0xffffffff80ef5c40, rbp = 0xffffffff80ef5c60 --- > spinlock_exit() at spinlock_exit+0x33 > ioapic_assign_cpu() at ioapic_assign_cpu+0x123 > intr_shuffle_irqs() at intr_shuffle_irqs+0x9d > mi_startup() at mi_startup+0x77 > btext() at btext+0x2c > Uptime: 2s Can you do 'l *intr_execute_handlers+0x21' and 'l *ioapic_assign_cpu+0x123' in 'gdb kernel.debug' of your kernel? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 14:59:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7A251065697 for ; Wed, 22 Dec 2010 14:59:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BB5408FC19 for ; Wed, 22 Dec 2010 14:59:12 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7046846B6C; Wed, 22 Dec 2010 09:59:12 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 828FD8A009; Wed, 22 Dec 2010 09:59:11 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 22 Dec 2010 09:57:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <4D11F1F5.7050902@quip.cz> In-Reply-To: <4D11F1F5.7050902@quip.cz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Message-Id: <201012220957.26854.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 22 Dec 2010 09:59:11 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 14:59:13 -0000 On Wednesday, December 22, 2010 7:41:25 am Miroslav Lachman wrote: > Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000833 > Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, > Status 0x0000000000000000 > Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, > APIC ID 0 > Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source DRD Memory > Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x236493c0 You are getting corrected ECC errors in your RAM. You see them once an hour because we poll the machine check registers once an hour. If this happens constantly you might have a DIMM that is dying? % ~/mcelog --ascii < foo.txt mcelog: Cannot open /dev/mem for DMI decoding: Permission denied HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 0 data cache ADDR 236493c0 Data cache ECC error (syndrome 1c) bit46 = corrected ecc error bit62 = error overflow (multiple errors) bus error 'local node origin, request didn't time out data read mem transaction memory access, level generic' STATUS d40e400000000833 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 67 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 1 instruction cache ADDR 2a1c9440 Instruction cache ECC error bit46 = corrected ecc error bit62 = error overflow (multiple errors) bus error 'local node origin, request didn't time out instruction fetch mem transaction memory access, level generic' STATUS d400400000000853 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 67 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 2 bus unit L2 cache ECC error Bus or cache array error bit46 = corrected ecc error bit62 = error overflow (multiple errors) bus error 'local node origin, request didn't time out prefetch mem transaction memory access, level generic' STATUS d000400000000863 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 67 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge MISC e00d0fff00000000 ADDR 2cac9678 Northbridge RAM ECC error ECC syndrome = 1c bit33 = err cpu1 bit46 = corrected ecc error bit59 = misc error valid bit62 = error overflow (multiple errors) bus error 'local node origin, request didn't time out generic read mem transaction memory access, level generic' STATUS dc0e400200000813 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 67 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 1 0 data cache ADDR 23649640 Data cache ECC error (syndrome 1c) bit46 = corrected ecc error bit62 = error overflow (multiple errors) bus error 'local node origin, request didn't time out data read mem transaction memory access, level generic' STATUS d40e400000000833 MCGSTATUS 0 MCGCAP 105 APICID 1 SOCKETID 0 CPUID Vendor AMD Family 15 Model 67 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 1 1 instruction cache ADDR 2a1c9440 Instruction cache ECC error bit46 = corrected ecc error bit62 = error overflow (multiple errors) bus error 'local node origin, request didn't time out instruction fetch mem transaction memory access, level generic' STATUS d400400000000853 MCGSTATUS 0 MCGCAP 105 APICID 1 SOCKETID 0 CPUID Vendor AMD Family 15 Model 67 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 1 2 bus unit L2 cache ECC error Bus or cache array error bit46 = corrected ecc error bit62 = error overflow (multiple errors) bus error 'local node origin, request didn't time out prefetch mem transaction memory access, level generic' STATUS d000400000000863 MCGSTATUS 0 MCGCAP 105 APICID 1 SOCKETID 0 CPUID Vendor AMD Family 15 Model 67 -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 15:58:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D45B106566C; Wed, 22 Dec 2010 15:58:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7788FC23; Wed, 22 Dec 2010 15:58:57 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PVR5c-0006AQ-Cb; Wed, 22 Dec 2010 17:58:56 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: John Baldwin In-reply-to: <201012220951.50493.jhb@freebsd.org> References: <201012220951.50493.jhb@freebsd.org> Comments: In-reply-to John Baldwin message dated "Wed, 22 Dec 2010 09:51:50 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Dec 2010 17:58:56 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: panic on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 15:58:58 -0000 > On Wednesday, December 22, 2010 5:12:03 am Daniel Braniss wrote: > > the hardware is Sun Fire X2200 M2, and it's discless, PXE booted. > > > > this seems to have started sometime before 8.2, and it > > 'sometimes happens': > > > > FreeBSD 8.2-PRERELEASE #15 r4274: Wed Dec 22 09:11:27 IST 2010c40, rbp = > > 0xffffffff80ef5c60 --- > > danny@rnd:/home/obj/rnd/r+d/stable/8/sys/HUJI amd64 > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2613.40-MHz K8-class CPU) > > Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 > > Features=0x178bfbff > CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > Features2=0x2001 > > AMD Features=0xea500800 > > AMD Features2=0x1f > > ... > > SMP: AP CPU #3 Launched! > > (cd0:ata0:0:0:0): SCSI status: Check Condition > > cpu3 AP: > > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > > ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > (cd0: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > ata0:0: timer: 0x000200ef therm: 0x00010000 err: 0x000000f00: pmc: 0x000104000): > > Error 6, Unretryable error > > SMP: AP CPU #2 Launched! > > cd0 at ata0 bus 0 scbus0 target 0 lun 0 > > cpu2 AP: > > cd0: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > Removable CD-ROM SCSI-0 device > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > cd0: 33.300MB/s transfers timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 ( pmc: 0x00010400UDMA2, > > ATAPI 12bytes, ioapic0: routing intpin 3 (PIO 65534bytesISA IRQ 3)) to lapic 1 vector 48 > > f > > loiwotaapbilce0 :c lreoaunteirn gs tianrttpeidn > > 4 (cd0: Attempt to query device size failed: NOT READY, Medium not present > > ISA IRQ 4) to lapic 2 vector 48 > > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 > > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 > > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 2 vector 49 > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 3 vector 49 > > ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 50 > > ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 > > kernel trap 12 with interrupts disabled > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x10 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0xffffffff808b1581 > > stack pointer = 0x28:0xffffffff80ef5b20 > > frame pointer = 0x28:0xffffffff80ef5b50 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = resume, IOPL = 0 > > current process = 0 (swapper) > > trap number = 12 > > panic: page fault > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > kdb_backtrace() at kdb_backtrace+0x37 > > panic() at panic+0x187 > > trap_fatal() at trap_fatal+0x290 > > trap_pfault() at trap_pfault+0x28f > > trap() at trap+0x3df > > calltrap() at calltrap+0x8 > > --- trap 0xc, rip = 0xffffffff808b1581, rsp = 0xffffffff80ef5b20, rbp = 0xffffffff80ef5b50 --- > > intr_execute_handlers() at intr_execute_handlers+0x21 > > lapic_handle_intr() at lapic_handle_intr+0x37 > > Xapic_isr1() at Xapic_isr1+0xa5 > > --- interrupt, rip = 0xffffffff808b6cf3, rsp = 0xffffffff80ef5c40, rbp = 0xffffffff80ef5c60 --- > > spinlock_exit() at spinlock_exit+0x33 > > ioapic_assign_cpu() at ioapic_assign_cpu+0x123 > > intr_shuffle_irqs() at intr_shuffle_irqs+0x9d > > mi_startup() at mi_startup+0x77 > > btext() at btext+0x2c > > Uptime: 2s > > Can you do 'l *intr_execute_handlers+0x21' and 'l *ioapic_assign_cpu+0x123' > in 'gdb kernel.debug' of your kernel? sure, as soon as it happens, and it aint happening now :-( but when it will happen, I think it won't let me into the debugger - probably will have to recompile thanks danny From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 16:07:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18DBD106564A; Wed, 22 Dec 2010 16:07:02 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id C9CE98FC1C; Wed, 22 Dec 2010 16:07:01 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PVRDQ-0006FI-Dy; Wed, 22 Dec 2010 18:07:00 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: John Baldwin In-reply-to: Your message of Wed, 22 Dec 2010 09:51:50 -0500 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Dec 2010 18:07:00 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: panic on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 16:07:02 -0000 ok, it happened ... Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. but a- the 15 seconds never happen :-) b- there is some magic to get into the debugger but can't find it. danny From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 16:35:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89693106564A for ; Wed, 22 Dec 2010 16:35:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5AE158FC17 for ; Wed, 22 Dec 2010 16:35:08 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E60F846B17; Wed, 22 Dec 2010 11:35:07 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C5A1F8A009; Wed, 22 Dec 2010 11:35:06 -0500 (EST) From: John Baldwin To: Daniel Braniss Date: Wed, 22 Dec 2010 11:18:09 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201012220951.50493.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012221118.09049.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 22 Dec 2010 11:35:06 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: panic on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 16:35:08 -0000 On Wednesday, December 22, 2010 10:58:56 am Daniel Braniss wrote: > > On Wednesday, December 22, 2010 5:12:03 am Daniel Braniss wrote: > > > the hardware is Sun Fire X2200 M2, and it's discless, PXE booted. > > > > > > this seems to have started sometime before 8.2, and it > > > 'sometimes happens': > > > > > > FreeBSD 8.2-PRERELEASE #15 r4274: Wed Dec 22 09:11:27 IST 2010c40, rbp = > > > 0xffffffff80ef5c60 --- > > > danny@rnd:/home/obj/rnd/r+d/stable/8/sys/HUJI amd64 > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2613.40-MHz K8-class CPU) > > > Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 > > > Features=0x178bfbff > > CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > > Features2=0x2001 > > > AMD Features=0xea500800 > > > AMD Features2=0x1f > > > ... > > > SMP: AP CPU #3 Launched! > > > (cd0:ata0:0:0:0): SCSI status: Check Condition > > > cpu3 AP: > > > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > > > ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > (cd0: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > ata0:0: timer: 0x000200ef therm: 0x00010000 err: 0x000000f00: pmc: 0x000104000): > > > Error 6, Unretryable error > > > SMP: AP CPU #2 Launched! > > > cd0 at ata0 bus 0 scbus0 target 0 lun 0 > > > cpu2 AP: > > > cd0: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > Removable CD-ROM SCSI-0 device > > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > cd0: 33.300MB/s transfers timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 ( pmc: 0x00010400UDMA2, > > > ATAPI 12bytes, ioapic0: routing intpin 3 (PIO 65534bytesISA IRQ 3)) to lapic 1 vector 48 > > > f > > > loiwotaapbilce0 :c lreoaunteirn gs tianrttpeidn > > > 4 (cd0: Attempt to query device size failed: NOT READY, Medium not present > > > ISA IRQ 4) to lapic 2 vector 48 > > > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 > > > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 > > > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 2 vector 49 > > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 3 vector 49 > > > ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 50 > > > ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 > > > kernel trap 12 with interrupts disabled > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x10 > > > fault code = supervisor read data, page not present > > > instruction pointer = 0x20:0xffffffff808b1581 > > > stack pointer = 0x28:0xffffffff80ef5b20 > > > frame pointer = 0x28:0xffffffff80ef5b50 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags = resume, IOPL = 0 > > > current process = 0 (swapper) > > > trap number = 12 > > > panic: page fault > > > cpuid = 0 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > kdb_backtrace() at kdb_backtrace+0x37 > > > panic() at panic+0x187 > > > trap_fatal() at trap_fatal+0x290 > > > trap_pfault() at trap_pfault+0x28f > > > trap() at trap+0x3df > > > calltrap() at calltrap+0x8 > > > --- trap 0xc, rip = 0xffffffff808b1581, rsp = 0xffffffff80ef5b20, rbp = 0xffffffff80ef5b50 --- > > > intr_execute_handlers() at intr_execute_handlers+0x21 > > > lapic_handle_intr() at lapic_handle_intr+0x37 > > > Xapic_isr1() at Xapic_isr1+0xa5 > > > --- interrupt, rip = 0xffffffff808b6cf3, rsp = 0xffffffff80ef5c40, rbp = 0xffffffff80ef5c60 --- > > > spinlock_exit() at spinlock_exit+0x33 > > > ioapic_assign_cpu() at ioapic_assign_cpu+0x123 > > > intr_shuffle_irqs() at intr_shuffle_irqs+0x9d > > > mi_startup() at mi_startup+0x77 > > > btext() at btext+0x2c > > > Uptime: 2s > > > > Can you do 'l *intr_execute_handlers+0x21' and 'l *ioapic_assign_cpu+0x123' > > in 'gdb kernel.debug' of your kernel? > > sure, as soon as it happens, and it aint happening now :-( > but when it will happen, I think it won't let me into the debugger > - probably will have to recompile You don't need to trigger the panic, you can just run 'gdb /path/to/kernel.debug' (e.g. 'gdb /usr/obj/usr/src/sys/GENERIC/kernel.debug') -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 04:02:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF5F6106566C for ; Thu, 23 Dec 2010 04:02:43 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id A359E8FC0A for ; Thu, 23 Dec 2010 04:02:43 +0000 (UTC) Received: by gwj21 with SMTP id 21so3623612gwj.13 for ; Wed, 22 Dec 2010 20:02:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=ZJPDY7Sp+F3qTQ/nlr8NTyVPjVnodolo1lvcNgYj4j0=; b=c7UgEazO4i51ez/b8o8L4Iz27NqDj2/DT4DiJ0ulJkkZUTZVKCZSqAMPSJbMQf2jfV 2aWp6SqFntd3xKJJRk8xeRtum2UK0gYV/ucne/9p4nwU0XuJ0BENPbzVrTYPH7hxUnhF Vdcw3+W+bDWrkuB76IX/3DTqXuaEdongbBfjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=FWjyelK6pQ+tXNKRyf7BIiTWLoqtEJk2yBlMyn+s5D0yqwY8CgtomcLUS3+uUYwuWW Y+eZimBcnUiPhhG1Qdk+pqxB8x0qiLeuJ+ra3CYoHUO4+KxEbcrws3s5PKlINlOozH7q CSQc2CbOxIKZSbEVrC6XYgFoijVNS7OH0lRAs= Received: by 10.236.105.172 with SMTP id k32mr14940144yhg.83.1293076962859; Wed, 22 Dec 2010 20:02:42 -0800 (PST) Received: from centel.dataix.local ([99.181.145.144]) by mx.google.com with ESMTPS id l4sm4084700yhl.21.2010.12.22.20.02.40 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Dec 2010 20:02:41 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4D12C9DF.50505@DataIX.net> Date: Wed, 22 Dec 2010 23:02:39 -0500 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101210 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: ciaby References: <88c5f0ced2411ed60eae361a2de4a047@autistici.org> In-Reply-To: <88c5f0ced2411ed60eae361a2de4a047@autistici.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS v28 on 8.2-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 04:02:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/22/2010 08:48, ciaby wrote: > P.S. Can i remove the SSD ZIL without upgrading the pool? Simply put `NO' Longer answer, ZFS will complain at the point where you try to replace the log device or remove it and tell you it was formatted using an older version. OpenSolaris and OpenIndiana both do this so the expectancy of FreeBSD would be to do the same. Regards, - -- jhell,v -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJNEsneAAoJEJBXh4mJ2FR+oY4IAJXHj2b29RxuP9M8Ru0ixFEj T4CVYQ9KFkPxozbb2OZW60lpEGOtJfPuHzzqX5ICAUgFnbeSwM0kMIBDvI2srE2l WvlSNwIB7wTdOac6s74o0IWBh4TBhKBMgFeQ+CLZlMkKoEs2HGwbYYqPg+R/+0gD x+sOQdfiMa1sUwMupl2QOFR5Iq1z+4IGNljVvg43EZ5IvJCc7dGF9vaE1V4gNkdq MNT/OphXOHirngdfphiRb7mdRss3k49NwrSaiPxlg4X+KNHI1BQmpZOLgLE+7Chg M6RfHSgoLkmtl2XK4H7eIivfnQrloU/4RMnou4LG2uPrNHHg/YbfqXjaehajXCc= =ZCc1 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 06:47:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AEB6106564A; Thu, 23 Dec 2010 06:47:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 78B418FC2C; Thu, 23 Dec 2010 06:47:40 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PVexf-000EIU-2R; Thu, 23 Dec 2010 08:47:39 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: John Baldwin In-reply-to: Your message of Wed, 22 Dec 2010 11:18:09 -0500 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Dec 2010 08:47:39 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: panic on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 06:47:41 -0000 > On Wednesday, December 22, 2010 10:58:56 am Daniel Braniss wrote: > > > On Wednesday, December 22, 2010 5:12:03 am Daniel Braniss wrote: > > > > the hardware is Sun Fire X2200 M2, and it's discless, PXE booted. > > > > > > > > this seems to have started sometime before 8.2, and it > > > > 'sometimes happens': > > > > > > > > FreeBSD 8.2-PRERELEASE #15 r4274: Wed Dec 22 09:11:27 IST 2010c40, rbp = > > > > 0xffffffff80ef5c60 --- > > > > danny@rnd:/home/obj/rnd/r+d/stable/8/sys/HUJI amd64 > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2613.40-MHz K8-class CPU) > > > > Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 > > > > Features=0x178bfbff > > > CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > > > Features2=0x2001 > > > > AMD Features=0xea500800 > > > > AMD Features2=0x1f > > > > ... > > > > SMP: AP CPU #3 Launched! > > > > (cd0:ata0:0:0:0): SCSI status: Check Condition > > > > cpu3 AP: > > > > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > > > > ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > > (cd0: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > > ata0:0: timer: 0x000200ef therm: 0x00010000 err: 0x000000f00: pmc: 0x000104000): > > > > Error 6, Unretryable error > > > > SMP: AP CPU #2 Launched! > > > > cd0 at ata0 bus 0 scbus0 target 0 lun 0 > > > > cpu2 AP: > > > > cd0: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > > Removable CD-ROM SCSI-0 device > > > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > > cd0: 33.300MB/s transfers timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 ( pmc: 0x00010400UDMA2, > > > > ATAPI 12bytes, ioapic0: routing intpin 3 (PIO 65534bytesISA IRQ 3)) to lapic 1 vector 48 > > > > f > > > > loiwotaapbilce0 :c lreoaunteirn gs tianrttpeidn > > > > 4 (cd0: Attempt to query device size failed: NOT READY, Medium not present > > > > ISA IRQ 4) to lapic 2 vector 48 > > > > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 > > > > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 > > > > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 2 vector 49 > > > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 3 vector 49 > > > > ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 50 > > > > ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 > > > > kernel trap 12 with interrupts disabled > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid = 0; apic id = 00 > > > > fault virtual address = 0x10 > > > > fault code = supervisor read data, page not present > > > > instruction pointer = 0x20:0xffffffff808b1581 > > > > stack pointer = 0x28:0xffffffff80ef5b20 > > > > frame pointer = 0x28:0xffffffff80ef5b50 > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > processor eflags = resume, IOPL = 0 > > > > current process = 0 (swapper) > > > > trap number = 12 > > > > panic: page fault > > > > cpuid = 0 > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > kdb_backtrace() at kdb_backtrace+0x37 > > > > panic() at panic+0x187 > > > > trap_fatal() at trap_fatal+0x290 > > > > trap_pfault() at trap_pfault+0x28f > > > > trap() at trap+0x3df > > > > calltrap() at calltrap+0x8 > > > > --- trap 0xc, rip = 0xffffffff808b1581, rsp = 0xffffffff80ef5b20, rbp = 0xffffffff80ef5b50 --- > > > > intr_execute_handlers() at intr_execute_handlers+0x21 > > > > lapic_handle_intr() at lapic_handle_intr+0x37 > > > > Xapic_isr1() at Xapic_isr1+0xa5 > > > > --- interrupt, rip = 0xffffffff808b6cf3, rsp = 0xffffffff80ef5c40, rbp = 0xffffffff80ef5c60 --- > > > > spinlock_exit() at spinlock_exit+0x33 > > > > ioapic_assign_cpu() at ioapic_assign_cpu+0x123 > > > > intr_shuffle_irqs() at intr_shuffle_irqs+0x9d > > > > mi_startup() at mi_startup+0x77 > > > > btext() at btext+0x2c > > > > Uptime: 2s > > > > > > Can you do 'l *intr_execute_handlers+0x21' and 'l *ioapic_assign_cpu+0x123' > > > in 'gdb kernel.debug' of your kernel? > > > > sure, as soon as it happens, and it aint happening now :-( > > but when it will happen, I think it won't let me into the debugger > > - probably will have to recompile > > You don't need to trigger the panic, you can just run > 'gdb /path/to/kernel.debug' (e.g. > 'gdb /usr/obj/usr/src/sys/GENERIC/kernel.debug') sorry, missed the gdb part. gdb /d/7/boot/kernel/kernel ... (gdb) l *intr_execute_handlers+0x21 0xffffffff808b1581 is in intr_execute_handlers (/r+d/stable/8/sys/amd64/amd64/i ntr_machdep.c:243). 238 * We count software interrupts when we process them. The 239 * code here follows previous practice, but there's an 240 * argument for counting hardware interrupts when they're 241 * processed too. 242 */ 243 (*isrc->is_count)++; 244 PCPU_INC(cnt.v_intr); 245 246 ie = isrc->is_event; 247 (gdb) l *ioapic_assign_cpu+0x123 0xffffffff808b29c3 is in ioapic_assign_cpu (/r+d/stable/8/sys/amd64/amd64/io_ap ic.c:383). 378 379 /* 380 * Free the old vector after the new one is established. This is done 381 * to prevent races where we could miss an interrupt. 382 */ 383 if (old_vector) { 384 if (isrc->is_handlers > 0) 385 apic_disable_vector(old_id, old_vector); 386 apic_free_vector(old_id, old_vector, intpin->io_irq); 387 } BTW, the config has makeoptions DEBUG=-g but I don't see no kernel.debug (searched the obj directory, and only found old versions) danny From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 08:27:15 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C62F1065670; Thu, 23 Dec 2010 08:27:15 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id A8BE58FC17; Thu, 23 Dec 2010 08:27:14 +0000 (UTC) Received: from [IPv6:::1] (ruben@erg [IPv6:2a02:898:96::5e8e:f508]) (authenticated bits=0) by erg.verweg.com (8.14.4/8.14.4) with ESMTP id oBN8R8hO060691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 23 Dec 2010 08:27:13 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host ruben@erg [IPv6:2a02:898:96::5e8e:f508] claimed to be [IPv6:::1] Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ruben van Staveren In-Reply-To: <4D0A09AF.3040005@FreeBSD.org> Date: Thu, 23 Dec 2010 09:27:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D0A09AF.3040005@FreeBSD.org> To: Martin Matuska X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]); Thu, 23 Dec 2010 08:27:13 +0000 (UTC) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Updated py-zfs ? Re: New ZFSv28 patchset for 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 08:27:15 -0000 Hi, On 16 Dec 2010, at 13:44, Martin Matuska wrote: > Hi everyone, >=20 > following the announcement of Pawel Jakub Dawidek (pjd@FreeBSD.org) I = am > providing a ZFSv28 testing patch for 8-STABLE. Where can I find an updated py-zfs so that zfs = (un)allow/userspace/groupspace can be tested ? Regards, Ruben From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 08:58:57 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4895106566B; Thu, 23 Dec 2010 08:58:57 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id 6BC6C8FC14; Thu, 23 Dec 2010 08:58:57 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 94F5C1322B6; Thu, 23 Dec 2010 09:58:56 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dT4Gf1tTh0FT; Thu, 23 Dec 2010 09:58:54 +0100 (CET) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 8AC4D1322AE; Thu, 23 Dec 2010 09:58:54 +0100 (CET) Message-ID: <4D130F4E.3040701@FreeBSD.org> Date: Thu, 23 Dec 2010 09:58:54 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ruben van Staveren References: <4D0A09AF.3040005@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Updated py-zfs ? Re: New ZFSv28 patchset for 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 08:58:57 -0000 I have updated the py-zfs port right now so it should work with v28, too. The problem was a non-existing solaris.misc module, I had to patch and remove references to this module. Cheers, mm Dňa 23.12.2010 09:27, Ruben van Staveren wrote / napísal(a): > Hi, > > On 16 Dec 2010, at 13:44, Martin Matuska wrote: > >> Hi everyone, >> >> following the announcement of Pawel Jakub Dawidek (pjd@FreeBSD.org) I am >> providing a ZFSv28 testing patch for 8-STABLE. > > Where can I find an updated py-zfs so that zfs (un)allow/userspace/groupspace can be tested ? > > Regards, > Ruben > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 09:45:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 313811065693 for ; Thu, 23 Dec 2010 09:45:02 +0000 (UTC) (envelope-from alexkozlov0@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id ACCD68FC0C for ; Thu, 23 Dec 2010 09:45:01 +0000 (UTC) Received: by bwz12 with SMTP id 12so237330bwz.13 for ; Thu, 23 Dec 2010 01:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=Yt2ZFuteViJb3X1MQODCRSj7mOhV5JIS2RfQloS9Zf4=; b=PclI8QjD4/0UiSiVmP7P0exYjuU0P78kC3dLlxLJ5ySQ81j69BKfRHa6zmxQGpm3pO XavFpFzUHpjAgIC679XJEEg1Z0fpAMpnDF/VXrA21jJv0cxE4+36KRr6nzvo1joSE3DH 3dbP4T51QYctBp2S6Otb8oG0Hado6JcJ4tN7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=upiEP3hlx5Ugz8D9hAsTKGUhg7WsKLbz6CR6GIWW/HP6JrBULGFiQNVlQSRXa+grg0 3fNBSefGqXWPJrpGMB/wJW0Xum+NqRafPLgkXBcss/wdH3mayCmF52epGN2KqgoKVtqv Q0Vd8tBKpMwx69J5ZHs/E0jaTJyFkKGEfR3zA= Received: by 10.204.63.206 with SMTP id c14mr37235bki.95.1293095751276; Thu, 23 Dec 2010 01:15:51 -0800 (PST) Received: from ravenloft.kiev.ua (ravenloft.kiev.ua [94.244.131.95]) by mx.google.com with ESMTPS id b6sm4583950bkb.22.2010.12.23.01.15.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Dec 2010 01:15:50 -0800 (PST) Sender: Alex Kozlov Date: Thu, 23 Dec 2010 11:15:17 +0200 From: Alex Kozlov To: freebsd-stable@freebsd.org, spam@rm-rf.kiev.ua Message-ID: <20101223091517.GA2591@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: 8.2-PRERELEASE: bsdtar does not recognise xz -z9 compression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 09:45:02 -0000 Hi, stable Can anyone reproduce this? $uname FreeBSD 8.2-PRERELEASE #0: Thu Dec 23 10:11:09 i386 $cd /tmp $dd if=/dev/random of=junk bs=1024 count=1 1+0 records in 1+0 records out 1024 bytes transferred in 0.000077 secs (13297112 bytes/sec) $tar cvf junk.tar junk a junk $xz -z9ck junk.tar >junk-z9.tar.xz $xz -ck junk.tar >junk.tar.xz $file junk.tar.xz junk-z9.tar.xz junk.tar.xz: XZ compressed data junk-z9.tar.xz: XZ compressed data $tar tvf junk.tar.xz -rw-r--r-- 0 kozlov kozlov 1024 Dec 23 10:52 junk $tar tvf junk-z9.tar.xz tar: Unrecognized archive format tar: Error exit delayed from previous errors. $xzcat junk.tar.xz>1 $xzcat junk-z9.tar.xz>2 $md5 -r junk.tar 1 2 d2f8de384f6dc1b3969c76ce7fe6ff00 junk.tar d2f8de384f6dc1b3969c76ce7fe6ff00 1 d2f8de384f6dc1b3969c76ce7fe6ff00 2 -- Adios From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 09:46:33 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ABB31065679; Thu, 23 Dec 2010 09:46:33 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id A347A8FC1E; Thu, 23 Dec 2010 09:46:32 +0000 (UTC) Received: from [IPv6:::1] (ruben@erg [IPv6:2a02:898:96::5e8e:f508]) (authenticated bits=0) by erg.verweg.com (8.14.4/8.14.4) with ESMTP id oBN9kQ21066000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 23 Dec 2010 09:46:31 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host ruben@erg [IPv6:2a02:898:96::5e8e:f508] claimed to be [IPv6:::1] Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ruben van Staveren In-Reply-To: <4D130F4E.3040701@FreeBSD.org> Date: Thu, 23 Dec 2010 10:46:20 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1779BD6F-12D5-434E-99FA-BB33DC273998@verweg.com> References: <4D0A09AF.3040005@FreeBSD.org> <4D130F4E.3040701@FreeBSD.org> To: Martin Matuska X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]); Thu, 23 Dec 2010 09:46:31 +0000 (UTC) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Updated py-zfs ? Re: New ZFSv28 patchset for 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 09:46:33 -0000 Thanks, I'm going to check it out! On 23 Dec 2010, at 9:58, Martin Matuska wrote: > I have updated the py-zfs port right now so it should work with v28, > too. The problem was a non-existing solaris.misc module, I had to patch > and remove references to this module. > > Cheers, > mm > Regards, Ruben From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 10:30:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A209D1065674 for ; Thu, 23 Dec 2010 10:30:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE648FC1D for ; Thu, 23 Dec 2010 10:30:47 +0000 (UTC) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta09.westchester.pa.mail.comcast.net with comcast id maJF1f0050QuhwU59aWoMZ; Thu, 23 Dec 2010 10:30:48 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta02.westchester.pa.mail.comcast.net with comcast id maWb1f00A2tehsa3NaWfiq; Thu, 23 Dec 2010 10:30:45 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 232E29B427; Thu, 23 Dec 2010 02:30:34 -0800 (PST) Date: Thu, 23 Dec 2010 02:30:34 -0800 From: Jeremy Chadwick To: Alex Kozlov Message-ID: <20101223103034.GA46413@icarus.home.lan> References: <20101223091517.GA2591@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101223091517.GA2591@ravenloft.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: 8.2-PRERELEASE: bsdtar does not recognise xz -z9 compression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 10:30:48 -0000 On Thu, Dec 23, 2010 at 11:15:17AM +0200, Alex Kozlov wrote: > Hi, stable > > Can anyone reproduce this? > > $uname > FreeBSD 8.2-PRERELEASE #0: Thu Dec 23 10:11:09 i386 > $cd /tmp > $dd if=/dev/random of=junk bs=1024 count=1 > 1+0 records in > 1+0 records out > 1024 bytes transferred in 0.000077 secs (13297112 bytes/sec) > $tar cvf junk.tar junk > a junk > $xz -z9ck junk.tar >junk-z9.tar.xz > $xz -ck junk.tar >junk.tar.xz > $file junk.tar.xz junk-z9.tar.xz > junk.tar.xz: XZ compressed data > junk-z9.tar.xz: XZ compressed data > $tar tvf junk.tar.xz > -rw-r--r-- 0 kozlov kozlov 1024 Dec 23 10:52 junk > $tar tvf junk-z9.tar.xz > tar: Unrecognized archive format > tar: Error exit delayed from previous errors. > $xzcat junk.tar.xz>1 > $xzcat junk-z9.tar.xz>2 > $md5 -r junk.tar 1 2 > d2f8de384f6dc1b3969c76ce7fe6ff00 junk.tar > d2f8de384f6dc1b3969c76ce7fe6ff00 1 > d2f8de384f6dc1b3969c76ce7fe6ff00 2 I can reproduce this problem on RELENG_8 dated November 27th, with libarchive.so.5 confirmed to be linked to liblzma.so.5. The problem happens with any xz compression level 7 or higher. Verification: $ for i in {1..9}; do echo "==> Testing compression level $i" ; rm -f junk* ; dd if=/dev/random of=junk bs=1024 count=1 2>/dev/null ; tar cf junk.tar junk ; xz -z$i -ck junk.tar > junk.tar.xz ; file -z junk.tar.xz ; tar tvf junk.tar.xz ; echo ; done ==> Testing compression level 1 junk.tar.xz: POSIX tar archive (XZ compressed data) -rw------- 0 jdc users 1024 23 Dec 02:30 junk ==> Testing compression level 2 junk.tar.xz: POSIX tar archive (XZ compressed data) -rw------- 0 jdc users 1024 23 Dec 02:30 junk ==> Testing compression level 3 junk.tar.xz: POSIX tar archive (XZ compressed data) -rw------- 0 jdc users 1024 23 Dec 02:30 junk ==> Testing compression level 4 junk.tar.xz: POSIX tar archive (XZ compressed data) -rw------- 0 jdc users 1024 23 Dec 02:30 junk ==> Testing compression level 5 junk.tar.xz: POSIX tar archive (XZ compressed data) -rw------- 0 jdc users 1024 23 Dec 02:30 junk ==> Testing compression level 6 junk.tar.xz: POSIX tar archive (XZ compressed data) -rw------- 0 jdc users 1024 23 Dec 02:30 junk ==> Testing compression level 7 junk.tar.xz: POSIX tar archive (XZ compressed data) tar: Unrecognized archive format tar: Error exit delayed from previous errors. ==> Testing compression level 8 junk.tar.xz: POSIX tar archive (XZ compressed data) tar: Unrecognized archive format tar: Error exit delayed from previous errors. ==> Testing compression level 9 junk.tar.xz: POSIX tar archive (XZ compressed data) tar: Unrecognized archive format tar: Error exit delayed from previous errors. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 10:38:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 303BC106566C for ; Thu, 23 Dec 2010 10:38:53 +0000 (UTC) (envelope-from alexkozlov0@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AEFC28FC17 for ; Thu, 23 Dec 2010 10:38:52 +0000 (UTC) Received: by bwz12 with SMTP id 12so265705bwz.13 for ; Thu, 23 Dec 2010 02:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=a5XwTAkZRjyArvmq/mXxeZiS3tSeg2jGmK02U9kQF4M=; b=qOj154UtZbsYpp4kIqp9t2BtLrg/+pDSw/UlW+lG486YO46MyU+2WHv3OR+wPXcrf6 LB8f6UClRmMpf22X1IcR983qoU/mRHXuO4Of+3cE9kXUolBOaWZxKJiqTFo2NR0b5RzC nYlTZKxBnJToh7H2M0elAMMU4d2FhWQUj3B3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=NVg6Gi41DsDOV4It9AcsmwHuI8iPOR2/Z0WPrF/v3XWDn4VAYcjdsELcRgmKSRVT20 9UiMoBUSLp5mPoKOOZhCgg4tsochrYTg63HeIHG0B58293kWM2sEEQV46JzVUO34Q9pq lPEFeVGX5/TVVb1WkoI5/2TX15Lsaqs4wVx9M= Received: by 10.204.72.199 with SMTP id n7mr113563bkj.8.1293100731593; Thu, 23 Dec 2010 02:38:51 -0800 (PST) Received: from ravenloft.kiev.ua (ravenloft.kiev.ua [94.244.131.95]) by mx.google.com with ESMTPS id b17sm5561021bku.20.2010.12.23.02.38.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Dec 2010 02:38:50 -0800 (PST) Sender: Alex Kozlov Date: Thu, 23 Dec 2010 12:38:18 +0200 From: Alex Kozlov To: Jeremy Chadwick , freebsd-stable@freebsd.org, spam@rm-rf.kiev.ua Message-ID: <20101223103818.GA5275@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: Re: 8.2-PRERELEASE: bsdtar does not recognise xz -z9 compression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 10:38:53 -0000 On Thu, Dec 23, 2010 at 02:30:34AM -0800, Jeremy Chadwick wrote: > On Thu, Dec 23, 2010 at 11:15:17AM +0200, Alex Kozlov wrote: >> Hi, stable >> >> Can anyone reproduce this? >> >> $uname >> FreeBSD 8.2-PRERELEASE #0: Thu Dec 23 10:11:09 i386 >> $cd /tmp >> $dd if=/dev/random of=junk bs=1024 count=1 >> 1+0 records in >> 1+0 records out >> 1024 bytes transferred in 0.000077 secs (13297112 bytes/sec) >> $tar cvf junk.tar junk >> a junk >> $xz -z9ck junk.tar >junk-z9.tar.xz >> $xz -ck junk.tar >junk.tar.xz >> $file junk.tar.xz junk-z9.tar.xz >> junk.tar.xz: XZ compressed data >> junk-z9.tar.xz: XZ compressed data >> $tar tvf junk.tar.xz >> -rw-r--r-- 0 kozlov kozlov 1024 Dec 23 10:52 junk >> $tar tvf junk-z9.tar.xz >> tar: Unrecognized archive format >> tar: Error exit delayed from previous errors. >> $xzcat junk.tar.xz>1 >> $xzcat junk-z9.tar.xz>2 >> $md5 -r junk.tar 1 2 >> d2f8de384f6dc1b3969c76ce7fe6ff00 junk.tar >> d2f8de384f6dc1b3969c76ce7fe6ff00 1 >> d2f8de384f6dc1b3969c76ce7fe6ff00 2 > > I can reproduce this problem on RELENG_8 dated November 27th, with > libarchive.so.5 confirmed to be linked to liblzma.so.5. > > The problem happens with any xz compression level 7 or higher. Yes, bsdtar from STABLE (bsdtar 2.7.0 - libarchive 2.7.0) autodetects xz up to -z6 (default), bsdtar from CURRENT (bsdtar 2.8.3 - libarchive 2.7.901a) recognizes xz with any compression level. $ls -l junk.tar.xz junk-z9.tar.xz -rw-r--r-- 1 kozlov kozlov 1200 Dec 23 11:02 junk-z9.tar.xz -rw-r--r-- 1 kozlov kozlov 1200 Dec 23 11:02 junk.tar.xz $cmp -x junk.tar.xz junk-z9.tar.xz 00000010 16 1c 00000014 74 10 00000015 2f cf 00000016 e5 58 00000017 a3 cc -- Adios From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 12:43:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82132106564A for ; Thu, 23 Dec 2010 12:43:47 +0000 (UTC) (envelope-from alexkozlov0@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 028248FC12 for ; Thu, 23 Dec 2010 12:43:46 +0000 (UTC) Received: by bwz12 with SMTP id 12so343754bwz.13 for ; Thu, 23 Dec 2010 04:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=gEKjjYc45mQglZyoCSsDf+ga0WrfeUD4p3RlC1UPc4w=; b=OBpIglzOce4gXTAIJlDIYddneCyynImRej/Wd/hvr7nstErFmM0L5W/fGMS+dh0922 wyyAiQgP1v/eAm7as/MQyb6JF48M75uWPAZjbefIfLoKtkdvegUDGQQ8UuDiN2BqjtPG zS0lN14N7piLtuKV2J4s9WM9R9Zhanc3ZpN/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=cv3Ybs4K5CJvpGG8+eRhYjCpda0UlkOamW8+4kCd6OOUgAgs16xf3Bcykz2fz0fJlb jPBB3Zp8K9srvNUwo5uude87cNBeTb/7XSO14akBzLfIg/8Ndrx4N817/x1gUXPH//48 /H8mhPo4p9AHyyRXiRQ47PeGdFyewAWdb7JfA= Received: by 10.204.98.12 with SMTP id o12mr7110775bkn.32.1293108225926; Thu, 23 Dec 2010 04:43:45 -0800 (PST) Received: from ravenloft.kiev.ua (ravenloft.kiev.ua [94.244.131.95]) by mx.google.com with ESMTPS id 12sm5631315bki.19.2010.12.23.04.43.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Dec 2010 04:43:45 -0800 (PST) Sender: Alex Kozlov Date: Thu, 23 Dec 2010 14:43:12 +0200 From: Alex Kozlov To: Jeremy Chadwick , freebsd-stable@freebsd.org, spam@rm-rf.kiev.ua Message-ID: <20101223124312.GA10405@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline Cc: Subject: Re: 8.2-PRERELEASE: bsdtar does not recognise xz -z9 compression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 12:43:47 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, stable Possible fix for this issue. (MFC r201167): -- Adios --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.txt" Index: lib/libarchive/archive_read_support_compression_xz.c @@ -48,6 +48,7 @@ #endif #include "archive.h" +#include "archive_endian.h" #include "archive_private.h" #include "archive_read_private.h" @@ -205,37 +206,100 @@ { const unsigned char *buffer; ssize_t avail; + uint32_t dicsize; + uint64_t uncompressed_size; int bits_checked; (void)self; /* UNUSED */ - buffer = __archive_read_filter_ahead(filter, 6, &avail); + buffer = __archive_read_filter_ahead(filter, 14, &avail); if (buffer == NULL) return (0); - /* First byte of raw LZMA stream is always 0x5d. */ + /* First byte of raw LZMA stream is commonly 0x5d. + * The first byte is a special number, which consists of + * three parameters of LZMA compression, a number of literal + * context bits(which is from 0 to 8, default is 3), a number + * of literal pos bits(which is from 0 to 4, default is 0), + * a number of pos bits(which is from 0 to 4, default is 2). + * The first byte is made by + * (pos bits * 5 + literal pos bit) * 9 + * literal contest bit, + * and so the default value in this field is + * (2 * 5 + 0) * 9 + 3 = 0x5d. + * lzma of LZMA SDK has options to change those parameters. + * It means a range of this field is from 0 to 224. And lzma of + * XZ Utils with option -e records 0x5e in this field. */ + /* NOTE: If this checking of the first byte increases false + * recognition, we should allow only 0x5d and 0x5e for the first + * byte of LZMA stream. */ bits_checked = 0; - if (buffer[0] != 0x5d) - return (0); - bits_checked += 8; - - /* Second through fifth bytes are dictionary code, stored in - * little-endian order. The two least-significant bytes are - * always zero. */ - if (buffer[1] != 0 || buffer[2] != 0) + if (buffer[0] > (4 * 5 + 4) * 9 + 8) return (0); - bits_checked += 16; - - /* ??? TODO: Fix this. ??? */ - /* NSIS format check uses this, but I've seen tar.lzma - * archives where this byte is 0xff, not 0. Can it - * ever be anything other than 0 or 0xff? - */ -#if 0 - if (buffer[5] != 0) + /* Most likely value in the first byte of LZMA stream. */ + if (buffer[0] == 0x5d || buffer[0] == 0x5e) + bits_checked += 8; + + /* Sixth through fourteenth bytes are uncompressed size, + * stored in little-endian order. `-1' means uncompressed + * size is unknown and lzma of XZ Utils always records `-1' + * in this field. */ + uncompressed_size = archive_le64dec(buffer+5); + if (uncompressed_size == (uint64_t)ARCHIVE_LITERAL_LL(-1)) + bits_checked += 64; + + /* Second through fifth bytes are dictionary size, stored in + * little-endian order. The minimum dictionary size is + * 1 << 12(4KiB) which the lzma of LZMA SDK uses with option + * -d12 and the maxinam dictionary size is 1 << 27(128MiB) + * which the one uses with option -d27. + * NOTE: A comment of LZMA SDK source code says this dictionary + * range is from 1 << 12 to 1 << 30. */ + dicsize = archive_le32dec(buffer+1); + switch (dicsize) { + case 0x00001000:/* lzma of LZMA SDK option -d12. */ + case 0x00002000:/* lzma of LZMA SDK option -d13. */ + case 0x00004000:/* lzma of LZMA SDK option -d14. */ + case 0x00008000:/* lzma of LZMA SDK option -d15. */ + case 0x00010000:/* lzma of XZ Utils option -0 and -1. + * lzma of LZMA SDK option -d16. */ + case 0x00020000:/* lzma of LZMA SDK option -d17. */ + case 0x00040000:/* lzma of LZMA SDK option -d18. */ + case 0x00080000:/* lzma of XZ Utils option -2. + * lzma of LZMA SDK option -d19. */ + case 0x00100000:/* lzma of XZ Utils option -3. + * lzma of LZMA SDK option -d20. */ + case 0x00200000:/* lzma of XZ Utils option -4. + * lzma of LZMA SDK option -d21. */ + case 0x00400000:/* lzma of XZ Utils option -5. + * lzma of LZMA SDK option -d22. */ + case 0x00800000:/* lzma of XZ Utils option -6. + * lzma of LZMA SDK option -d23. */ + case 0x01000000:/* lzma of XZ Utils option -7. + * lzma of LZMA SDK option -d24. */ + case 0x02000000:/* lzma of XZ Utils option -8. + * lzma of LZMA SDK option -d25. */ + case 0x04000000:/* lzma of XZ Utils option -9. + * lzma of LZMA SDK option -d26. */ + case 0x08000000:/* lzma of LZMA SDK option -d27. */ + bits_checked += 32; + break; + default: + /* If a memory usage for encoding was not enough on + * the platform where LZMA stream was made, lzma of + * XZ Utils automatically decreased the dictionary + * size to enough memory for encoding by 1Mi bytes + * (1 << 20).*/ + if (dicsize <= 0x03F00000 && dicsize >= 0x00300000 && + (dicsize & ((1 << 20)-1)) == 0 && + bits_checked == 8 + 64) { + bits_checked += 32; + break; + } + /* Otherwise dictionary size is unlikely. But it is + * possible that someone makes lzma stream with + * liblzma/LZMA SDK in one's dictionary size. */ return (0); - bits_checked += 8; -#endif + } /* TODO: The above test is still very weak. It would be * good to do better. */ @@ -304,11 +368,11 @@ */ if (self->code == ARCHIVE_COMPRESSION_XZ) ret = lzma_stream_decoder(&(state->stream), - (1U << 23) + (1U << 21),/* memlimit */ + (1U << 30),/* memlimit */ LZMA_CONCATENATED); else ret = lzma_alone_decoder(&(state->stream), - (1U << 23) + (1U << 21));/* memlimit */ + (1U << 30));/* memlimit */ if (ret == LZMA_OK) return (ARCHIVE_OK); --zhXaljGHf11kAtnf-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 12:52:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83CEF1065670 for ; Thu, 23 Dec 2010 12:52:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 267CF8FC14 for ; Thu, 23 Dec 2010 12:52:25 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 91AE646B17; Thu, 23 Dec 2010 07:52:24 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 16FB38A009; Thu, 23 Dec 2010 07:52:23 -0500 (EST) From: John Baldwin To: Daniel Braniss Date: Thu, 23 Dec 2010 07:47:46 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012230747.46527.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 23 Dec 2010 07:52:23 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: panic on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 12:52:25 -0000 On Thursday, December 23, 2010 1:47:39 am Daniel Braniss wrote: > > On Wednesday, December 22, 2010 10:58:56 am Daniel Braniss wrote: > > > > On Wednesday, December 22, 2010 5:12:03 am Daniel Braniss wrote: > > > > > the hardware is Sun Fire X2200 M2, and it's discless, PXE booted. > > > > > > > > > > this seems to have started sometime before 8.2, and it > > > > > 'sometimes happens': > > > > > > > > > > FreeBSD 8.2-PRERELEASE #15 r4274: Wed Dec 22 09:11:27 IST 2010c40, rbp = > > > > > 0xffffffff80ef5c60 --- > > > > > danny@rnd:/home/obj/rnd/r+d/stable/8/sys/HUJI amd64 > > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > > CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2613.40-MHz K8-class CPU) > > > > > Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 > > > > > Features=0x178bfbff > > > > CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > > > > Features2=0x2001 > > > > > AMD Features=0xea500800 > > > > > AMD Features2=0x1f > > > > > ... > > > > > SMP: AP CPU #3 Launched! > > > > > (cd0:ata0:0:0:0): SCSI status: Check Condition > > > > > cpu3 AP: > > > > > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > > > > > ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > > > (cd0: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > > > ata0:0: timer: 0x000200ef therm: 0x00010000 err: 0x000000f00: pmc: 0x000104000): > > > > > Error 6, Unretryable error > > > > > SMP: AP CPU #2 Launched! > > > > > cd0 at ata0 bus 0 scbus0 target 0 lun 0 > > > > > cpu2 AP: > > > > > cd0: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > > > Removable CD-ROM SCSI-0 device > > > > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > > > cd0: 33.300MB/s transfers timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 ( pmc: 0x00010400UDMA2, > > > > > ATAPI 12bytes, ioapic0: routing intpin 3 (PIO 65534bytesISA IRQ 3)) to lapic 1 vector 48 > > > > > f > > > > > loiwotaapbilce0 :c lreoaunteirn gs tianrttpeidn > > > > > 4 (cd0: Attempt to query device size failed: NOT READY, Medium not present > > > > > ISA IRQ 4) to lapic 2 vector 48 > > > > > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 > > > > > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 > > > > > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 2 vector 49 > > > > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 3 vector 49 > > > > > ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 50 > > > > > ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 > > > > > kernel trap 12 with interrupts disabled > > > > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > cpuid = 0; apic id = 00 > > > > > fault virtual address = 0x10 > > > > > fault code = supervisor read data, page not present > > > > > instruction pointer = 0x20:0xffffffff808b1581 > > > > > stack pointer = 0x28:0xffffffff80ef5b20 > > > > > frame pointer = 0x28:0xffffffff80ef5b50 > > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > processor eflags = resume, IOPL = 0 > > > > > current process = 0 (swapper) > > > > > trap number = 12 > > > > > panic: page fault > > > > > cpuid = 0 > > > > > KDB: stack backtrace: > > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > > kdb_backtrace() at kdb_backtrace+0x37 > > > > > panic() at panic+0x187 > > > > > trap_fatal() at trap_fatal+0x290 > > > > > trap_pfault() at trap_pfault+0x28f > > > > > trap() at trap+0x3df > > > > > calltrap() at calltrap+0x8 > > > > > --- trap 0xc, rip = 0xffffffff808b1581, rsp = 0xffffffff80ef5b20, rbp = 0xffffffff80ef5b50 --- > > > > > intr_execute_handlers() at intr_execute_handlers+0x21 > > > > > lapic_handle_intr() at lapic_handle_intr+0x37 > > > > > Xapic_isr1() at Xapic_isr1+0xa5 > > > > > --- interrupt, rip = 0xffffffff808b6cf3, rsp = 0xffffffff80ef5c40, rbp = 0xffffffff80ef5c60 --- > > > > > spinlock_exit() at spinlock_exit+0x33 > > > > > ioapic_assign_cpu() at ioapic_assign_cpu+0x123 > > > > > intr_shuffle_irqs() at intr_shuffle_irqs+0x9d > > > > > mi_startup() at mi_startup+0x77 > > > > > btext() at btext+0x2c > > > > > Uptime: 2s > > > > > > > > Can you do 'l *intr_execute_handlers+0x21' and 'l *ioapic_assign_cpu+0x123' > > > > in 'gdb kernel.debug' of your kernel? > > > > > > sure, as soon as it happens, and it aint happening now :-( > > > but when it will happen, I think it won't let me into the debugger > > > - probably will have to recompile > > > > You don't need to trigger the panic, you can just run > > 'gdb /path/to/kernel.debug' (e.g. > > 'gdb /usr/obj/usr/src/sys/GENERIC/kernel.debug') > sorry, missed the gdb part. > > gdb /d/7/boot/kernel/kernel > ... > (gdb) l *intr_execute_handlers+0x21 > 0xffffffff808b1581 is in intr_execute_handlers (/r+d/stable/8/sys/amd64/amd64/i > ntr_machdep.c:243). > 238 * We count software interrupts when we process them. The > 239 * code here follows previous practice, but there's an > 240 * argument for counting hardware interrupts when they're > 241 * processed too. > 242 */ > 243 (*isrc->is_count)++; > 244 PCPU_INC(cnt.v_intr); > 245 > 246 ie = isrc->is_event; > 247 > (gdb) l *ioapic_assign_cpu+0x123 > 0xffffffff808b29c3 is in ioapic_assign_cpu (/r+d/stable/8/sys/amd64/amd64/io_ap > ic.c:383). > 378 > 379 /* > 380 * Free the old vector after the new one is established. This > is done > 381 * to prevent races where we could miss an interrupt. > 382 */ > 383 if (old_vector) { > 384 if (isrc->is_handlers > 0) > 385 apic_disable_vector(old_id, old_vector); > 386 apic_free_vector(old_id, old_vector, intpin->io_irq); > 387 } > > BTW, the config has > makeoptions DEBUG=-g > but I don't see no kernel.debug (searched the obj directory, and only found > old versions) Hmmm, can you get a crashdump? If not, try this patch: Index: local_apic.c =================================================================== --- local_apic.c (revision 216651) +++ local_apic.c (working copy) @@ -763,6 +763,9 @@ panic("Couldn't get vector from ISR!"); isrc = intr_lookup_source(apic_idt_to_irq(PCPU_GET(apic_id), vector)); + if (isrc == NULL) + panic("null isrc for APIC %d, vector %d", PCPU_GET(apic_id), + vector); intr_execute_handlers(isrc, frame); } If it triggers this new panic, capture the panic message and the output of 'show apic' from DDB. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 13:30:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 315431065670; Thu, 23 Dec 2010 13:30:37 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 9F4518FC13; Thu, 23 Dec 2010 13:30:36 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PVlFb-000IIs-83; Thu, 23 Dec 2010 15:30:35 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: John Baldwin In-reply-to: <201012230747.46527.jhb@freebsd.org> References: <201012230747.46527.jhb@freebsd.org> Comments: In-reply-to John Baldwin message dated "Thu, 23 Dec 2010 07:47:46 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Dec 2010 15:30:35 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: panic on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 13:30:37 -0000 > On Thursday, December 23, 2010 1:47:39 am Daniel Braniss wrote: > > > On Wednesday, December 22, 2010 10:58:56 am Daniel Braniss wrote: > > > > > On Wednesday, December 22, 2010 5:12:03 am Daniel Braniss wrote: > > > > > > the hardware is Sun Fire X2200 M2, and it's discless, PXE booted. > > > > > > > > > > > > this seems to have started sometime before 8.2, and it > > > > > > 'sometimes happens': > > > > > > > > > > > > FreeBSD 8.2-PRERELEASE #15 r4274: Wed Dec 22 09:11:27 IST 2010c40, rbp = > > > > > > 0xffffffff80ef5c60 --- > > > > > > danny@rnd:/home/obj/rnd/r+d/stable/8/sys/HUJI amd64 > > > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > > > CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2613.40-MHz K8-class CPU) > > > > > > Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 > > > > > > Features=0x178bfbff > > > > > CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > > > > > Features2=0x2001 > > > > > > AMD Features=0xea500800 > > > > > > AMD Features2=0x1f > > > > > > ... > > > > > > SMP: AP CPU #3 Launched! > > > > > > (cd0:ata0:0:0:0): SCSI status: Check Condition > > > > > > cpu3 AP: > > > > > > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > > > > > > ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > > > > (cd0: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > > > > ata0:0: timer: 0x000200ef therm: 0x00010000 err: 0x000000f00: pmc: 0x000104000): > > > > > > Error 6, Unretryable error > > > > > > SMP: AP CPU #2 Launched! > > > > > > cd0 at ata0 bus 0 scbus0 target 0 lun 0 > > > > > > cpu2 AP: > > > > > > cd0: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > > > > Removable CD-ROM SCSI-0 device > > > > > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > > > > cd0: 33.300MB/s transfers timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 ( pmc: 0x00010400UDMA2, > > > > > > ATAPI 12bytes, ioapic0: routing intpin 3 (PIO 65534bytesISA IRQ 3)) to lapic 1 vector 48 > > > > > > f > > > > > > loiwotaapbilce0 :c lreoaunteirn gs tianrttpeidn > > > > > > 4 (cd0: Attempt to query device size failed: NOT READY, Medium not present > > > > > > ISA IRQ 4) to lapic 2 vector 48 > > > > > > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 > > > > > > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 > > > > > > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 2 vector 49 > > > > > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 3 vector 49 > > > > > > ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 50 > > > > > > ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 > > > > > > kernel trap 12 with interrupts disabled > > > > > > > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > > cpuid = 0; apic id = 00 > > > > > > fault virtual address = 0x10 > > > > > > fault code = supervisor read data, page not present > > > > > > instruction pointer = 0x20:0xffffffff808b1581 > > > > > > stack pointer = 0x28:0xffffffff80ef5b20 > > > > > > frame pointer = 0x28:0xffffffff80ef5b50 > > > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > > processor eflags = resume, IOPL = 0 > > > > > > current process = 0 (swapper) > > > > > > trap number = 12 > > > > > > panic: page fault > > > > > > cpuid = 0 > > > > > > KDB: stack backtrace: > > > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > > > kdb_backtrace() at kdb_backtrace+0x37 > > > > > > panic() at panic+0x187 > > > > > > trap_fatal() at trap_fatal+0x290 > > > > > > trap_pfault() at trap_pfault+0x28f > > > > > > trap() at trap+0x3df > > > > > > calltrap() at calltrap+0x8 > > > > > > --- trap 0xc, rip = 0xffffffff808b1581, rsp = 0xffffffff80ef5b20, rbp = 0xffffffff80ef5b50 --- > > > > > > intr_execute_handlers() at intr_execute_handlers+0x21 > > > > > > lapic_handle_intr() at lapic_handle_intr+0x37 > > > > > > Xapic_isr1() at Xapic_isr1+0xa5 > > > > > > --- interrupt, rip = 0xffffffff808b6cf3, rsp = 0xffffffff80ef5c40, rbp = 0xffffffff80ef5c60 --- > > > > > > spinlock_exit() at spinlock_exit+0x33 > > > > > > ioapic_assign_cpu() at ioapic_assign_cpu+0x123 > > > > > > intr_shuffle_irqs() at intr_shuffle_irqs+0x9d > > > > > > mi_startup() at mi_startup+0x77 > > > > > > btext() at btext+0x2c > > > > > > Uptime: 2s > > > > > > > > > > Can you do 'l *intr_execute_handlers+0x21' and 'l *ioapic_assign_cpu+0x123' > > > > > in 'gdb kernel.debug' of your kernel? > > > > > > > > sure, as soon as it happens, and it aint happening now :-( > > > > but when it will happen, I think it won't let me into the debugger > > > > - probably will have to recompile > > > > > > You don't need to trigger the panic, you can just run > > > 'gdb /path/to/kernel.debug' (e.g. > > > 'gdb /usr/obj/usr/src/sys/GENERIC/kernel.debug') > > sorry, missed the gdb part. > > > > gdb /d/7/boot/kernel/kernel > > ... > > (gdb) l *intr_execute_handlers+0x21 > > 0xffffffff808b1581 is in intr_execute_handlers (/r+d/stable/8/sys/amd64/amd64/i > > ntr_machdep.c:243). > > 238 * We count software interrupts when we process them. The > > 239 * code here follows previous practice, but there's an > > 240 * argument for counting hardware interrupts when they're > > 241 * processed too. > > 242 */ > > 243 (*isrc->is_count)++; > > 244 PCPU_INC(cnt.v_intr); > > 245 > > 246 ie = isrc->is_event; > > 247 > > (gdb) l *ioapic_assign_cpu+0x123 > > 0xffffffff808b29c3 is in ioapic_assign_cpu (/r+d/stable/8/sys/amd64/amd64/io_ap > > ic.c:383). > > 378 > > 379 /* > > 380 * Free the old vector after the new one is established. This > > is done > > 381 * to prevent races where we could miss an interrupt. > > 382 */ > > 383 if (old_vector) { > > 384 if (isrc->is_handlers > 0) > > 385 apic_disable_vector(old_id, old_vector); > > 386 apic_free_vector(old_id, old_vector, intpin->io_irq); > > 387 } > > > > BTW, the config has > > makeoptions DEBUG=-g > > but I don't see no kernel.debug (searched the obj directory, and only found > > old versions) > > Hmmm, can you get a crashdump? If not, try this patch: > > Index: local_apic.c > =================================================================== > --- local_apic.c (revision 216651) > +++ local_apic.c (working copy) > @@ -763,6 +763,9 @@ > panic("Couldn't get vector from ISR!"); > isrc = intr_lookup_source(apic_idt_to_irq(PCPU_GET(apic_id), > vector)); > + if (isrc == NULL) > + panic("null isrc for APIC %d, vector %d", PCPU_GET(apic_id), > + vector); > intr_execute_handlers(isrc, frame); > } > > If it triggers this new panic, capture the panic message and the output of > 'show apic' from DDB. > the code change is easy, the problems is that when it panics it will only allow reboot. panic: null isrc for APIC 0, vector 50 now lets see how I can get into DDB :-( cheers, danny > -- > John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 13:33:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9332106566C; Thu, 23 Dec 2010 13:33:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 22FC78FC1E; Thu, 23 Dec 2010 13:33:14 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PVlI9-000IMb-LI; Thu, 23 Dec 2010 15:33:13 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: John Baldwin In-reply-to: <201012230747.46527.jhb@freebsd.org> References: <201012230747.46527.jhb@freebsd.org> Comments: In-reply-to John Baldwin message dated "Thu, 23 Dec 2010 07:47:46 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Dec 2010 15:33:13 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: panic on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 13:33:15 -0000 > On Thursday, December 23, 2010 1:47:39 am Daniel Braniss wrote: > > > On Wednesday, December 22, 2010 10:58:56 am Daniel Braniss wrote: > > > > > On Wednesday, December 22, 2010 5:12:03 am Daniel Braniss wrote: > > > > > > the hardware is Sun Fire X2200 M2, and it's discless, PXE booted. > > > > > > > > > > > > this seems to have started sometime before 8.2, and it > > > > > > 'sometimes happens': > > > > > > > > > > > > FreeBSD 8.2-PRERELEASE #15 r4274: Wed Dec 22 09:11:27 IST 2010c40, rbp = > > > > > > 0xffffffff80ef5c60 --- > > > > > > danny@rnd:/home/obj/rnd/r+d/stable/8/sys/HUJI amd64 > > > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > > > CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2613.40-MHz K8-class CPU) > > > > > > Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 > > > > > > Features=0x178bfbff > > > > > CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > > > > > Features2=0x2001 > > > > > > AMD Features=0xea500800 > > > > > > AMD Features2=0x1f > > > > > > ... > > > > > > SMP: AP CPU #3 Launched! > > > > > > (cd0:ata0:0:0:0): SCSI status: Check Condition > > > > > > cpu3 AP: > > > > > > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > > > > > > ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > > > > (cd0: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > > > > ata0:0: timer: 0x000200ef therm: 0x00010000 err: 0x000000f00: pmc: 0x000104000): > > > > > > Error 6, Unretryable error > > > > > > SMP: AP CPU #2 Launched! > > > > > > cd0 at ata0 bus 0 scbus0 target 0 lun 0 > > > > > > cpu2 AP: > > > > > > cd0: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > > > > Removable CD-ROM SCSI-0 device > > > > > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > > > > cd0: 33.300MB/s transfers timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 ( pmc: 0x00010400UDMA2, > > > > > > ATAPI 12bytes, ioapic0: routing intpin 3 (PIO 65534bytesISA IRQ 3)) to lapic 1 vector 48 > > > > > > f > > > > > > loiwotaapbilce0 :c lreoaunteirn gs tianrttpeidn > > > > > > 4 (cd0: Attempt to query device size failed: NOT READY, Medium not present > > > > > > ISA IRQ 4) to lapic 2 vector 48 > > > > > > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 > > > > > > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 > > > > > > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 2 vector 49 > > > > > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 3 vector 49 > > > > > > ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 50 > > > > > > ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 > > > > > > kernel trap 12 with interrupts disabled > > > > > > > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > > cpuid = 0; apic id = 00 > > > > > > fault virtual address = 0x10 > > > > > > fault code = supervisor read data, page not present > > > > > > instruction pointer = 0x20:0xffffffff808b1581 > > > > > > stack pointer = 0x28:0xffffffff80ef5b20 > > > > > > frame pointer = 0x28:0xffffffff80ef5b50 > > > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > > processor eflags = resume, IOPL = 0 > > > > > > current process = 0 (swapper) > > > > > > trap number = 12 > > > > > > panic: page fault > > > > > > cpuid = 0 > > > > > > KDB: stack backtrace: > > > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > > > kdb_backtrace() at kdb_backtrace+0x37 > > > > > > panic() at panic+0x187 > > > > > > trap_fatal() at trap_fatal+0x290 > > > > > > trap_pfault() at trap_pfault+0x28f > > > > > > trap() at trap+0x3df > > > > > > calltrap() at calltrap+0x8 > > > > > > --- trap 0xc, rip = 0xffffffff808b1581, rsp = 0xffffffff80ef5b20, rbp = 0xffffffff80ef5b50 --- > > > > > > intr_execute_handlers() at intr_execute_handlers+0x21 > > > > > > lapic_handle_intr() at lapic_handle_intr+0x37 > > > > > > Xapic_isr1() at Xapic_isr1+0xa5 > > > > > > --- interrupt, rip = 0xffffffff808b6cf3, rsp = 0xffffffff80ef5c40, rbp = 0xffffffff80ef5c60 --- > > > > > > spinlock_exit() at spinlock_exit+0x33 > > > > > > ioapic_assign_cpu() at ioapic_assign_cpu+0x123 > > > > > > intr_shuffle_irqs() at intr_shuffle_irqs+0x9d > > > > > > mi_startup() at mi_startup+0x77 > > > > > > btext() at btext+0x2c > > > > > > Uptime: 2s > > > > > > > > > > Can you do 'l *intr_execute_handlers+0x21' and 'l *ioapic_assign_cpu+0x123' > > > > > in 'gdb kernel.debug' of your kernel? > > > > > > > > sure, as soon as it happens, and it aint happening now :-( > > > > but when it will happen, I think it won't let me into the debugger > > > > - probably will have to recompile > > > > > > You don't need to trigger the panic, you can just run > > > 'gdb /path/to/kernel.debug' (e.g. > > > 'gdb /usr/obj/usr/src/sys/GENERIC/kernel.debug') > > sorry, missed the gdb part. > > > > gdb /d/7/boot/kernel/kernel > > ... > > (gdb) l *intr_execute_handlers+0x21 > > 0xffffffff808b1581 is in intr_execute_handlers (/r+d/stable/8/sys/amd64/amd64/i > > ntr_machdep.c:243). > > 238 * We count software interrupts when we process them. The > > 239 * code here follows previous practice, but there's an > > 240 * argument for counting hardware interrupts when they're > > 241 * processed too. > > 242 */ > > 243 (*isrc->is_count)++; > > 244 PCPU_INC(cnt.v_intr); > > 245 > > 246 ie = isrc->is_event; > > 247 > > (gdb) l *ioapic_assign_cpu+0x123 > > 0xffffffff808b29c3 is in ioapic_assign_cpu (/r+d/stable/8/sys/amd64/amd64/io_ap > > ic.c:383). > > 378 > > 379 /* > > 380 * Free the old vector after the new one is established. This > > is done > > 381 * to prevent races where we could miss an interrupt. > > 382 */ > > 383 if (old_vector) { > > 384 if (isrc->is_handlers > 0) > > 385 apic_disable_vector(old_id, old_vector); > > 386 apic_free_vector(old_id, old_vector, intpin->io_irq); > > 387 } > > > > BTW, the config has > > makeoptions DEBUG=-g > > but I don't see no kernel.debug (searched the obj directory, and only found > > old versions) > > Hmmm, can you get a crashdump? If not, try this patch: > > Index: local_apic.c > =================================================================== > --- local_apic.c (revision 216651) > +++ local_apic.c (working copy) > @@ -763,6 +763,9 @@ > panic("Couldn't get vector from ISR!"); > isrc = intr_lookup_source(apic_idt_to_irq(PCPU_GET(apic_id), > vector)); > + if (isrc == NULL) > + panic("null isrc for APIC %d, vector %d", PCPU_GET(apic_id), > + vector); > intr_execute_handlers(isrc, frame); > } > > If it triggers this new panic, capture the panic message and the output of > 'show apic' from DDB. > > -- > John Baldwin because reboot hung :-), I was able to ~^B and so: db> show apic Interrupts bound to lapic 0 vec 0x31 -> IRQ 21 vec 0x33 -> IRQ 14 vec 0x35 -> IRQ 23 vec 0x36 -> IRQ 256 vec 0x37 -> IRQ 257 vec 0x38 -> IRQ 258 vec 0x39 -> IRQ 259 vec 0x3a -> IRQ 260 vec 0x3b -> IRQ 261 vec 0x3c -> IRQ 262 vec 0x3d -> IRQ 263 vec 0x3e -> IRQ 264 vec 0x3f -> IRQ 265 vec 0x40 -> IRQ 266 vec 0x41 -> IRQ 267 vec 0x42 -> IRQ 268 vec 0x43 -> IRQ 269 vec 0x44 -> IRQ 270 vec 0x45 -> IRQ 271 vec 0x4a -> IRQ 1 vec 0xef -> lapic timer Interrupts bound to lapic 1 vec 0x30 -> IRQ 3 vec 0x31 -> IRQ 15 vec 0x32 -> IRQ 22 vec 0xef -> lapic timer Interrupts bound to lapic 2 vec 0x30 -> IRQ 4 vec 0x31 -> IRQ 17 vec 0x32 -> IRQ 23 vec 0xef -> lapic timer Interrupts bound to lapic 3 vec 0x30 -> IRQ 9 vec 0x31 -> IRQ 18 vec 0xef -> lapic timer From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 14:10:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3350106566B; Thu, 23 Dec 2010 14:10:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 67C808FC19; Thu, 23 Dec 2010 14:10:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 046AB46B86; Thu, 23 Dec 2010 09:10:37 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AC37F8A009; Thu, 23 Dec 2010 09:10:35 -0500 (EST) From: John Baldwin To: Daniel Braniss , Alexander Motin Date: Thu, 23 Dec 2010 09:10:35 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201012230747.46527.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012230910.35201.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 23 Dec 2010 09:10:35 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: panic on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 14:10:37 -0000 On Thursday, December 23, 2010 8:33:13 am Daniel Braniss wrote: > > On Thursday, December 23, 2010 1:47:39 am Daniel Braniss wrote: > > > > On Wednesday, December 22, 2010 10:58:56 am Daniel Braniss wrote: > > > > > > On Wednesday, December 22, 2010 5:12:03 am Daniel Braniss wrote: > > > > > > > the hardware is Sun Fire X2200 M2, and it's discless, PXE booted. > > > > > > > > > > > > > > this seems to have started sometime before 8.2, and it > > > > > > > 'sometimes happens': > > > > > > > > > > > > > > FreeBSD 8.2-PRERELEASE #15 r4274: Wed Dec 22 09:11:27 IST 2010c40, rbp = > > > > > > > 0xffffffff80ef5c60 --- > > > > > > > danny@rnd:/home/obj/rnd/r+d/stable/8/sys/HUJI amd64 > > > > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > > > > CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2613.40-MHz K8-class CPU) > > > > > > > Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 > > > > > > > Features=0x178bfbff > > > > > > CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > > > > > > > Features2=0x2001 > > > > > > > AMD Features=0xea500800 > > > > > > > AMD Features2=0x1f > > > > > > > ... > > > > > > > SMP: AP CPU #3 Launched! > > > > > > > (cd0:ata0:0:0:0): SCSI status: Check Condition > > > > > > > cpu3 AP: > > > > > > > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > > > > > > > ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > > > > > (cd0: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > > > > > ata0:0: timer: 0x000200ef therm: 0x00010000 err: 0x000000f00: pmc: 0x000104000): > > > > > > > Error 6, Unretryable error > > > > > > > SMP: AP CPU #2 Launched! > > > > > > > cd0 at ata0 bus 0 scbus0 target 0 lun 0 > > > > > > > cpu2 AP: > > > > > > > cd0: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > > > > > > > Removable CD-ROM SCSI-0 device > > > > > > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > > > > > > cd0: 33.300MB/s transfers timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 ( pmc: 0x00010400UDMA2, > > > > > > > ATAPI 12bytes, ioapic0: routing intpin 3 (PIO 65534bytesISA IRQ 3)) to lapic 1 vector 48 > > > > > > > f > > > > > > > loiwotaapbilce0 :c lreoaunteirn gs tianrttpeidn > > > > > > > 4 (cd0: Attempt to query device size failed: NOT READY, Medium not present > > > > > > > ISA IRQ 4) to lapic 2 vector 48 > > > > > > > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 > > > > > > > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 > > > > > > > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 2 vector 49 > > > > > > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 3 vector 49 > > > > > > > ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 50 > > > > > > > ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 > > > > > > > kernel trap 12 with interrupts disabled > > > > > > > > > > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > > > cpuid = 0; apic id = 00 > > > > > > > fault virtual address = 0x10 > > > > > > > fault code = supervisor read data, page not present > > > > > > > instruction pointer = 0x20:0xffffffff808b1581 > > > > > > > stack pointer = 0x28:0xffffffff80ef5b20 > > > > > > > frame pointer = 0x28:0xffffffff80ef5b50 > > > > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > > > processor eflags = resume, IOPL = 0 > > > > > > > current process = 0 (swapper) > > > > > > > trap number = 12 > > > > > > > panic: page fault > > > > > > > cpuid = 0 > > > > > > > KDB: stack backtrace: > > > > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > > > > kdb_backtrace() at kdb_backtrace+0x37 > > > > > > > panic() at panic+0x187 > > > > > > > trap_fatal() at trap_fatal+0x290 > > > > > > > trap_pfault() at trap_pfault+0x28f > > > > > > > trap() at trap+0x3df > > > > > > > calltrap() at calltrap+0x8 > > > > > > > --- trap 0xc, rip = 0xffffffff808b1581, rsp = 0xffffffff80ef5b20, rbp = 0xffffffff80ef5b50 --- > > > > > > > intr_execute_handlers() at intr_execute_handlers+0x21 > > > > > > > lapic_handle_intr() at lapic_handle_intr+0x37 > > > > > > > Xapic_isr1() at Xapic_isr1+0xa5 > > > > > > > --- interrupt, rip = 0xffffffff808b6cf3, rsp = 0xffffffff80ef5c40, rbp = 0xffffffff80ef5c60 --- > > > > > > > spinlock_exit() at spinlock_exit+0x33 > > > > > > > ioapic_assign_cpu() at ioapic_assign_cpu+0x123 > > > > > > > intr_shuffle_irqs() at intr_shuffle_irqs+0x9d > > > > > > > mi_startup() at mi_startup+0x77 > > > > > > > btext() at btext+0x2c > > > > > > > Uptime: 2s > > > > > > > > > > > > Can you do 'l *intr_execute_handlers+0x21' and 'l *ioapic_assign_cpu+0x123' > > > > > > in 'gdb kernel.debug' of your kernel? > > > > > > > > > > sure, as soon as it happens, and it aint happening now :-( > > > > > but when it will happen, I think it won't let me into the debugger > > > > > - probably will have to recompile > > > > > > > > You don't need to trigger the panic, you can just run > > > > 'gdb /path/to/kernel.debug' (e.g. > > > > 'gdb /usr/obj/usr/src/sys/GENERIC/kernel.debug') > > > sorry, missed the gdb part. > > > > > > gdb /d/7/boot/kernel/kernel > > > ... > > > (gdb) l *intr_execute_handlers+0x21 > > > 0xffffffff808b1581 is in intr_execute_handlers (/r+d/stable/8/sys/amd64/amd64/i > > > ntr_machdep.c:243). > > > 238 * We count software interrupts when we process them. The > > > 239 * code here follows previous practice, but there's an > > > 240 * argument for counting hardware interrupts when they're > > > 241 * processed too. > > > 242 */ > > > 243 (*isrc->is_count)++; > > > 244 PCPU_INC(cnt.v_intr); > > > 245 > > > 246 ie = isrc->is_event; > > > 247 > > > (gdb) l *ioapic_assign_cpu+0x123 > > > 0xffffffff808b29c3 is in ioapic_assign_cpu (/r+d/stable/8/sys/amd64/amd64/io_ap > > > ic.c:383). > > > 378 > > > 379 /* > > > 380 * Free the old vector after the new one is established. This > > > is done > > > 381 * to prevent races where we could miss an interrupt. > > > 382 */ > > > 383 if (old_vector) { > > > 384 if (isrc->is_handlers > 0) > > > 385 apic_disable_vector(old_id, old_vector); > > > 386 apic_free_vector(old_id, old_vector, intpin->io_irq); > > > 387 } > > > > > > BTW, the config has > > > makeoptions DEBUG=-g > > > but I don't see no kernel.debug (searched the obj directory, and only found > > > old versions) > > > > Hmmm, can you get a crashdump? If not, try this patch: > > > > Index: local_apic.c > > =================================================================== > > --- local_apic.c (revision 216651) > > +++ local_apic.c (working copy) > > @@ -763,6 +763,9 @@ > > panic("Couldn't get vector from ISR!"); > > isrc = intr_lookup_source(apic_idt_to_irq(PCPU_GET(apic_id), > > vector)); > > + if (isrc == NULL) > > + panic("null isrc for APIC %d, vector %d", PCPU_GET(apic_id), > > + vector); > > intr_execute_handlers(isrc, frame); > > } > > > > If it triggers this new panic, capture the panic message and the output of > > 'show apic' from DDB. > > > > -- > > John Baldwin > > because reboot hung :-), I was able to ~^B and so: > > db> show apic > Interrupts bound to lapic 0 > vec 0x31 -> IRQ 21 > vec 0x33 -> IRQ 14 Ok, so vec 0x32 was recently moved. Can you try this patch? Index: sys/x86/x86/io_apic.c =================================================================== --- io_apic.c (revision 216651) +++ io_apic.c (working copy) @@ -359,7 +359,9 @@ if (!intpin->io_masked && !intpin->io_edgetrigger) { ioapic_write(io->io_addr, IOAPIC_REDTBL_LO(intpin->io_intpin), intpin->io_lowreg | IOART_INTMSET); + mtx_unlock_spin(&icu_lock); DELAY(100); + mtx_lock_spin(&icu_lock); } intpin->io_cpu = apic_id; -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 19:00:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91ECC106564A for ; Thu, 23 Dec 2010 19:00:13 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 171038FC16 for ; Thu, 23 Dec 2010 19:00:11 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id D271119E038; Thu, 23 Dec 2010 20:00:09 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id ABE1819E031; Thu, 23 Dec 2010 20:00:07 +0100 (CET) Message-ID: <4D139C37.1070500@quip.cz> Date: Thu, 23 Dec 2010 20:00:07 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 MIME-Version: 1.0 To: John Baldwin References: <4D11F1F5.7050902@quip.cz> <201012220957.26854.jhb@freebsd.org> In-Reply-To: <201012220957.26854.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 19:00:13 -0000 John Baldwin wrote: > On Wednesday, December 22, 2010 7:41:25 am Miroslav Lachman wrote: >> Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000833 >> Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, >> Status 0x0000000000000000 >> Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, >> APIC ID 0 >> Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source DRD Memory >> Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x236493c0 > > You are getting corrected ECC errors in your RAM. You see them once an hour > because we poll the machine check registers once an hour. If this happens > constantly you might have a DIMM that is dying? Yes, it happens constantly. Does Bank in this context means DIMM socket or anything else? If it is DIMM socket, then it means all modules are dying at the same time :( Thank you for mcelog output. BTW do you have any time plan for releasing port of mcelog? Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 19:39:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B66E11065673 for ; Thu, 23 Dec 2010 19:39:39 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 890BF8FC1D for ; Thu, 23 Dec 2010 19:39:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id C870750A72; Thu, 23 Dec 2010 19:39:38 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUKanzeQlZ54; Thu, 23 Dec 2010 19:39:38 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 8C83850A4C ; Thu, 23 Dec 2010 19:39:38 +0000 (GMT) Message-ID: <4D13A579.8090004@langille.org> Date: Thu, 23 Dec 2010 14:39:37 -0500 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D11F1F5.7050902@quip.cz> <201012220957.26854.jhb@freebsd.org> In-Reply-To: <201012220957.26854.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 19:39:39 -0000 On 12/22/2010 9:57 AM, John Baldwin wrote: > On Wednesday, December 22, 2010 7:41:25 am Miroslav Lachman wrote: >> Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000833 >> Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, >> Status 0x0000000000000000 >> Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, >> APIC ID 0 >> Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source DRD Memory >> Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x236493c0 > > You are getting corrected ECC errors in your RAM. You see them once an hour > because we poll the machine check registers once an hour. If this happens > constantly you might have a DIMM that is dying? John: I take it these ECC errors *may* have been happening for some time. What has changed is the OS now polls for the errors and reports them. -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 23:17:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C624106566B; Thu, 23 Dec 2010 23:17:49 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3C7328FC13; Thu, 23 Dec 2010 23:17:48 +0000 (UTC) Received: by gwj21 with SMTP id 21so4015513gwj.13 for ; Thu, 23 Dec 2010 15:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=3fTQIxocJ1HiVqMaCthQNj8iWTE5/J+8YWeU/eD7G1c=; b=oB0CnkUZpCGsHPsNHDXZMup2PuNeB3Crce3UuZSOQJEuhvi6VHKiasAMknuYZi1ZdY kTwM+MjMqgsY8fg4nzhfUwhOEh7xfM1sinZz0E/zhn3JsouHdOrWOSt7eXQ5lsAYN7u1 B4jdwiBHzouNgOglrNvzofvC1grUHVPKgMYbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=e27vvZQxrB2juUVGLkj+jVI8lq0SA296fVPsHV4kDdxwqXVM27E/0J1Lh3mJrdFbxT 0Q298P4iHjOioZ/AFTLbmB9o8BW9dwP1KWXIwzTXzUDObm14OJEbcCzyteQFEKJkbAfS 4dWqntQtQDURE5JJQH6BH5Py5r6IgK9XGIFnQ= Received: by 10.150.196.2 with SMTP id t2mr12816661ybf.205.1293146268309; Thu, 23 Dec 2010 15:17:48 -0800 (PST) Received: from centel.dataix.local (adsl-99-181-145-144.dsl.klmzmi.sbcglobal.net [99.181.145.144]) by mx.google.com with ESMTPS id 8sm4662304yhx.3.2010.12.23.15.17.45 (version=SSLv3 cipher=RC4-MD5); Thu, 23 Dec 2010 15:17:46 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4D13D898.6040203@DataIX.net> Date: Thu, 23 Dec 2010 18:17:44 -0500 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101210 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Martin Matuska References: <4D0A09AF.3040005@FreeBSD.org> In-Reply-To: <4D0A09AF.3040005@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: New ZFSv28 patchset for 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 23:17:49 -0000 Hi Martin, List, Patched up to a ZFSv28 20101218 and it is working as expected, Great Job!. There seems to be some assertion errors that are left to be fixed yet with the following examples: Panic String: solaris assert: vd->vdev_stat.vs_alloc == 0 (0x18a000 == 0x0), file:/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c, line: 4623 #3 0x84caca35 in spa_vdev_remove (spa=0x84dba000, guid=2330662286000872312, unspare=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:4623 4623 ASSERT3U(vd->vdev_stat.vs_alloc, ==, 0); (kgdb) list 4618 4619 /* 4620 * The evacuation succeeded. Remove any remaining MOS metadata 4621 * associated with this vdev, and wait for these changes to sync. 4622 */ 4623 ASSERT3U(vd->vdev_stat.vs_alloc, ==, 0); 4624 txg = spa_vdev_config_enter(spa); 4625 vd->vdev_removing = B_TRUE; 4626 vdev_dirty(vd, 0, NULL, txg); 4627 vdev_config_dirty(vd); This happens on i386 upon ( zfs remove pool ) Also if it is of any relevance this happens during ``offline'' too. If further information is needed I still have these cores and kernel just let me know what you need. Regards, -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Fri Dec 24 06:09:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72D2E1065695 for ; Fri, 24 Dec 2010 06:09:59 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 314378FC21 for ; Fri, 24 Dec 2010 06:09:58 +0000 (UTC) Received: by iwn39 with SMTP id 39so6842265iwn.13 for ; Thu, 23 Dec 2010 22:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=N7puEesQ9E4VM1Fi0m4FrbPxQIb10w2/E04E5mSqODM=; b=iHFcdJBCpCxWd2IPQtamEBuIlzaU1JdaSjGA55MmdLIooY2D3XV5DwjecIrIoViFXD 9Wwz88zPaznoT0nFGr59apl5itk15xhDTzyY6NIFakoVK80rAVuA5N01qytL6X+WinHn zTgGVrDXEjKmRAjxxn1Aw3LdLBhCGQpqipbKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=HHX/ZfYydYpZE3yxrVDfPMqjrB0dEw+huH2k5mhnSAES529SNuyUKRzdQMpsfCY1+3 YLNjSifjrPrV0sKudb/D5Eptk736U8gGGHrxfK90t9kNtfJWY8WSQhw+Vy3XCdIed6QS HD21xbC/SDse4qQBIjmDPZxS1rYh2CIfCIyDg= Received: by 10.231.34.195 with SMTP id m3mr8970307ibd.116.1293170998476; Thu, 23 Dec 2010 22:09:58 -0800 (PST) Received: from compaq.yuetime (c-98-228-178-175.hsd1.il.comcast.net [98.228.178.175]) by mx.google.com with ESMTPS id 8sm7378216iba.10.2010.12.23.22.09.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Dec 2010 22:09:57 -0800 (PST) Date: Fri, 24 Dec 2010 00:09:33 -0600 From: Zhihao Yuan To: freebsd-stable@freebsd.org Message-ID: <20101224060933.GA78345@compaq.yuetime> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: USB flash drive crashed hal on 8.2-PRERELEASE amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 06:09:59 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi: I saw a similair error report before. This only happens on this jump stick. The GEOM lines may be the cause of the problem. Please check it out, thank you.=20 ~> dmesg # tail part ugen7.2: at usbus7 umass1: on usbus7 (probe0:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0=20 (probe0:umass-sim1:1:0:0): CAM status: SCSI Status Error (probe0:umass-sim1:1:0:0): SCSI status: Check Condition (probe0:umass-sim1:1:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) da1 at umass-sim1 bus 1 scbus1 target 0 lun 0 da1: Removable Direct Access SCSI-2 device=20 da1: 40.000MB/s transfers da1: 1910MB (3913664 512 byte sectors: 255H 63S/T 243C) GEOM: da1: partition 1 does not start on a track boundary. GEOM: da1: partition 1 does not end on a track boundary. pid 78290 (hald-probe-volume), uid 0: exited on signal 6 (core dumped) pid 78292 (hald-probe-volume), uid 0: exited on signal 6 (core dumped) ~> uname -a FreeBSD compaq.yuetime 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #2: Sun Dec 12 03:34:43 CST 2010 root@compaq.yuetime:/usr/obj/usr/src/sys/HOUKAGO amd64 --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. -------------------------------------------------- let focus =3D 'computing' in here: http://let-in.blogspot.com (let (me Program!)): http://lichray.blogspot.com --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk0UOR0ACgkQflQ9HU+rZa13sQCeMHi+vsObpLjer/a3vCMnQC9o 7zgAoJekwPZ/ey4PbzW25OgK90PBbgqu =Yb1n -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-freebsd-stable@FreeBSD.ORG Fri Dec 24 08:47:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BA67106564A for ; Fri, 24 Dec 2010 08:47:18 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 107B58FC12 for ; Fri, 24 Dec 2010 08:47:17 +0000 (UTC) Received: from draco.over-yonder.net (c-75-64-226-141.hsd1.ms.comcast.net [75.64.226.141]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id DB35437B56C; Fri, 24 Dec 2010 02:47:16 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 1011161C5A; Fri, 24 Dec 2010 02:47:16 -0600 (CST) Date: Fri, 24 Dec 2010 02:47:16 -0600 From: "Matthew D. Fuller" To: John Baldwin Message-ID: <20101224084716.GM94020@over-yonder.net> References: <4D11F1F5.7050902@quip.cz> <201012220957.26854.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201012220957.26854.jhb@freebsd.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.96.5 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 08:47:18 -0000 On Wed, Dec 22, 2010 at 09:57:26AM -0500 I heard the voice of John Baldwin, and lo! it spake thus: > > You are getting corrected ECC errors in your RAM. Actually, don't > CPU 0 0 data cache > ADDR 236493c0 > Data cache ECC error (syndrome 1c) > CPU 0 1 instruction cache > ADDR 2a1c9440 > Instruction cache ECC error > CPU 0 2 bus unit > L2 cache ECC error > CPU 1 0 data cache > ADDR 23649640 > Data cache ECC error (syndrome 1c) > CPU 1 1 instruction cache > ADDR 2a1c9440 > Instruction cache ECC error > CPU 1 2 bus unit > L2 cache ECC error suggest CPU cache, not RAM? (that's actually a question; I don't know, but that's what a naive reading suggests...) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Fri Dec 24 17:20:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E111C1065674 for ; Fri, 24 Dec 2010 17:20:43 +0000 (UTC) (envelope-from zoran@fooboo.org) Received: from feodosiia.fooboo.org (fw.fooboo.org [90.179.146.117]) by mx1.freebsd.org (Postfix) with ESMTP id 59A3D8FC13 for ; Fri, 24 Dec 2010 17:20:43 +0000 (UTC) Received: from feodosiia.fooboo.org (localhost.fooboo.org [127.0.0.1]) by feodosiia.fooboo.org (8.14.1/8.14.1) with ESMTP id oBOH899m014812 for ; Fri, 24 Dec 2010 18:08:10 +0100 (CET) Received: (from zoran@localhost) by feodosiia.fooboo.org (8.14.1/8.14.1/Submit) id oBOH89xZ023386 for freebsd-stable@freebsd.org; Fri, 24 Dec 2010 18:08:09 +0100 (CET) X-Authentication-Warning: feodosiia.fooboo.org: zoran set sender to zoran@fooboo.org using -f Date: Fri, 24 Dec 2010 18:08:09 +0100 From: Zoran To: freebsd-stable@freebsd.org Message-ID: <20101224170809.GA28772@feodosiia.fooboo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: happy hacker lite 2 keyboard X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 17:20:44 -0000 Dear all! I consider buying new keyboard and found happy hacker lite 2 model suiting fine. Is there someone on the list with expe- rience using it? I'm aware I should change rc.conf to meet it's 65 key layout. Also, how xorg.conf has to look like in this situation? Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Fri Dec 24 17:47:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6AB1065674; Fri, 24 Dec 2010 17:47:35 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 006798FC13; Fri, 24 Dec 2010 17:47:34 +0000 (UTC) Received: by wwf26 with SMTP id 26so6923735wwf.31 for ; Fri, 24 Dec 2010 09:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=O2/E8eL1Pfk+/REonszR9ZXStTc9V124PsfXpWaCZAA=; b=kINnwzsClXvEAc1GJyR+pxJzWAHHWjsr/1O2FZfEvOegSt+YO1cWtGClWY688hcNld NCvT99e6mK+6x/N3YZoADINlS7i7JaprTobx063YBM+ZPEz2exOiVlCr0TC1rRpODa3S 10Po8PEdwPG1FeOkJH+8HMQaUSvo93AZxaSjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FUqhpIZmbEiTIY6nj/+2/helkkfprKrBx/cVnY6RujjTl8VSHQOlQ5TVNoBaXq0ehw DE+SktsBFlq6PlV0bIeSpPxl/YjgyMK8tpf0PO7zZEBrtCg6OvPbQrZN9Y8Y2pnZ3lCs a0WMLiIgmbq7yK14z+Qbhz8lGFrf06GbdiYT0= MIME-Version: 1.0 Received: by 10.216.63.15 with SMTP id z15mr10420255wec.74.1293212853843; Fri, 24 Dec 2010 09:47:33 -0800 (PST) Received: by 10.216.12.80 with HTTP; Fri, 24 Dec 2010 09:47:33 -0800 (PST) In-Reply-To: <4CE0010D.7080505@FreeBSD.org> References: <4CD45209.5010607@FreeBSD.org> <4CDE5B8C.4000102@FreeBSD.org> <4CE0010D.7080505@FreeBSD.org> Date: Fri, 24 Dec 2010 11:47:33 -0600 Message-ID: From: Brandon Gooch To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 17:47:36 -0000 On Sun, Nov 14, 2010 at 9:32 AM, Alexander Motin wrote: > Brandon Gooch wrote: >> On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin wrote: >>> Now uncommitted pass_autosence.patch and possibly cdrtools.patch. >> >> OK. Patched kernel and cdrtools has resulted in a working cdrecord >> (burned an ISO successfully) and an endless stream of: >> >> ... >> (pass0:ata0:0:0:0): Requesting SCSI sense data >> (pass0:ata0:0:0:0): SCSI status error >> (pass0:ata0:0:0:0): Requesting SCSI sense data >> (pass0:ata0:0:0:0): SCSI status error >> (pass0:ata0:0:0:0): Requesting SCSI sense data >> (pass0:ata0:0:0:0): SCSI status error >> (pass0:ata0:0:0:0): Requesting SCSI sense data >> (pass0:ata0:0:0:0): SCSI status error >> ... > > I think it can be hald probing for media insertion. Probably we should > slightly reduce error logging verbosity. May be somehow make to not log > errors on requests submitted from user-level via pass driver. > >> But most important part: It works, and it burned very quickly! The CD >> was created, and fully functional (I booted the Fedora image and >> completed an installation). > > Nice! What are your thoughts on committing this (or something like it)? Should I just keep a local patch set for the semi-long-term? Do you have something else in the works? -Brandon From owner-freebsd-stable@FreeBSD.ORG Fri Dec 24 18:59:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB937106567A for ; Fri, 24 Dec 2010 18:59:05 +0000 (UTC) (envelope-from pj@smo.de) Received: from smtp-out24.ilk.net (smtp-out24.ilk.net [212.86.193.184]) by mx1.freebsd.org (Postfix) with ESMTP id 1BEAA8FC1C for ; Fri, 24 Dec 2010 18:59:04 +0000 (UTC) Received: from bologna.intern.smo.de (pool39.tdsl.ilk.net [212.86.201.39]) by smtp.ilk.net (Postfix) with ESMTP id 5492A360EA; Fri, 24 Dec 2010 19:44:01 +0100 (CET) Received: from herdubreid.intern.smo.de (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.8+Sun/8.13.8) with ESMTP id oBOIhuEe021831; Fri, 24 Dec 2010 19:43:57 +0100 (CET) Message-ID: <4D14EA2C.8060401@smo.de> Date: Fri, 24 Dec 2010 19:45:00 +0100 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.16) Gecko/20101218 SeaMonkey/2.0.11 MIME-Version: 1.0 To: Zoran References: <20101224170809.GA28772@feodosiia.fooboo.org> In-Reply-To: <20101224170809.GA28772@feodosiia.fooboo.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010103010307010809060508" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: happy hacker lite 2 keyboard X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 18:59:05 -0000 This is a cryptographically signed message in MIME format. --------------ms010103010307010809060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Zoran wrote: > I consider buying new keyboard and found happy hacker lite 2 > model suiting fine. Is there someone on the list with expe- > rience using it? I have one in use since ~5 years. The typing feel is a lot better=20 compared to the Logitech keyboard I had before. The only problem I have with mine is that it's not usable with the boot=20 loader menu. It seems to be hardware related as it works fine with other = computers (using different chipsets). > I'm aware I should change rc.conf to meet it's > 65 key layout. Also, how xorg.conf has to look like in this > situation? The only keyboard-specific thing I have in my rc.conf is 'keymap=3D"us.is= o"'. My xorg.conf contains the following entries in the "InputDevice" section:= Option "XkbRules" "xorg" Option "XkbModel" "pc101" Option "XkbLayout" "us" I say it should work right out of the box ;-) In addition, I did=20 configure a .xmodmaprc to get umlauts, etc. HTH, Philipp --------------ms010103010307010809060508-- From owner-freebsd-stable@FreeBSD.ORG Fri Dec 24 19:43:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79E05106564A for ; Fri, 24 Dec 2010 19:43:02 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C56C8FC08 for ; Fri, 24 Dec 2010 19:43:01 +0000 (UTC) Received: by fxm16 with SMTP id 16so7775958fxm.13 for ; Fri, 24 Dec 2010 11:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=zPQawLIYfpnCZQcTeuNXeYv3QqZyrNin1B6T5mMchmE=; b=aqzY/IrEIelNs6MLS1bfE/ux1aTe3q20+6/2Tr5JGx2cWwQGJ2RWtcUmyhIZUGh5vG 8MWX7ryL4oUgPRktUF15RwbkWi0RLfIXbsdA/RlPC7FyxRqnwgLlNp4uCT8TSry5JLI8 BTAVSMhVMvX4LENXOdu69jenD5QKQOXxyDkjw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=pe5MeJURlRz1PLxZt584YoKvJ6vPuXzbaDvHBfHfdvdUhquWFvhmTo5zu7PkaBuy9Z W3pCw6Ek86AFHOr+7ZJ1O3sVeRrZhfG9x0Cv1fttU/y0hNymXJeMOIldn+55VvsIe7xS SicpVF1DR8trLO3Ze6vS1Ijd/Cs024g4M8HgY= MIME-Version: 1.0 Received: by 10.223.74.141 with SMTP id u13mr629604faj.62.1293218416582; Fri, 24 Dec 2010 11:20:16 -0800 (PST) Received: by 10.223.109.138 with HTTP; Fri, 24 Dec 2010 11:20:16 -0800 (PST) In-Reply-To: <4D13A579.8090004@langille.org> References: <4D11F1F5.7050902@quip.cz> <201012220957.26854.jhb@freebsd.org> <4D13A579.8090004@langille.org> Date: Fri, 24 Dec 2010 13:20:16 -0600 Message-ID: From: Alan Cox To: Dan Langille Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz>, John Baldwin Subject: Re: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 19:43:02 -0000 2010/12/23 Dan Langille > On 12/22/2010 9:57 AM, John Baldwin wrote: > >> On Wednesday, December 22, 2010 7:41:25 am Miroslav Lachman wrote: >> >>> Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000833 >>> Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, >>> Status 0x0000000000000000 >>> Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, >>> APIC ID 0 >>> Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source DRD >>> Memory >>> Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x236493c0 >>> >> >> You are getting corrected ECC errors in your RAM. You see them once an >> hour >> because we poll the machine check registers once an hour. If this happens >> constantly you might have a DIMM that is dying? >> > > John: > > I take it these ECC errors *may* have been happening for some time. What > has changed is the OS now polls for the errors and reports them. > > Yes, we enabled MCA by default in 8.1-RELEASE. Alan From owner-freebsd-stable@FreeBSD.ORG Fri Dec 24 21:11:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9AFA106564A; Fri, 24 Dec 2010 21:11:18 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D0E1B8FC18; Fri, 24 Dec 2010 21:11:17 +0000 (UTC) Received: by fxm16 with SMTP id 16so7808732fxm.13 for ; Fri, 24 Dec 2010 13:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=hFJRpwZxI+o0J/FMYKWHPEQiI1TerrKmRlWbI1jzDvE=; b=oFY/nTD35eSJy52/7lmOA18cdu8FsxZmOK0vv/d32YfomBluntzDd304okrEUrxWHp s0b136WCyAfi8al73QAQkwEWlx1Q8AE7sGUZD8YM+BejXZe0R5rzhivY4SVHtAPBivoB gC1TLsyNf12dfO8Abu4VU4Ax5vwyTcAd6nBxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=P4IRU49QbtMRtcxGnWfRdxwtOQQdDZLL0gR0LOfwiYzVcVYWjJrr1fo7NI+Uqp1JxO hNDRMGWH6+r8EdlQwrNb/Kpd4sQx7e2etuacOa3o1k9tXnB6dNGhuseA23uVE7YibbfY S5Pi8Te8weLCdtvnahDmQErggOFuDLdQyrNa4= Received: by 10.223.98.198 with SMTP id r6mr1367549fan.42.1293225076638; Fri, 24 Dec 2010 13:11:16 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id n15sm2372345fam.12.2010.12.24.13.11.13 (version=SSLv3 cipher=RC4-MD5); Fri, 24 Dec 2010 13:11:15 -0800 (PST) Sender: Alexander Motin Message-ID: <4D150C56.4080801@FreeBSD.org> Date: Fri, 24 Dec 2010 23:10:46 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Brandon Gooch References: <4CD45209.5010607@FreeBSD.org> <4CDE5B8C.4000102@FreeBSD.org> <4CE0010D.7080505@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 21:11:18 -0000 Brandon Gooch wrote: > On Sun, Nov 14, 2010 at 9:32 AM, Alexander Motin wrote: >> Brandon Gooch wrote: >>> On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin wrote: >>>> Now uncommitted pass_autosence.patch and possibly cdrtools.patch. >>> OK. Patched kernel and cdrtools has resulted in a working cdrecord >>> (burned an ISO successfully) and an endless stream of: >>> >>> ... >>> (pass0:ata0:0:0:0): Requesting SCSI sense data >>> (pass0:ata0:0:0:0): SCSI status error >>> (pass0:ata0:0:0:0): Requesting SCSI sense data >>> (pass0:ata0:0:0:0): SCSI status error >>> (pass0:ata0:0:0:0): Requesting SCSI sense data >>> (pass0:ata0:0:0:0): SCSI status error >>> (pass0:ata0:0:0:0): Requesting SCSI sense data >>> (pass0:ata0:0:0:0): SCSI status error >>> ... >> I think it can be hald probing for media insertion. Probably we should >> slightly reduce error logging verbosity. May be somehow make to not log >> errors on requests submitted from user-level via pass driver. >> >>> But most important part: It works, and it burned very quickly! The CD >>> was created, and fully functional (I booted the Fedora image and >>> completed an installation). >> Nice! > > What are your thoughts on committing this (or something like it)? > Should I just keep a local patch set for the semi-long-term? Do you > have something else in the works? I wanted to do something with these logs first, as they are hardly acceptable, but was distracted by different project. Unless somebody take it, I'll be back to it later. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Fri Dec 24 22:35:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E6D0106564A for ; Fri, 24 Dec 2010 22:35:37 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 72EA78FC17 for ; Fri, 24 Dec 2010 22:35:34 +0000 (UTC) Received: from ur.dons.net.au (ppp203-122-198-230.lns6.adl6.internode.on.net [203.122.198.230]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id oBOMZBBa052373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 25 Dec 2010 09:05:18 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-31--757185471; protocol="application/pkcs7-signature"; micalg=sha1 From: "Daniel O'Connor" In-Reply-To: <4D14EA2C.8060401@smo.de> Date: Sat, 25 Dec 2010 09:05:10 +1030 Message-Id: References: <20101224170809.GA28772@feodosiia.fooboo.org> <4D14EA2C.8060401@smo.de> To: Philipp Ost X-Mailer: Apple Mail (2.1082) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Zoran Subject: Re: happy hacker lite 2 keyboard X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 22:35:37 -0000 --Apple-Mail-31--757185471 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25/12/2010, at 5:15, Philipp Ost wrote: > The only problem I have with mine is that it's not usable with the = boot loader menu. It seems to be hardware related as it works fine with = other computers (using different chipsets). If it's a USB keyboard then it's up to your BIOS if it will work in the = loader. ie it needs to probe for USB devices and be able to parse the keyboard = messages on behalf of the loader. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail-31--757185471-- From owner-freebsd-stable@FreeBSD.ORG Fri Dec 24 23:22:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A4B81065674 for ; Fri, 24 Dec 2010 23:22:08 +0000 (UTC) (envelope-from carlj@peak.org) Received: from redcondor1.peak.org (redcondor1.peak.org [69.59.192.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1E38FC27 for ; Fri, 24 Dec 2010 23:22:07 +0000 (UTC) Received: from peak-mail-gateway.peak.org ([69.59.192.42]) by redcondor1.peak.org ({e03e86cd-14ae-47ce-9578-3c080ce9c462}) via TCP (outbound) with ESMTP id 20101224230849085 for ; Fri, 24 Dec 2010 23:08:49 +0000 X-RC-FROM: X-RC-RCPT: Received: from oak.localnet (207.55.91.159.peak.org [207.55.91.159] (may be forged)) by peak-mail-gateway.peak.org (8.12.10/8.12.8) with ESMTP id oBON8mW7027975 for ; Fri, 24 Dec 2010 15:08:48 -0800 (PST) Received: from oak.localnet (localhost [127.0.0.1]) by oak.localnet (Postfix) with ESMTP id 6A2D1CC9E for ; Fri, 24 Dec 2010 15:08:48 -0800 (PST) Received: (from carlj@localhost) by oak.localnet (8.14.4/8.14.4/Submit) id oBON8muC016207; Fri, 24 Dec 2010 15:08:48 -0800 (PST) (envelope-from carlj@peak.org) X-Authentication-Warning: oak.localnet: carlj set sender to carlj@peak.org using -f From: Carl Johnson To: freebsd-stable@freebsd.org References: <4D11F1F5.7050902@quip.cz> <201012220957.26854.jhb@freebsd.org> <4D13A579.8090004@langille.org> Date: Fri, 24 Dec 2010 15:08:48 -0800 In-Reply-To: (Alan Cox's message of "Fri, 24 Dec 2010 13:20:16 -0600") Message-ID: <87vd2iepkv.fsf@oak.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 23:22:08 -0000 Alan Cox writes: > 2010/12/23 Dan Langille > >> On 12/22/2010 9:57 AM, John Baldwin wrote: >> >>> On Wednesday, December 22, 2010 7:41:25 am Miroslav Lachman wrote: >>> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000833 >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, >>>> Status 0x0000000000000000 >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, >>>> APIC ID 0 >>>> Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source DRD >>>> Memory >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x236493c0 >>>> >>> >>> You are getting corrected ECC errors in your RAM. You see them once an >>> hour >>> because we poll the machine check registers once an hour. If this happens >>> constantly you might have a DIMM that is dying? >>> >> >> John: >> >> I take it these ECC errors *may* have been happening for some time. What >> has changed is the OS now polls for the errors and reports them. >> >> > Yes, we enabled MCA by default in 8.1-RELEASE. Is there some reason that it is only available for i386 and not for amd64? Linux has something called mcelog, for machine check errors, which sounds similar and is available for amd64. -- Carl Johnson carlj@peak.org From owner-freebsd-stable@FreeBSD.ORG Sat Dec 25 00:03:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27F7C106564A for ; Sat, 25 Dec 2010 00:03:57 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id ABD848FC0C for ; Sat, 25 Dec 2010 00:03:56 +0000 (UTC) Received: by fxm16 with SMTP id 16so7859132fxm.13 for ; Fri, 24 Dec 2010 16:03:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=C8wStlooLdLfrjrtjhUMUiDZzWfDXdbDbZN9MdrBumQ=; b=VsYJMUZGebUhIxo6W4Mp3RIOrqW7IaFVmsk1qzUExCHh0W+duZHBaVFgMaFXnHPare jnXmJg/SfS6K09OdULk6zpNSniJR05sQZjB/DPL11w4E97C3JH/K9YrrymV7e3tLc6Ne r8AWnaQC7OnOykRH4gDSgvEFRsNmaMjpxAwU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=iej0dXoS5+58TYta+17dDc8RILWBd182Mg09pvhMOeeZyXjrTpSC2aVFbxsI2VlBRP 9SET+Dt1NHf8zfJieACVNsMFxRYQkB6Lwrsxf8BGnKVhqlWhbNF9q+nTfin+vNnjS2iI 20go0jcxLucHxrfedSzZjqtQ3CCr24BLwucJ4= MIME-Version: 1.0 Received: by 10.223.89.143 with SMTP id e15mr1313721fam.100.1293235435605; Fri, 24 Dec 2010 16:03:55 -0800 (PST) Received: by 10.223.109.138 with HTTP; Fri, 24 Dec 2010 16:03:55 -0800 (PST) In-Reply-To: <87vd2iepkv.fsf@oak.localnet> References: <4D11F1F5.7050902@quip.cz> <201012220957.26854.jhb@freebsd.org> <4D13A579.8090004@langille.org> <87vd2iepkv.fsf@oak.localnet> Date: Fri, 24 Dec 2010 18:03:55 -0600 Message-ID: From: Alan Cox To: Carl Johnson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 00:03:57 -0000 On Fri, Dec 24, 2010 at 5:08 PM, Carl Johnson wrote: > Alan Cox writes: > > > 2010/12/23 Dan Langille > > > >> On 12/22/2010 9:57 AM, John Baldwin wrote: > >> > >>> On Wednesday, December 22, 2010 7:41:25 am Miroslav Lachman wrote: > >>> > >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000833 > >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, > >>>> Status 0x0000000000000000 > >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, > >>>> APIC ID 0 > >>>> Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source DRD > >>>> Memory > >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x236493c0 > >>>> > >>> > >>> You are getting corrected ECC errors in your RAM. You see them once an > >>> hour > >>> because we poll the machine check registers once an hour. If this > happens > >>> constantly you might have a DIMM that is dying? > >>> > >> > >> John: > >> > >> I take it these ECC errors *may* have been happening for some time. What > >> has changed is the OS now polls for the errors and reports them. > >> > >> > > Yes, we enabled MCA by default in 8.1-RELEASE. > > Is there some reason that it is only available for i386 and not for > amd64? Linux has something called mcelog, for machine check errors, > which sounds similar and is available for amd64. > > Perhaps I'm misunderstanding your question, but our MCA driver is supported and enabled by default on both i386 and amd64. Alan From owner-freebsd-stable@FreeBSD.ORG Sat Dec 25 02:12:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 366BC106566C for ; Sat, 25 Dec 2010 02:12:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9118FC0C for ; Sat, 25 Dec 2010 02:12:42 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta09.emeryville.ca.mail.comcast.net with comcast id nE8b1f0020FhH24A9ECiCF; Sat, 25 Dec 2010 02:12:42 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta08.emeryville.ca.mail.comcast.net with comcast id nECh1f00B2tehsa8UEChym; Sat, 25 Dec 2010 02:12:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 56D869B427; Fri, 24 Dec 2010 18:12:41 -0800 (PST) Date: Fri, 24 Dec 2010 18:12:41 -0800 From: Jeremy Chadwick To: Carl Johnson Message-ID: <20101225021241.GA96768@icarus.home.lan> References: <4D11F1F5.7050902@quip.cz> <201012220957.26854.jhb@freebsd.org> <4D13A579.8090004@langille.org> <87vd2iepkv.fsf@oak.localnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vd2iepkv.fsf@oak.localnet> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 02:12:43 -0000 On Fri, Dec 24, 2010 at 03:08:48PM -0800, Carl Johnson wrote: > Alan Cox writes: > > > 2010/12/23 Dan Langille > > > >> On 12/22/2010 9:57 AM, John Baldwin wrote: > >> > >>> On Wednesday, December 22, 2010 7:41:25 am Miroslav Lachman wrote: > >>> > >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000833 > >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, > >>>> Status 0x0000000000000000 > >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, > >>>> APIC ID 0 > >>>> Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source DRD > >>>> Memory > >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x236493c0 > >>>> > >>> > >>> You are getting corrected ECC errors in your RAM. You see them once an > >>> hour > >>> because we poll the machine check registers once an hour. If this happens > >>> constantly you might have a DIMM that is dying? > >>> > >> > >> John: > >> > >> I take it these ECC errors *may* have been happening for some time. What > >> has changed is the OS now polls for the errors and reports them. > >> > >> > > Yes, we enabled MCA by default in 8.1-RELEASE. > > Is there some reason that it is only available for i386 and not for > amd64? Linux has something called mcelog, for machine check errors, > which sounds similar and is available for amd64. You mean like what John used in his earlier post on this thread? :-) http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/060705.html If you're looking for it for FreeBSD, it's available below as a patch to the original (I believe): http://www.FreeBSD.org/~jhb/mcelog/ -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Dec 25 04:48:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 740951065673 for ; Sat, 25 Dec 2010 04:48:10 +0000 (UTC) (envelope-from carlj@peak.org) Received: from redcondor2.peak.org (redcondor2.peak.org [69.59.192.56]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD818FC12 for ; Sat, 25 Dec 2010 04:48:10 +0000 (UTC) Received: from peak-mail-gateway.peak.org ([69.59.192.42]) by redcondor2.peak.org ({6c724cae-de34-4c5f-b615-3072b86419fa}) via TCP (outbound) with ESMTP id 20101225044809316 for ; Sat, 25 Dec 2010 04:48:09 +0000 X-RC-FROM: X-RC-RCPT: Received: from oak.localnet (207.55.91.159.peak.org [207.55.91.159] (may be forged)) by peak-mail-gateway.peak.org (8.12.10/8.12.8) with ESMTP id oBP4m8W7023045 for ; Fri, 24 Dec 2010 20:48:09 -0800 (PST) Received: from oak.localnet (localhost [127.0.0.1]) by oak.localnet (Postfix) with ESMTP id 7E300CCAC for ; Fri, 24 Dec 2010 20:48:08 -0800 (PST) Received: (from carlj@localhost) by oak.localnet (8.14.4/8.14.4/Submit) id oBP4m8B6017688; Fri, 24 Dec 2010 20:48:08 -0800 (PST) (envelope-from carlj@peak.org) X-Authentication-Warning: oak.localnet: carlj set sender to carlj@peak.org using -f From: Carl Johnson To: freebsd-stable@freebsd.org References: <4D11F1F5.7050902@quip.cz> <201012220957.26854.jhb@freebsd.org> <4D13A579.8090004@langille.org> <87vd2iepkv.fsf@oak.localnet> Date: Fri, 24 Dec 2010 20:48:08 -0800 In-Reply-To: (Alan Cox's message of "Fri, 24 Dec 2010 18:03:55 -0600") Message-ID: <87r5d6e9vb.fsf@oak.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 04:48:10 -0000 Alan Cox writes: > On Fri, Dec 24, 2010 at 5:08 PM, Carl Johnson wrote: > >> Alan Cox writes: >> >> > 2010/12/23 Dan Langille >> > >> >> On 12/22/2010 9:57 AM, John Baldwin wrote: >> >> >> >>> On Wednesday, December 22, 2010 7:41:25 am Miroslav Lachman wrote: >> >>> >> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000833 >> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, >> >>>> Status 0x0000000000000000 >> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, >> >>>> APIC ID 0 >> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source DRD >> >>>> Memory >> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x236493c0 >> >>>> >> >>> >> >>> You are getting corrected ECC errors in your RAM. You see them once an >> >>> hour >> >>> because we poll the machine check registers once an hour. If this >> happens >> >>> constantly you might have a DIMM that is dying? >> >>> >> >> >> >> John: >> >> >> >> I take it these ECC errors *may* have been happening for some time. What >> >> has changed is the OS now polls for the errors and reports them. >> >> >> >> >> > Yes, we enabled MCA by default in 8.1-RELEASE. >> >> Is there some reason that it is only available for i386 and not for >> amd64? Linux has something called mcelog, for machine check errors, >> which sounds similar and is available for amd64. >> >> > Perhaps I'm misunderstanding your question, but our MCA driver is supported > and enabled by default on both i386 and amd64. Thanks, it appears that I misunderstood. I ran whereis and found /usr/src/sbin/mca and didn't find it on my amd64 system. I do see it in my sysctl listing now that I look there. -- Carl Johnson carlj@peak.org From owner-freebsd-stable@FreeBSD.ORG Sat Dec 25 04:54:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39D06106564A for ; Sat, 25 Dec 2010 04:54:22 +0000 (UTC) (envelope-from carlj@peak.org) Received: from redcondor1.peak.org (redcondor1.peak.org [69.59.192.54]) by mx1.freebsd.org (Postfix) with ESMTP id 052078FC0C for ; Sat, 25 Dec 2010 04:54:21 +0000 (UTC) Received: from peak-mail-gateway.peak.org ([69.59.192.42]) by redcondor1.peak.org ({e03e86cd-14ae-47ce-9578-3c080ce9c462}) via TCP (outbound) with ESMTP id 20101225045421058 for ; Sat, 25 Dec 2010 04:54:21 +0000 X-RC-FROM: X-RC-RCPT: Received: from oak.localnet (207.55.91.159.peak.org [207.55.91.159] (may be forged)) by peak-mail-gateway.peak.org (8.12.10/8.12.8) with ESMTP id oBP4sKW7024483 for ; Fri, 24 Dec 2010 20:54:20 -0800 (PST) Received: from oak.localnet (localhost [127.0.0.1]) by oak.localnet (Postfix) with ESMTP id 4BC38CCB2 for ; Fri, 24 Dec 2010 20:54:20 -0800 (PST) Received: (from carlj@localhost) by oak.localnet (8.14.4/8.14.4/Submit) id oBP4sKI7017706; Fri, 24 Dec 2010 20:54:20 -0800 (PST) (envelope-from carlj@peak.org) X-Authentication-Warning: oak.localnet: carlj set sender to carlj@peak.org using -f From: Carl Johnson To: freebsd-stable@freebsd.org References: <4D11F1F5.7050902@quip.cz> <201012220957.26854.jhb@freebsd.org> <4D13A579.8090004@langille.org> <87vd2iepkv.fsf@oak.localnet> <20101225021241.GA96768@icarus.home.lan> Date: Fri, 24 Dec 2010 20:54:20 -0800 In-Reply-To: <20101225021241.GA96768@icarus.home.lan> (Jeremy Chadwick's message of "Fri, 24 Dec 2010 18:12:41 -0800") Message-ID: <87mxnue9kz.fsf@oak.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 04:54:22 -0000 Jeremy Chadwick writes: > On Fri, Dec 24, 2010 at 03:08:48PM -0800, Carl Johnson wrote: >> Alan Cox writes: >> >> > 2010/12/23 Dan Langille >> > >> >> On 12/22/2010 9:57 AM, John Baldwin wrote: >> >> >> >>> On Wednesday, December 22, 2010 7:41:25 am Miroslav Lachman wrote: >> >>> >> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000833 >> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, >> >>>> Status 0x0000000000000000 >> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40f33, >> >>>> APIC ID 0 >> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source DRD >> >>>> Memory >> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x236493c0 >> >>>> >> >>> >> >>> You are getting corrected ECC errors in your RAM. You see them once an >> >>> hour >> >>> because we poll the machine check registers once an hour. If this happens >> >>> constantly you might have a DIMM that is dying? >> >>> >> >> >> >> John: >> >> >> >> I take it these ECC errors *may* have been happening for some time. What >> >> has changed is the OS now polls for the errors and reports them. >> >> >> >> >> > Yes, we enabled MCA by default in 8.1-RELEASE. >> >> Is there some reason that it is only available for i386 and not for >> amd64? Linux has something called mcelog, for machine check errors, >> which sounds similar and is available for amd64. > > You mean like what John used in his earlier post on this thread? :-) > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/060705.html Oops! Yes, I missed that when I read it. > If you're looking for it for FreeBSD, it's available below as a patch to > the original (I believe): > > http://www.FreeBSD.org/~jhb/mcelog/ Thanks for the link. -- Carl Johnson carlj@peak.org From owner-freebsd-stable@FreeBSD.ORG Sat Dec 25 05:17:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF04B106564A for ; Sat, 25 Dec 2010 05:17:12 +0000 (UTC) (envelope-from zoran@fooboo.org) Received: from feodosiia.fooboo.org (fw.fooboo.org [90.179.146.117]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF9B8FC0C for ; Sat, 25 Dec 2010 05:17:11 +0000 (UTC) Received: from feodosiia.fooboo.org (localhost.fooboo.org [127.0.0.1]) by feodosiia.fooboo.org (8.14.1/8.14.1) with ESMTP id oBP5H9nP027048 for ; Sat, 25 Dec 2010 06:17:09 +0100 (CET) Received: (from zoran@localhost) by feodosiia.fooboo.org (8.14.1/8.14.1/Submit) id oBP5H8xR009839 for freebsd-stable@freebsd.org; Sat, 25 Dec 2010 06:17:08 +0100 (CET) X-Authentication-Warning: feodosiia.fooboo.org: zoran set sender to zoran@fooboo.org using -f Date: Sat, 25 Dec 2010 06:17:08 +0100 From: Zoran To: freebsd-stable@freebsd.org Message-ID: <20101225051708.GA853@feodosiia.fooboo.org> References: <20101224170809.GA28772@feodosiia.fooboo.org> <4D14EA2C.8060401@smo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D14EA2C.8060401@smo.de> Subject: Re: happy hacker lite 2 keyboard X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 05:17:12 -0000 Thaks for reply. > I have one in use since ~5 years. The typing feel is a lot better compared > to the Logitech keyboard I had before. > The only problem I have with mine is that it's not usable with the boot > loader menu. It seems to be hardware related as it works fine with other > computers (using different chipsets). There is always chance to use it with ps2 converter. All new keyboards are usb in fact, but I add that little plastic in between. > The only keyboard-specific thing I have in my rc.conf is 'keymap="us.iso"'. K. Then I have to change nothing. > My xorg.conf contains the following entries in the "InputDevice" section: > Option "XkbRules" "xorg" > Option "XkbModel" "pc101" > Option "XkbLayout" "us" I don't have this. Should be easy to check out if necessary. > I say it should work right out of the box ;-) In addition, I did configure > a .xmodmaprc to get umlauts, etc. Yep, I assume I would have to change my xmodmaprc to match new layout. The other part is that fvwm2rc uses that layout to have extra tweaks for window manager. I still have something to ponder. To have more than one screen in fvwm, actually four of them, I ought to turn off numpad first. Then I use com- bination of Alt-Fx to jump here and there. In bios I removed numpad and it is not working on the kb, to my wish. Any thought how it goes on HH? Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Sat Dec 25 11:43:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 932AC106566B; Sat, 25 Dec 2010 11:43:31 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 217DB8FC0C; Sat, 25 Dec 2010 11:43:30 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id EECA119E02E; Sat, 25 Dec 2010 12:43:28 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 14C6A19E030; Sat, 25 Dec 2010 12:43:26 +0100 (CET) Message-ID: <4D15D8DD.9010900@quip.cz> Date: Sat, 25 Dec 2010 12:43:25 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 MIME-Version: 1.0 To: John Baldwin References: <4BCE4D0F.2020807@quip.cz> <4BCE6615.9010707@quip.cz> <4D03AC1D.5070906@quip.cz> <201012130824.33968.jhb@freebsd.org> In-Reply-To: <201012130824.33968.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-stable@freebsd.org Subject: Re: /libexec/ld-elf.so.1: Cannot execute objects on / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 11:43:31 -0000 John Baldwin wrote: > On Saturday, December 11, 2010 11:51:41 am Miroslav Lachman wrote: >> Miroslav Lachman wrote: >>> Garrett Cooper wrote: >>>> 2010/4/20 Miroslav Lachman<000.fbsd@quip.cz>: >>>>> I have large storage partition (/vol0) mounted as noexec and nosuid. >>>>> Then >>>>> one directory from this partition is mounted by nullfs as "exec and >>>>> suid" so >>>>> anything on it can be executed. >>>>> >>>>> The directory contains full installation of jail. Jail is running >>>>> fine, but >>>>> some ports (PHP for example) cannot be compiled inside the jail with >>>>> message: >>>>> >>>>> /libexec/ld-elf.so.1: Cannot execute objects on / >>>>> >>>>> The same apply to executing of apxs >>>>> >>>>> root@rainnew ~/# /usr/local/sbin/apxs -q MPM_NAME >>>>> /libexec/ld-elf.so.1: Cannot execute objects on / >>>>> >>>>> apxs:Error: Sorry, no shared object support for Apache. >>>>> apxs:Error: available under your platform. Make sure. >>>>> apxs:Error: the Apache module mod_so is compiled into. >>>>> apxs:Error: your server binary '/usr/local/sbin/httpd'.. >>>>> >>>>> (it should return "prefork") >>>>> >>>>> So I think there is some bug in checking the mountpoint options, >>>>> where the >>>>> check is made on "parent" of the nullfs instead of the nullfs target >>>>> mountpoint. >>>>> >>>>> It is on 6.4-RELEASE i386 GENERIC. I did not test it on another release. >>>>> >>>>> This is list of related mount points: >>>>> >>>>> /dev/mirror/gm0s2d on /vol0 (ufs, local, noexec, nosuid, soft-updates) >>>>> /vol0/jail/.nullfs/rain on /vol0/jail/rain_new (nullfs, local) >>>>> /usr/ports on /vol0/jail/rain_new/usr/ports (nullfs, local) >>>>> devfs on /vol0/jail/rain_new/dev (devfs, local) >>>>> >>>>> If I changed /vol0 options to (ufs, local, soft-updates) the above >>>>> error is >>>>> gone and apxs / compilation works fine. >>>>> >>>>> Can somebody look at this problem? >>>> >>>> Can you please provide output from ktrace / truss for the issue? >>> >>> I did >>> # ktrace /usr/local/sbin/apxs -q MPM_NAME >>> >>> The output is here http://freebsd.quip.cz/ld-elf/ktrace.out >>> >>> Let me know if you need something else. >>> >>> Thank you for your interest! >> >> The problem is still there in FreeBSD 8.1-RELEASE amd64 GENERIC (and in >> 7.x). >> >> Can somebody say if this is a bug or an expected "feature"? > > I think this is the expected behavior as nullfs is simply re-exposing /vol0 > and it shouldn't be able to create a more privileged mount than the underlying > mount I think (e.g. a read/write nullfs mount of a read-only filesystem would > not make the underlying files read/write). It can be used to provide less > privilege (e.g. a readonly nullfs mount of a read/write filesystem does not > allow writes via the nullfs layer). > > That said, I'm not sure exactly where the permission check is failing. > execve() only checks MNT_NOEXEC on the "upper" vnode's mountpoint (i.e. the > nullfs mountpoint) and the VOP_ACCESS(.., V_EXEC) check does not look at > MNT_NOEXEC either. > > I do think there might be bugs in that a nullfs mount that specifies noexec or > nosuid might not enforce the noexec or nosuid bits if the underlying mount > point does not have them set (from what I can see). Thank you for your explanation. Then it is strange, that there is bug, that allows execution on originally non executable mountpoint. It should be mentioned in the bugs section of the mount_nullfs man page. It would be useful, if 'mount' output shows inherited options for nullfs. If parent is: /dev/mirror/gm0s2d on /vol0 (ufs, local, noexec, nosuid, soft-updates) Then nullfs line will be: /vol0/jail/.nullfs/rain on /vol0/jail/rain_new (nullfs, local, noexec, nosuid) instead of just /vol0/jail/.nullfs/rain on /vol0/jail/rain_new (nullfs, local) Then I can understand what is expected behavior, but our current state is half working, if I can execute scripts and binaries, run jail on it, but can't execute "apxs -q MPM_NAME" and few others. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sat Dec 25 13:56:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 857FD106566C for ; Sat, 25 Dec 2010 13:56:37 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 39FB88FC13 for ; Sat, 25 Dec 2010 13:56:37 +0000 (UTC) Received: by qyk8 with SMTP id 8so7980375qyk.13 for ; Sat, 25 Dec 2010 05:56:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+IP78LBrl3RHkRXp3Aik/OlBOdEAggYSW65SPi33RJM=; b=fAFgXnfWeDuQlqOXKSSCaWFgdRcXkq1O5y+XaPm1n+DaPUYD7ZsiqT9POA81KS78Tx fTsOq5LQ+G24OtuumQpvC+E9DidXX369t8Mq+bGm/HMVV/6gpW4olA8hA9oqiaPcuenF 16kSEdIpUj8XuWlc1Tnp5GWXWogw8ObhxG4ZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=W0V+lw97+aokdSWZA/z++WXlaObse5zvMkYlhU960Jmj9+0R5lCNvJtnWXzmH4cIhM 1dgIQmlH1AuvsAq5ENmIohzVzjMDp1nVL4DSIpiUx/4bHTi3bsu//WGgLJQrGoumf1Wq xSA8yPO2eMswAyOuts9BKvdtuptafM0lc9vm8= MIME-Version: 1.0 Received: by 10.229.248.198 with SMTP id mh6mr9410348qcb.5.1293283658104; Sat, 25 Dec 2010 05:27:38 -0800 (PST) Received: by 10.229.39.147 with HTTP; Sat, 25 Dec 2010 05:27:37 -0800 (PST) In-Reply-To: <87r5d6e9vb.fsf@oak.localnet> References: <4D11F1F5.7050902@quip.cz> <201012220957.26854.jhb@freebsd.org> <4D13A579.8090004@langille.org> <87vd2iepkv.fsf@oak.localnet> <87r5d6e9vb.fsf@oak.localnet> Date: Sat, 25 Dec 2010 16:27:37 +0300 Message-ID: From: Sergey Kandaurov To: Carl Johnson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: MCA messages after upgrade to 8.2-BEAT1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 13:56:37 -0000 On 25 December 2010 07:48, Carl Johnson wrote: > Alan Cox writes: > >> On Fri, Dec 24, 2010 at 5:08 PM, Carl Johnson wrote: >> >>> Alan Cox writes: >>> >>> > 2010/12/23 Dan Langille >>> > >>> >> On 12/22/2010 9:57 AM, John Baldwin wrote: >>> >> >>> >>> On Wednesday, December 22, 2010 7:41:25 am Miroslav Lachman wrote: >>> >>> >>> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Bank 0, Status 0xd40e400000000= 833 >>> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Global Cap 0x0000000000000105, >>> >>>> Status 0x0000000000000000 >>> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Vendor "AuthenticAMD", ID 0x40= f33, >>> >>>> APIC ID 0 >>> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: CPU 0 COR OVER BUSLG Source DR= D >>> >>>> Memory >>> >>>> Dec 21 12:42:26 kavkaz kernel: MCA: Address 0x236493c0 >>> >>>> >>> >>> >>> >>> You are getting corrected ECC errors in your RAM. =A0You see them o= nce an >>> >>> hour >>> >>> because we poll the machine check registers once an hour. =A0If thi= s >>> happens >>> >>> constantly you might have a DIMM that is dying? >>> >>> >>> >> >>> >> John: >>> >> >>> >> I take it these ECC errors *may* have been happening for some time. = What >>> >> has changed is the OS now polls for the errors and reports them. >>> >> >>> >> >>> > Yes, we enabled MCA by default in 8.1-RELEASE. >>> >>> Is there some reason that it is only available for i386 and not for >>> amd64? =A0Linux has something called mcelog, for machine check errors, >>> which sounds similar and is available for amd64. >>> >>> >> Perhaps I'm misunderstanding your question, but our MCA driver is suppor= ted >> and enabled by default on both i386 and amd64. > > Thanks, it appears that I misunderstood. =A0I ran whereis and found > /usr/src/sbin/mca and didn't find it on my amd64 system. =A0I do see it i= n > my sysctl listing now that I look there. > I guess that's designed for ia64 only (at least there's no hw.mca.first on other arches). --=20 wbr, pluknet